Monde API

Endpoint availability

Each endpoint has a badge indicating whether you can already use it:

• Beta (orange): already available for use, but still in a testing and adjustment phase. It may change.
• In development (gray): not ready for use yet. It is only documented as a reference of what we have planned, and may still change.

Authentication

To access the endpoints, you must include a valid credential in the request's Authorization header, using the Bearer scheme.

Example of an authentication header:

Authorization: Bearer bW9uZGV8dXNlcjpwYXNzMTIz

About authentication:

• Credentials will be generated and provided by the travel agency with which you are integrating.
• Credentials do not expire, but can be revoked at any time by the travel agency.

Idempotency

Some endpoints in this API use an idempotency key (Idempotency-Key) to ensure duplicate requests (for example, due to timeouts or automatic retries) are not processed more than once.

How to use

• The key must be a valid UUID v4 (e.g. 550e8400-e29b-41d4-a716-446655440000).
• Use the same key when retrying the same request (same endpoint and same payload).
• Use a new key for each different operation (different payload).
• The key is valid for 1 day after the first request.

Behavior

• Replay: if the same key is reused with the same payload and the previous request has already been processed, the API returns the cached response and includes the X-Idempotent-Replay: true header.
• Request in progress: if a request with the same key is still being processed, the API returns 409 Conflict.
• Refused request: if the previous request ended in a refusal (for example, a 422 Unprocessable Content), the key becomes available again: sending the same request with the same key is processed again.
• Key reused with different payload: if the same key is reused with a different payload, the API returns 422 Unprocessable Content.

Rate limits

To keep the service stable for everyone, this API limits how many requests each client can make in a short time window.

Limit

• Up to 10 requests every 3 seconds, counted per origin IP address.

When the limit is exceeded

• The API responds with 429 Too Many Requests and an error message.
• No requests are processed while the limit is exceeded.

Recommendation

• When you receive a 429, wait before retrying and use an increasing wait time between attempts (exponential backoff).

Pagination

List queries return one page of records at a time. The pagination node in the response tells the page size, whether a next page exists and which cursor to send to reach it.

Walking through the whole query

1. Make the first request without cursor.
2. While has_next_page is true, repeat the request sending cursor with the next_cursor value from the previous response.
3. When has_next_page is false, next_cursor comes back null and the walk is over.

Page size

• size sets how many records come per page: from 1 to 50. Without the parameter, it is 20.

The cursor

• It is opaque: store and send back the value exactly as it came, without reading into its content.
• It belongs to the query that produced it: keep the same filters as you move forward. A cursor this API did not return is refused with 400.
• It marks a position in the query, not a moment in time: records created or changed during the walk may show up in the following pages.

Attachments

Operations for uploading attachments associated with resources.

Sales

A sale is an object that represents the commercialization of one or more products between a travel agency and its clients. To sell the product to the client, the agency may acquire it directly from a supplier or through a representative.

• Supplier: the company that directly owns the product. Examples: insurers, cruise lines, airlines, hotels, car rental companies, among others. On Monde, a product must have a supplier.
• Representative: the company responsible for intermediating the commercialization and distribution of the supplier's product to the travel agency. The most common examples are operators and consolidators. On Monde, a product must have a representative when the agency did not purchase the product directly from the supplier.
• Some operators and consolidators may also directly own products, such as travel packages. In these cases, they act as the suppliers of the product to the travel agency.

Products

Query available travel products (insurance, cruises, hotels, airline tickets, own operations, and others) to use in your sales.

Cabins

Query the cabin types registered in the system to use in cruise products.

Ships

Query the ships registered in the system to use in cruise products.

Cost Centers

Query the cost centers registered in the system to use in financial transactions.

Currencies

Query the currencies registered in the system to use in sale products and financial transactions.

Categories

Query the financial categories registered in the system, grouped by kind (revenue or expense) and group.

Cities

Query the cities registered in the system, with state, country, and official codes (IBGE, SIAFI, and SETEC).

Sellers

Query the sellers registered in the system to use in your sales.

Payment Methods

Query the payment methods registered in the system to use in financial transactions.

Accounts and Cards

Query the accounts and cards registered in the system, with bank and credit card data and the companies where each account is available.

Invoice (NF) Rules

Query the invoice (nota fiscal) issuing rules registered in the system, with the sale fields that compose each issuance.

Tasks

Query, create, update, and delete tasks, with assignee, linked person, category, and due date, and comment on their history.

Task Categories

Query the task categories registered in the system.

Travels

Query the travels registered in the system, with customer, seller, situation, and the period calculated from the linked sales.

Quotes

Query the quotes registered in the system, with validity, status, and the public viewing link.

Billing Rules

Query the billing rules registered in the system, with the rule owner, closing period, and due date conditions.

Integrations

Query the vendor integrations registered in the system. Integration credentials are never returned.

People

Query the people registered in the system, with contact data, documents, and additional information.

Labels

Query the labels registered in the system to classify people.

Accounts Payable and Receivable

Query the accounts payable and receivable (financial entries) of the companies where the credential has permission. The same resource covers both cases: accounts receivable (transaction_kind = credit) and accounts payable (transaction_kind = debit). It brings identification, values, status, categories, apportionments, settlement movements, items, commissions, attachments and custom fields.

Account movements

Query the movements of accounts and cash registers: date, amount, direction, check and card data, and the references to the account, the payment method and the settled bill.

Refunds

Query the sale refunds: refund side, amount, dates and the references to the sale, the sale product, the person, the company and the account payable or receivable.

CVC Statement

Query the receipts and movements of the CVC statement: amounts, commissions, balances, dates and the references to the company, the contractor, the seller, the intermediary, the sale, the sale product, the fiscal note and whoever registered it.

Invoices

Query the service invoices: numbering, status, dates, amounts, withholdings and taxes, the recipient data stored on the invoice (with the reference to their city), the NFS-e data and, when getting the invoice by ID, the items and the references to person, company, sale product and sale.

Logs

Query the system change history: the recorded action, the origin, the description of the change, when it was recorded and, when getting the entry by ID, the references to the author and to the audited record.

Custom Fields

Query the definitions of the system's custom fields by resource (sales, travels, people, accounts payable/receivable and tasks): the identifier, the name, the kind, whether it is required and the registered options.

Changelog

The v3 API is in beta: already available for use, but still in a testing and adjustment phase — fields and endpoints may change. Follow this section for changes.

2026-09-28

Automatic connection

• The Automatic connection section now has the full request and response examples for the approval check, the code exchange and the revocation, what reaches the redirect_uri when the agency approves or refuses (with the state), and the errors of each step.
• Revocation by the partner, at POST /oauth/revoke, is now documented: it deletes the connection with the agency immediately.

People, Sales, Tasks and Cities

• In Create a person, Update a person, Create a sale, Create task, Update task and Comment on the task, a field sent in a format other than the documented one now answers 422, naming the field, and nothing is written. Before, the field was ignored and the request succeeded without that data. This applies to a list or object sent as text, number or boolean (such as "labels": "..."), to a list item that is not an object (such as "labels": ["<id>"] instead of "labels": [{ "id": "<id>" }]) and to a plain value sent as a list or object. A null field or one with empty text still counts as not sent.

• In List people and List cities, a filter sent as a list or a nested value (such as ?name[]=Ana) now answers 400, naming the parameter. Before, the filter was ignored and the query returned the list without it.

2026-09-25

Cities

• List cities now accepts the name filter, which searches by a part of the city name, case-, accent- and position-insensitive (e.g. ?name=sao paulo). The filter works with pagination and the ordering by name.

Tasks

• Update task is now available: updates title, description, due, category_id, assignee_id, person_id, and custom_fields of an existing task. Send only what should change — a field that is omitted, or sent as null or as an empty string, stays as it is. title is the exception: a task must have a title, and sending it as an empty string is rejected. The custom fields sent overwrite the current ones, and the others stay.

• completed completes the task (true) or reopens it (false), and company_identifier moves the task to another company, which also requires the Create and edit permission on Tasks in the destination company.

• The update requires the Create and edit permission on Tasks and the Idempotency-Key header. The task participants are notified by email, as when the change is made in Monde.

• Delete task is now available: deletes the task, which no longer appears in List tasks and is still available in the query by ID, with deleted set to true. A completed or already deleted task responds 409, and nothing is changed. Responds 204 with no body and does not require Idempotency-Key. Requires the Delete permission on Tasks, now offered on the API credential, granted in the task's company with an API license that writes. The task participants are notified by email.

• A deleted task cannot be updated or take comments: Update task and Comment on the task respond 409.

• Update task and Comment on the task respond with only the id of the task when the credential does not have the Read all tasks permission in the task's company. The write happens all the same, with the same status. A credential with the read permission keeps receiving the full task, in the same format as the get by ID.

People

• Update a person now responds with only the id of the person when the credential does not have the "Read all people" permission. The update is written all the same, with the same 200 status. A credential with the read permission keeps receiving the full person, in the same format as the get by ID.

2026-09-24

Tasks

• Create task is now available: send company_identifier, title, due, category_id and assignee_id, and optionally description, person_id and custom_fields. The assignee must be an active Monde user and is notified by email. The task is created as pending. Accepts Idempotency-Key for safe retries.

• A task can be created with its first comments: send history, a list of { "text": "..." }, in the same creation body.

• Comment on the task appends a comment to the history of an existing task and returns the task with the updated history. The task participants are notified by email. The history is append-only: a recorded comment can be neither changed nor deleted.

• Both writes require the Create and edit permission on Tasks, now offered on the credential.

• In the task queries, due and completed_at are now returned without the time zone offset, in the same format as created_at and every other date-time field in the API: 2026-04-01T09:00:00 instead of 2026-04-01T09:00:00-03:00. The time itself is unchanged.

People

• In the people queries, last_contacts.last_task_update_at is now returned without the time zone offset, in the same format as the other last_contacts dates and the other date-time fields of the API: 2026-07-01T15:12:00 instead of 2026-07-01T15:12:00-03:00. The time is the same.

Automatic connection

• The Supplier credentialing section is now called Automatic connection and applies to any partner, not only to those that create sales.
• The partner permissions are now set during approval, and the agency sees that list on the consent screen before authorizing. Partners approved before this keep sale creation.
• Creating sales through the integration needs no API license. Permissions outside Sales need an API license on the picked company.
• A partner with sale creation does not read sales: the created sale comes back in full in the POST /sales response. Attachments only go to the sale the partner itself created.

2026-09-22

People

• Delete a person is now available: permanently deletes a person that has no related records (sales, financial entries, invoices, quotes, tasks, attachments, among others) and that is neither a system user nor a system company. In those cases the response is 409, with the reason, and nothing is changed. It responds 204 without a body and does not require Idempotency-Key. It requires the "Delete" permission on People, now offered on the API credential, granted in a company whose API license allows writing.

Logs

• The description of every log written by an API request now starts with the action and the label of the credential that made it: Inserido via API pela credencial "...", Editado via API pela credencial "..." or Excluído via API pela credencial "...". The following lines, with the changed fields, are unchanged. It covers everything the request writes: the record, the links written along with it (such as a person's labels and contacts) and the bills a sale generates, including those of the supplier invoice. In List logs the person of these logs is still null, because the credential is not a person.
• The separate log with the description Registro cadastrado via API, written by the API alongside every record creation, is gone: who created the record is now the first line of the log of the record itself. In List logs a creation made through the API now brings one log less.

2026-09-21

People

• Update person is now available: it updates a person already registered with the same fields as Create person. Send only what must change — a field left out, or sent as null or as empty text, stays as it is, and a text field is not emptied by this operation. The kind of the person does not change, the external_id starts identifying them as long as it does not identify another person, and the CPF/CNPJ and the airline code cannot belong to another person. Labels and contacts work by replacement: the list sent becomes the list of the person, an empty list removes every item and leaving the field out keeps the current ones. Custom fields do not replace: every one sent is written over the current value and the remaining ones stay. It requires the "Insert and edit" permission on People and the Idempotency-Key header.

Sales

• Sale totals now account for the passenger's RAV fee discount and second fee (other_fees, tip). Previously the discount sent on the passenger was stored but did not reduce any total, and the second fee did not reach the fee total. Product amount, total discount, revenue, billing and the sale balance now match what Monde calculates on screen.
• rav_fee_discount is only accepted when rav_fee is greater than zero. Sending the discount without the fee now answers 422, the same way Monde refuses it on screen.

Attachments

• Upload attachment refused with a 422 now releases the Idempotency-Key: sending the same attachment again with the same key is processed again, instead of answering 409 indefinitely.

2026-09-18

License and permission

• The 403 responses now point at the right cause across the whole API. The API license is charged on the company where the credential works — the company of the record being read, or the company where the permission was granted — and no longer on any company in the database. A credential holding the permission in a company without an API license now gets "You do not have an API license" in place of "You do not have permission to perform this action". A missing license is always reported before a missing permission.

Attachments

• Upload attachment now accepts person in resource_type: send the resource_id of the target person and the attachment is stored on their record, showing up in the person query by ID and in the download. It requires, on People, the Add attachments permission — now offered on the API credential — granted on a company holding a writable API license. The rest of the upload is unchanged: one file per request, the same extensions, the same 12 MB limit and the same Idempotency-Key.

• Upload attachment no longer requires permission to read the target resource: attaching to a sale only asks for the sale attachment permission. The response changes with it: a sale the credential cannot attach to now answers 403, in place of the 422 "Resource not found" that came back when the read-sales permission was missing. The 422 is now for a resource_id that does not exist.

• The attachment upload limit of 10 requests every 3 seconds now counts every attempt, including the ones refused by authentication, permission, license, oversized file or malformed request. A run of refused attempts now reaches the 429.

People

• Create a person is now available: it creates an individual or a legal person with address, place of birth, documents and parentage, municipal registration, tax identification, notes, bank slip fee charging, tax withholding, airline data, salesperson, promoter, labels, contacts and custom fields. The external_id is optional and, when provided, must be free; the CPF/CNPJ cannot belong to any person already registered. It requires the "Insert and edit" permission on People and the Idempotency-Key header.

• In Get person by ID, each custom_fields item now brings the definition id and no longer brings the name, as sales and bills already did. The name, the kind and the options come from Get custom field by ID.

Sales

• The installments (credit card and bank slip) and installment_period (bank slip) fields were removed from the payments made to the agency in Create sale. They split nothing: the sale was always created with a single entry, on the due date informed. They are still accepted in the request body and ignored, so anyone already sending them keeps creating sales the same way.

• To split a payment to the agency, send one payment per installment in the payments array, all with the same payment method, bank account and payer, each with its own due_date and its share of the amount in products[].payment_amount. Each payment becomes one financial entry.

• In vendor.credit_card the installments field did not change: it is still informed on creation and returned when reading the sale.

• The person nodes of the sale creation (payer, intermediary, approver, requester, supplier, representative, the person of each passenger and the payer of each payment) now accept the same fields as the person registration: business_phone, website, city_inscription, tax_identification_number, observations, charge_billet_fee, birthplace, additional_data, tax_withholding and airline. Each field is accepted on the person kind it belongs to, and the payload you already send does not change. charge_billet_fee describes the whole registration and only applies when the sale creates the person: when the external_id or the document already identifies somebody, it is ignored. The person's salesperson, promoter, labels, contacts and custom fields are accepted only on Create a person.

2026-09-15

Sales

• The field that carries the product document is now called document on the products Monde labels "Documento" on the registration screen: Car Rental and Travel Package (previously booking_number), Travel Insurance (previously voucher_code), Train Ticket, Ground Transportation and Excursion (previously locator). On CVC Package the same field is now called receipt_number, the "Recibo Nº" of the screen.

• Products whose screen label was already another word are unchanged: Airline Ticket keeps locator ("Localizador"), Lodging keeps booking_number ("Reserva"), Cruise keeps booking_number ("Booking"), and Other and Own Operation already used document.

• On sale creation, the passenger document is now sent in document, in place of ticket_number, on the products where Monde has that field: Travel Insurance, Ground Transportation, Train Ticket, Travel Package and Own Operation. ticket_number remains the ticket number of the Airline Ticket passenger, on read and on creation, and the ticket_number of each seat in ground_transportations[].segments[].seats[] is unchanged.

• The product document now accepts 40 characters on every product, the same length Monde stores. On Ground Transportation and Train Ticket the limit was 20.

• The old names are still accepted on sale creation and still come back on read, but they left the documentation, which now describes only the new name. They will be removed in a later step, giving existing integrations time to adjust.

2026-09-14

Sales

• In Create sale, the travel_agent field is now called seller, the same name the sale read already uses and the same term used in Monde.

• In the sale query, passengers of Other, Excursion and Own Operation now return document, which Monde already stores but did not return. In those same three products, other_fees left the response, because they have no second per-passenger fee. Own Operation also dropped rav_fee, rav_fee_discount and agency_fee, which the product does not charge the passenger. Car Rental is unchanged.

2026-09-11

Products

• The product kind now includes excursion and cvc_package (CVC package). CVC packages used to come back with no kind.

• The ?kind= filter now accepts cvc_package and excursion, and is described as a list of values: several kinds separated by commas, as in ?kind=insurance,cruise. The call does not change.

• In Get product by ID, the restitutes_lei_kandir field of each supply is now called restitutes_kandir_law. The value does not change.

• System products now show system: true in the examples, and the field description was corrected: a system product cannot be deleted, but it can be edited.

Sales

• Create a sale: the commission role in the commissions array is now set through the kind field (seller, intermediary or person), instead of job_title_id (UUID). seller and intermediary record the matching system job title; person records none. The recipient's external_id remains required.

• When creating sales, the passenger ticket_number field is now accepted for own operation, train ticket and travel package, storing the passenger's document — the same column the query returns as document for these products.

• The ?status= filter is now described as a list of values: several statuses separated by commas, as in ?status=opened,closed. The call does not change.

Accounts payable and receivable

• The ?status= filter is now described as a list of values: several statuses separated by commas, as in ?status=open,overdue. The call does not change.

2026-09-10

Attachments

• Upload attachment is now available: send one file per request as multipart/form-data, providing resource_type (currently sale) and the target sale's resource_id, plus file and an optional description. It validates the extension (pdf, images, office files, txt, csv), the 12 MB maximum size and the real file content. The attachment then appears in the sale query and download. Accepts an Idempotency-Key for safe retries.

2026-09-09

Sales

• The payer field on each payment now takes a full person object, the same one used for the sale payer, and creates the person when it does not exist yet. Before, it only referenced an already registered person by external_id. Repeating the sale payer's external_id resolves to the same person. When omitted, the payment still inherits the sale payer.

2026-09-08

Authentication

• Authentication now uses the Bearer scheme in the Authorization header. The credential is unchanged and does not need to be reissued, so integrations already in production keep working. Use Bearer from now on.

Sales

• In Create sale, the products' external_id is now called local_id, and the same applies to each payments[].*.products[] item. The local_id is a correlation key valid only inside the request: it must be unique among the products of that sale, it is not stored and it can be reused in later sales. It only accepts text.

• When reading List sales and Get sale by ID, products no longer carry external_id. The product identifier on read is id.

2026-09-03

All queries

• List queries now paginate by cursor. The response carries next_cursor in the pagination node, and to ask for the next page you send it back in the cursor parameter, while has_next_page is true. See the Pagination section. The page parameter keeps working as before for whoever already integrated, but it is no longer the published form: with page the cost of each page grows with how deep the walk goes, and with the cursor it does not. Whoever paginates by cursor no longer receives page in the pagination node.

2026-09-02

Supplier credentialing

• Suppliers now receive their credentials on a dedicated page in Monde (the email only carries the link to it); the client_secret is shown a single time and is no longer emailed. The page also includes the "Connect with Monde" button snippet.
• Credentialing gained an approval step: confirm your credentials at POST /oauth/homologation (HTTP Basic with client_id and client_secret). While pending, authorization does not work; once it answers 200, it becomes active. See the Supplier credentialing section.

2026-09-01

Sales

• Create a sale now accepts the payer field on each payment (agency credit card, bank slip and bank deposit; vendor card, credit and others), referencing by external_id the person who actually pays that payment — typically the person financially responsible informed on the sale. On the agency side the generated account receivable uses that payer as its person; on the vendor side the payer is written on the account payable entry. When omitted, the payment inherits the payer of the sale. An external_id that matches no registered person returns 422.

2026-08-31

Sales

• Create a sale now accepts the requester, to record who requested the sale along with its creation. It is an individual (physical person), an optional field, resolved by external_id (find-or-create), like the other roles.

2026-08-28

Sales

• Create a sale now accepts the commissions array, to record manual commissions (seller, intermediary or another role) along with the sale. The recipient is referenced by external_id, the same one sent as the seller/intermediary; the job title goes in job_title_id. It is only accepted when status is closed; a commission with an intermediary job title requires the sale to have an intermediary.

2026-08-27

Sales

• Create a sale now returns 422 when a sale person's (payer, supplier, passenger) CPF/CNPJ already belongs to another person in the database, with the error on the cpf_cnpj field. Previously the document conflict raised an internal error (500).

2026-08-26

Supplier credentialing

• Suppliers approved by Monde can now create sales on the v3 API on behalf of an agency via OAuth 2.0 (Authorization Code + PKCE), without the agency sharing a credential password. See the step by step (authorization at the root URL, exchanging the code for a token and using the Bearer on the fixed v3 URL) in the Supplier credentialing section. The agency can revoke access at any time and revocation invalidates the token immediately.

2026-08-24

Sales

• Create a sale now inherits the included services registered on the product. When the sale product's included_services field is not sent, the product's registered text is stored; when it is sent, the provided text is appended to the registered one. Previously the sale product field kept only what the request sent.

2026-08-21

Sales

• List sales now filters by number (one per request): pass the number shown in the app and the query returns the matching sale without translating number into UUID first. A non-integer number returns 400.
• List sales now filters by updated_since (ISO 8601 date or date-time, e.g. 2026-08-01 or 2026-08-01T14:30:00; the Brasília time zone is assumed when no zone is given): it returns sales updated at or after that instant, to reprocess only what changed since the last query, even within the same day. An invalid value returns 400.

Travels

• List travels now filters by date with date_field + date_from/date_to: choose the date in date_field (start_date or end_date, the trip start and end computed from the linked sales) and provide the closed inclusive range in date_from/date_to (ISO YYYY-MM-DD, both optional). date_field is required when any date is given; an invalid date format, an inverted range (date_from greater than date_to) or a date_field outside the list return 400. A travel with no linked sales has no computed dates and never shows up in a date range.

Accounts payable and receivable

• List accounts payable and receivable now filters by number (one per request): pass the bill number shown in the app. Installment bills carry a parcel suffix (e.g., 362-1), so provide the number exactly as shown.
• List accounts payable and receivable now filters by date with date_field + date_from/date_to: choose the date in date_field (issue_date, due_date or settlement_date) and provide the closed inclusive range in date_from/date_to (ISO YYYY-MM-DD, both optional). date_field is required when any date is given; an invalid date format, an inverted range (date_from greater than date_to) or a date_field outside the list return 400. Filtering by settlement_date returns only settled bills (unsettled ones have no settlement date and fall outside the range); since the default status (open, overdue) excludes settled bills, include settled in the status parameter when using settlement_date.

2026-08-20

Sales

• Create a sale now accepts the status field. It still defaults to opened; send closed to create the sale already closed. Closing honors every existing rule (no pending balance, and on a consolidator install the intermediary is required) and requires the close-sale permission on the credential. If the sale cannot be closed, the whole creation is rejected with 422 and nothing is persisted.

2026-08-17

Sales

• List sales now filters by date with date_field + date_from/date_to: choose the date in date_field (sale_date, departure_date or return_date) and provide the closed inclusive range in date_from/date_to (ISO YYYY-MM-DD, both optional). It replaces period_start/period_end, which were removed. date_field is required when any date is given; an invalid date format, an inverted range (date_from greater than date_to) or a date_field outside the list return 400.

• In the sale response, period_start and period_end became departure_date and return_date — same values (trip start and end, computed from the earliest and latest product dates).

2026-08-14

Sales

• Get sale by ID now brings the excursions array.
• In sale creation, the passenger fee field (fees) is now accepted on every product with passengers — travel insurance, cruise, hotel, ground transportation, car rental, train ticket, travel package, and own operation —, matching what the read already uses. rav_fee, rav_fee_discount and agency_fee are now accepted on the same products, except own operation, whose passenger only has amount and fee; other_fees (hotel, car rental, travel package) and tip (cruise) are now accepted as well. On the products that had a product-specific name for the main fee field — service_fee (hotel and ground transportation) and booking_fee (train ticket) —, the old names are still accepted for now, but are no longer documented in favor of fees.
• Fixed totals.balance: sales created through Create sale always came back with a 0 balance on read, even when there was a real open balance. It now reflects the correct balance on both the list query and the query by ID.

People

• Get person by ID gained the kandir_law node: per-product tax withholding (amount, boarding fee, DU/RAV fee, and service fee, each broken down by tax — IR, CSLL, PIS, and COFINS — plus the total, for both domestic and international regimes), with the reference to the product. Only exists for companies; comes back null for individuals.
• city_inscription and tax_identification_number moved back to the person's top level. They were inside additional_data, which only exists for an individual person, but both fields are legal-person data.

Invoice rules

• In closing.period_kind, the value separate became standalone. This closing cadence leaves each sale in its own invoice, and standalone is how the API already names that same concept in the accounts payable/receivable kind.

Accounts payable/receivable, and invoices

• The two fields that still came in the old format since the 2026-08-13 entry caught up with the code: in Get invoice by ID, items no longer bring id; in Get account payable or receivable by ID, credit_card_items[].id gave way to the movement reference.

Naming

• The Products and Tasks schemas now follow the rest of the API's convention: the list schema got the _summary suffix, and the plain name became the get by ID schema.

Naming

• registered_at was renamed to created_at in sales, accounts payable and receivable, invoices, invoice (NF) rules, tasks, travels, sellers, people, CVC statement and logs — the more common name for this concept across REST APIs.
• registered_by was renamed to created_by, for the same reason, in sales, accounts payable and receivable, invoices, invoice (NF) rules, tasks, travels, sellers, people and CVC statement.

2026-08-13

Read pattern adjusted across several endpoints, in the same direction as the 2026-08-11 entry: the list brings the record's own fields, and the associations — references and data from other entities — stay in the get by ID.

• The rate limit changed from 60 to 10 requests every 3 seconds per origin IP address.

People

• List people now brings every field of the person itself, which previously existed only in the get by ID: rg_ie, passport_number, passport_expiration_date, foreigner, foreign_identity_document, business_phone, website, cvc_code, observations, charge_billet_fee, registered_at and the additional_data, last_contacts, tax_withholding and airline nodes.
• gender and birthdate were added, in both reads.
• Get person by ID kept what is an association: birthplace, seller, promoter, registered_by, contacts, labels, custom_fields, attachments and credit_cards.
• Contacts and credit cards no longer bring id: they are data that only exist inside the person.
• In the credit cards, masked_number became last_digits and now brings only the last four digits, without the mask.

Accounts payable and receivable

• List accounts payable and receivable now brings billet, check and card, which previously existed only in the get by ID. They are data of the entry itself.
• In credit_card_items, the id — which was the account movement identifier, not the line's — gave way to the movement reference, resolved in Get account movement by ID.

Invoices

• The items in Query invoices by ID no longer bring id. The item has no endpoint of its own, and the identifier resolved nothing.

Cities, categories, accounts and cards

• state and country left List cities and stayed in Get city by ID.
• group left List categories and stayed in Get category by ID.
• bank left List accounts and cards and stayed in Get account or card by ID.

Logs

• kind now declares its possible values: insertion, edition, deletion, custom and export. There are no others.
• The person description now points to Get person by ID, the endpoint that resolves the reference.

Sales, products, tasks and invoice (NF) rules

• Get sale by ID now brings the travel reference, resolved in Get travel by ID. The link existed only in the opposite direction.
• Products now brings active, and Tasks, deleted.
• In the invoice (NF) rules, inside payer_rule, supplier_rule and representative_rule, recipient now comes before revenues and discounts.

2026-08-12

• List sales gained the people_id filter: it returns the sales in which the given person participates in any role (payer, seller, intermediary, requester, approver, promoter, passenger, supplier, representative or the person who registered the sale). It accepts multiple comma-separated identifiers — a sale matches when any of the people participates.

• New endpoints to read the custom field definitions: List custom fields and Get custom field by ID. The list brings the custom fields by resource (sales, travels, people, bills and tasks), with the identifier, the name, the kind, whether it is required, whether it is active and the registered options of list-kind fields, and accepts the resource filter; the get by ID resolves a field definition from its id. The definitions are not scoped by company. The identifier of each field is numeric (not a UUID like in the rest of the API).

• The pagination node no longer carries total and total_pages, and now carries has_next_page. To walk through a whole query, request the next page while has_next_page is true. The request does not change: page and size work as before. Counting the total required walking every record matching the filter on each request, which on large databases cost more than fetching the page itself.

2026-08-11

Every read now comes in two forms: a lean list query, for extracting volume, and a query by ID, with the complete record. Associations are no longer embedded: they come as a reference carrying only the identifier. Each reference description points to the endpoint that resolves it, and references and collections appear only on the query by ID. The changes are grouped by endpoint.

The new queries by ID are documented before they exist: each one carries the In development badge until the code ships. The list queries that already existed remain in Beta, available for use.

Sales

• List sales returns only the scalar fields of the sale plus the totals. The products, the payments, the commissions, the attachments, the custom fields and the financial node left the list and remain in Get sale by ID, which is also where the references live: payer, seller, company, intermediary, requester, approver, promoter, operation and whoever registered it.
• sale_id became id. travel_agent became seller, and the reference points to Get seller by ID — the id is the same as before, because the seller shares the identifier of the person; for the person data, use that same id on Get person by ID.
• Three fields were dropped: company_identifier, which carried the taxpayer ID copied from the company and gives way to the company reference (it is still required on creation), totals.payments, and role on the commissions.
• On commissions, value, retained_value and leftover became amount, retained_amount and balance; on the totals, final_value became final_amount; on vendor transfers, value became amount.
• Payments changed shape. payments is no longer a list: it is now an object with agency and vendor. Under agency, bills and refunds are reference lists, resolved by Get account payable or receivable by ID and Get refund by ID; credit, retained_by_intermediary and legacy come embedded, because they generate no bill. Under vendor there is one list per method: credit_card, check, credit and others.
• As a result, the per-method nodes on the agency side are gone (cash, check, credit_card, debit_card, bank_slip, bank_deposit, others, custom and invoice). All of them generate a bill, and it is the bill that carries the payment method, the account, the settlement, the billet and the products covered. A bill settled through several methods appears once, and each settlement comes in movements, on the bill itself.
• Each products item now carries amount and the sale_product reference, replacing external_id and payment_amount. Every embedded payment gained payer, which may differ from the payer of the sale.
• In the financial node, vendor became vendor_bills and bills became standalone_bills — both now reference lists to bills. The items and amounts come from the bill itself.
• The sale operation field is the reference to the own operation on the header, and the detail of the own-operation product lives in the operations collection, alongside the other products. In the 2026-08-07 entry that field started returning the whole product when a line existed; it is now always a reference.
• Each sale product now carries its own id, which makes the sale_product reference of the bill, the invoice, the refund and the CVC statement resolvable. On the others, operation and cvc_package types, product_name and product_with_passengers were dropped and the product reference was added; the other eight types have a single system product each, and the array name already identifies it.
• currency is an ISO code (text) both on creation and on read; the full currency object is now exclusive to Currencies. On sale products, currency and exchange_rate are creation fields: on read they always return BRL and 1, and the amounts come converted to Brazilian Real.
• In custom_fields, each field now carries the id of the definition and no longer carries name. The name, the kind and the choices come from the custom field definitions query.
• The response of Create sale is now the same as the query by ID. The request body does not change.
• Create sale now accepts the optional description field on agency payments (credit card, bank slip and bank deposit). When provided, the text is saved on the financial entry; when omitted, "Pagamento venda" is still used. Maximum of 60 characters.

Accounts payable and receivable

• Get account payable or receivable by ID gained the check and card blocks, with the check and card data recorded on it. They used to appear only on the sale, and were unreachable while the payment was not settled.
• On kind, sale_separate and vendor_separate became sale_standalone and vendor_standalone. The kind filter takes the new values.
• In custom_fields, each field now carries the id of the definition and no longer carries name, as on the sale.

People

• New Get person by ID, with the contacts, labels, custom fields, attachments and credit cards. List people is now lean.
• The city of the address, the birthplace, the seller, the promoter and whoever registered the record come as references.
• external_id is now documented on the query: the response already carried the identifier you assigned to the person, but it was not documented. It comes null when the querying credential has no external identifier for that person.
• List people now accepts filters by name, cpf_cnpj, passport_number, phone, kind (individual or company), code and email. All are optional and combinable (logical AND between them): name, passport_number and email match by substring, case- and accent-insensitive; cpf_cnpj and phone accept digits only (formatting is ignored) and code is an exact match. With no filters, the behavior is the same as before.

Products

• New Get product by ID, with the supplies in supplies: each one carries the supplier, the commission data and the representatives.
• On supplies, commission_value became commission_amount, and commission_type now takes amount instead of value.

Tasks

• New Get task by ID, with the history in history (comments and changes) and the custom fields.
• category is no longer text: it became a reference, resolved by Get task category by ID.

Travels

• New Get travel by ID, with references to the linked sales and passengers. The per-passenger amounts belong to each sale and come from the sale endpoint.
• client became customer, and seller now points to the sellers endpoint.

CVC statement

• seller now points to Get seller by ID.

Quotes

• New Get quote by ID. status was dropped: it is derivable from active and valid_until, both still in the response.

Attachments

• attachment_id became id.

Other registries

• These now have a lean list query and a query by ID: sellers, accounts and cards, cost centers, cities, categories, payment methods, invoice (NF) rules, billing rules, integrations and currency by code.
• On sellers, the corresponding person now comes in the person field.
• Still nested, with the full data: the state and the country of the city, the bank of the account, and the group of the category. They have no registry of their own in v3, so there is no endpoint to resolve them. The state gained name, and the country gained code (ISO 3166-1 alpha-2) and code_3 (alpha-3).

New registries on the read side

• Labels and task categories, with a list query and a query by ID. They are the targets of the labels reference on the person and the category reference on the task.

2026-08-10

• Create sale now accepts custom fields in the custom_fields field (an array of {id, value}). The id is the same returned by List custom fields; the value must match the field kind (integer for numeric, number for currency, ISO 8601 date, text for the others). ⚠️ Active required fields of the sales module become mandatory: the create returns 422 if one of them is missing a value.

• On the sale and bill reads, each custom_fields item is now {id, value}: it brings the field id (the reference) and the value, and no longer brings the name. The name, the kind and the rest of the definition are obtained from Get custom field by ID or from List custom fields, so the consumer always reads the reference and not a projected value that can become stale.

2026-08-07

• Create sale now accepts the own operation product in the operation field (a single object; at most one per sale). The product is informed by product_id and, depending on its configuration, the values go by passengers or by quantity × unit_price (with unit_fee and the hidden service fee agency_fee, a single line-level value); the supplier is the sale's own company.

• On read (List sales and Get sale by ID), the operation field now brings the full detail of the own operation product; it previously brought only id and name.

• New endpoints to read the change history: List logs and Get log by ID. The list brings the recorded action, the origin, the description of the change and when it was recorded, with filters by author, audited record, action and origin; the get by ID adds the references to the author and to the audited record. The history is not scoped by company.

2026-08-04

• The items of Get account payable or receivable by ID changed: customer_items and vendor_items were replaced by a single items, which brings every item of the entry, including sale payment items, which previously came out in no array at all. The item now brings only its own columns (description, cost_center, checked, amount) plus the sale, sale_product and cvc_statement references; the sale product data was removed and its source is Get sale by ID.

• Each credit_card_items line now brings id and the bill reference, and lost description and person. The id is the account movement's, so it can be looked up with Get account movement by ID.

• Each commissions line gained the person reference, and the leftover field was renamed to balance.

• The entry lost sale_number, balance, status, overdue_days and settled_late, and gained canceled, checked, invoice_closed, system_generated and recurrence_group_id. The get by ID gained the sale and invoice_rule references. In the status filter, paid became settled.

2026-07-31

• New read endpoints for the CVC statement: Query CVC statement and Query CVC statement by ID. The list brings the receipt number, the movement, sale, cancellation, boarding and return dates, the product name, the package name, the totals, the commissions, the deposit, the balances and the imported, edited, checked and deleted marks; the get by ID adds the movement kind and the references to company, contractor, seller, intermediary, sale, sale product, NF and whoever registered it. A deleted receipt stays out of the list but remains reachable by ID. Scoped by company.

• New read endpoints for invoices: Query invoices and Query invoices by ID. The list brings numbering, status, operation nature, dates, amounts, the recipient data stored on the invoice with the reference to their city, the withholdings and taxes and the NFS-e data, with status and issue period filters; the query by ID adds the invoice items and the references to person, company, sale product, sale and who registered or canceled it. Scoped by company.

• New read endpoints for refunds: Query refunds and Query refunds by ID. They bring the refund side (customer or supplier), the amount, the description, the issue and due dates, and the individual view adds the references to sale, sale product, person, company and account payable or receivable, scoped by company.

2026-07-29

• New read endpoints for account movements: List account movements and Get account movement by ID. The list brings date, amount, direction (credit or debit), note and the check and card data; the get by ID adds the references to account, payment method, bill, credit card invoice and the account on the other side of the transfer. Scoped by company.

2026-07-28

• New read endpoints for accounts payable and receivable: List accounts payable and receivable and Get account payable or receivable by ID. They bring identification, values, status, billet, recurrence, categories, apportionments, settlement movements, invoice items (customer, vendor or credit card), commissions, attachments and custom fields, scoped by company.

2026-07-17

• The List sales and Get sale by ID endpoints now include the sale attachments in the attachments field: each attachment carries id, description, extension, content_type and download_url, with the content accessible through a temporary download link.

2026-07-16

• The List sales and Get sale by ID endpoints now return the operation in the operation field (an object with id and name); previously only the identifier was returned in operation_id.

2026-07-15

• The List sales and Get sale by ID endpoints now include the sale commissions in the commissions field: the split per person and role (seller, intermediary and others), with commission amount, retained amount and remaining balance.

2026-07-14

• The List sales and Get sale by ID endpoints now include the sale financial data in the financial field: financial notes, vendor payouts, and the accounts payable and receivable entries linked to the sale.

2026-07-10

• New read endpoints for the system master data: cabins, categories, cost centers, cities, accounts and cards, payment methods, integrations, currencies, ships, quotes, people, invoice (NF) rules, billing rules, tasks, sellers and travels.

Automatic connection

Besides Basic Auth, a partner approved by Monde can access the v3 API on behalf of a travel agency, via OAuth 2.0 (Authorization Code + PKCE), without the agency sharing a credential password. What the partner can do is set during approval, and the agency sees and approves that list when it authorizes.

Every endpoint in this section lives at https://web.monde.com.br.

Approval credentials

• To request approval, contact Monde's sales or support team. Send the partner name, the email that receives the credentials and the redirect_uri.
• Each partner has a single redirect_uri, and it must use https. It must be identical, character by character, on the authorization and on the token exchange (a trailing slash already counts as a difference). http addresses are not accepted, localhost and 127.0.0.1 included.
• During approval, Monde emails you a link to your automatic connection page. The link is valid for 1 hour; if it expires, ask for a new one. The client_id and client_secret show up on that page; the secret is displayed a single time, so store it right away. If you need to see it again, ask Monde to regenerate it.
• Keep the client_secret on your backend only. It never goes to the browser or to the user's app.

1. Activate the automatic connection (approval check)

curl -X POST https://web.monde.com.br/oauth/homologation -u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET"

• 200 with {"status":"active"}: the connection becomes active. Calling it again returns the same response.
• 401 with an empty body: wrong client_id or client_secret, or partner disabled by Monde.

2. Authorization

code_verifier=$(openssl rand -base64 64 | tr -d '=+/\n' | cut -c1-64) code_challenge=$(printf '%s' "$code_verifier" | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '=\n')

GET https://web.monde.com.br/oauth/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&state=STATE&code_challenge=CODE_CHALLENGE&code_challenge_method=S256

• Do not send scope: what the partner can do comes from the approval.
• If the client_id is not an active, approved partner, if the redirect_uri is not the registered one, or if the code_challenge is missing or the code_challenge_method is not S256, Monde answers 400 on its own page and does not go back to the redirect_uri.

3. Return to the redirect_uri

YOUR_REDIRECT_URI?code=agencia%7CujES3JCJylJRoM3j_kGeavaD2hFqz2oqw1Lazq_u0rs&state=STATE

YOUR_REDIRECT_URI?error=access_denied&error_description=O+dono+do+recurso+ou+o+servidor+de+autoriza%C3%A7%C3%A3o+negou+a+requisi%C3%A7%C3%A3o.&state=STATE

• Compare the state with the one in the session. If it differs or is missing, discard the response.
• The code is opaque. Use the URL-decoded value as it came, without trimming or replacing characters. It is valid for 10 minutes and can be exchanged only once.
• Nothing comes back to the redirect_uri when the signed-in user is not an agency administrator, or when the company lacks the API license the partner's permissions require. In those cases the user sees the explanation on a Monde page.

"Connect with Monde" button

1. Negative (blue background)

Connect with Monde

<a href="AUTHORIZATION_URL" style="display:inline-flex;align-items:center;gap:10px;height:40px;padding:0 20px 0 14px;background:#2c7be5;color:#fff;border:1px solid #2c7be5;border-radius:6px;font:600 14px 'Open Sans',Arial,sans-serif;text-decoration:none"><img src="https://web.monde.com.br/logo-monde-conectar-branco.svg" alt="Monde" style="height:22px"> Connect with Monde</a>

2. Colored (white background)

Connect with Monde

<a href="AUTHORIZATION_URL" style="display:inline-flex;align-items:center;gap:10px;height:40px;padding:0 20px 0 14px;background:#fff;color:#344050;border:1px solid #d8e2ef;border-radius:6px;font:600 14px 'Open Sans',Arial,sans-serif;text-decoration:none"><img src="https://web.monde.com.br/logo-monde-conectar.svg" alt="Monde" style="height:22px"> Connect with Monde</a>

3. Text only

<a href="AUTHORIZATION_URL" style="display:inline-flex;align-items:center;height:40px;padding:0 20px;background:#2c7be5;color:#fff;border:1px solid #2c7be5;border-radius:6px;font:600 14px 'Open Sans',Arial,sans-serif;text-decoration:none">Connect with Monde</a>

4. Exchange the code for a token

curl -X POST https://web.monde.com.br/oauth/token -H "Content-Type: application/x-www-form-urlencoded" --data-urlencode "grant_type=authorization_code" --data-urlencode "code=CODE" --data-urlencode "redirect_uri=YOUR_REDIRECT_URI" --data-urlencode "client_id=YOUR_CLIENT_ID" --data-urlencode "client_secret=YOUR_CLIENT_SECRET" --data-urlencode "code_verifier=CODE_VERIFIER"

{ "access_token": "YWdlbmNpYXw2ZjFj...", "token_type": "Bearer", "scope": "full_access", "created_at": 1790602784 }

• 400 with {"error":"invalid_grant","error_description":"..."}: code expired or already exchanged, code_verifier that does not match the code_challenge, or a redirect_uri different from the one used on the authorization. Start again from the authorization.
• 400 with {"error":"invalid_request","error_description":"..."}: the code_verifier was not sent.
• 401 with {"error":"invalid_client","error_description":"..."}: wrong client_id or client_secret.
• 404 with an empty body: the code arrived altered.

5. Using the v3 API

Authorization: Bearer YOUR_ACCESS_TOKEN

curl https://web.monde.com.br/api/v3/sales -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -H "Content-Type: application/json"

• 403 with {"errors":["Você não tem permissão para executar essa ação."]}: the token is valid and the integration is ready. The partner creates sales but does not read them.
• 401 with {"errors":["Credenciais de acesso não são válidas."]}: the token is invalid or the connection was deleted. Start again from the authorization.

• The partner only reaches the company the agency picked, with the permissions it approved.
• Creating sales through the integration needs no API license. Permissions outside Sales need an API license on the picked company.
• The created sale comes back in full in the POST /sales response.
• The agency can delete the connection at any time; access stops immediately and the API starts answering 401.

6. Disconnect (revocation)

curl -X POST https://web.monde.com.br/oauth/revoke --data-urlencode "token=YOUR_ACCESS_TOKEN" --data-urlencode "client_id=YOUR_CLIENT_ID" --data-urlencode "client_secret=YOUR_CLIENT_SECRET"

• 403 with {"error":"unauthorized_client",...}: wrong client_id or client_secret, or the token does not belong to this client_id. Nothing is revoked.