Bem-vindo a API da Monde! Essa documentação detalha os endpoints disponíveis para você integrar seu sistema conosco.
https://web.monde.com.br/api/v3. string, integer, float, boolean, etc. .) como separador decimal, apenas nas últimas duas casas. Exemplo: 99999.99. required. Cada endpoint tem uma etiqueta que indica se você já pode utilizá-lo:
Para acessar os endpoints, é necessário enviar uma credencial válida no cabeçalho Authorization da requisição, com o esquema Bearer.
Exemplo de cabeçalho de autenticação:
Authorization: Bearer bW9uZGV8dXNlcjpwYXNzMTIz
Alguns endpoints desta API utilizam uma chave de idempotência (Idempotency-Key) para garantir que requisições duplicadas (por exemplo, por timeout ou tentativas automáticas) não sejam processadas mais de uma vez.
550e8400-e29b-41d4-a716-446655440000).X-Idempotent-Replay: true.409 Conflict.422 Unprocessable Content), a chave volta a ficar disponível: reenviar a mesma requisição com a mesma chave é processado de novo.422 Unprocessable Content.Para manter o serviço estável para todos, esta API limita quantas requisições cada cliente pode fazer em um curto intervalo de tempo.
429 Too Many Requests e uma mensagem de erro.429, aguarde antes de tentar novamente e use um tempo de espera crescente entre as tentativas (backoff exponencial).As consultas de lista devolvem uma página de registros por vez. O nó pagination da resposta diz o tamanho da página, se existe uma próxima e qual cursor pedir para chegar nela.
cursor.has_next_page for true, repita a requisição enviando cursor com o valor de next_cursor da resposta anterior.has_next_page for false, next_cursor vem nulo e a varredura terminou.size define quantos registros vêm por página: de 1 a 50. Sem o parâmetro, são 20.400.Operações de envio de anexos associados a recursos.
POST /attachments⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
429.
Idempotency-Key e aplique backoff exponencial.
Uma venda é um objeto que representa a comercialização de um ou mais produtos entre uma agência de viagens e seus clientes. Para vender o produto ao cliente, a agência pode adquiri-lo diretamente de um fornecedor ou através de um representante.
GET /sales⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna uma lista paginada de vendas. Por padrão, retorna apenas vendas abertas e fechadas; para incluir vendas excluídas (canceladas), utilize o parâmetro status.
date_field (query): Campo de data usado no filtro. Valores aceitos: sale_date (data da venda), departure_date (início da viagem) e return_date (fim da viagem). Obrigatório quando date_from ou date_to é informado.
date_from (query): Filtrar vendas cujo campo escolhido em date_field seja igual ou posterior a esta data, no formato ISO 8601 (AAAA-MM-DD).
date_to (query): Filtrar vendas cujo campo escolhido em date_field seja igual ou anterior a esta data, no formato ISO 8601 (AAAA-MM-DD).
status (query): Filtrar vendas por situação. Para múltiplas situações, separe os valores por vírgula (ex.: opened,closed,canceled). Valores aceitos: opened (aberta), closed (fechada) e canceled (excluída). Quando o parâmetro não é informado, a API retorna apenas vendas abertas e fechadas; vendas excluídas só são retornadas quando solicitadas explicitamente.
people_id (query): Filtrar vendas pela pessoa participante, informando o identificador (UUID) dela. A venda é retornada quando a pessoa aparece em qualquer papel: pagante, vendedor, intermediário, solicitante, aprovador, promotor, passageiro, fornecedor, representante ou quem cadastrou a venda. Para vários identificadores, separe-os por vírgula — a venda é retornada quando qualquer uma das pessoas participa dela.
number (query): Filtrar vendas pelo número exibido no aplicativo (ex.: 1024). Um número por requisição.
updated_since (query): Filtrar vendas atualizadas neste instante ou depois dele, no formato ISO 8601. Aceita data (AAAA-MM-DD, cai no início do dia) ou data-hora (AAAA-MM-DDTHH:MM:SS). Sem fuso no valor, considera o horário de Brasília. Útil para reprocessar apenas o que mudou desde a última consulta, inclusive no mesmo dia.
POST /sales⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
status: closed para já criar a venda fechada, respeitando as regras de fechamento e a permissão de fechar venda. Sem esse campo a venda nasce aberta.
GET /sales/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna os dados de uma venda específica.
id (path): Identificador único da venda (formato UUID).
Consulte os produtos de viagem disponíveis (seguros, cruzeiros, hotéis, passagens aéreas, operações próprias e outros) para utilizar em suas vendas.
GET /products⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de produtos disponíveis no sistema, com possibilidade de filtrar por tipo de produto.
kind (query): Filtra produtos por tipo. Para múltiplos tipos, separe os valores por vírgula (ex: insurance,cruise,hotel).
GET /products/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna os dados completos de um produto específico, incluindo seus fornecimentos com o fornecedor, os dados de comissão e os representantes.
id (path): Identificador único do produto (formato UUID).
Consulte os tipos de cabine cadastrados no sistema para utilizar em produtos de cruzeiro.
GET /cabins⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de tipos de cabine cadastrados no sistema.
Consulte os navios cadastrados no sistema para utilizar em produtos de cruzeiro.
GET /ships⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de navios cadastrados no sistema.
Consulte os centros de custo cadastrados no sistema para utilizar em lançamentos financeiros.
GET /cost_centers⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de centros de custo cadastrados no sistema.
GET /cost_centers/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna um centro de custo específico pelo seu identificador.
id (path): Identificador único do centro de custo
Consulte as moedas cadastradas no sistema para utilizar em produtos de venda e lançamentos financeiros.
GET /currencies⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de moedas cadastradas no sistema.
GET /currencies/{code}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma moeda específica pelo seu código ISO 4217.
code (path): Código da moeda no padrão ISO 4217
Consulte as categorias financeiras cadastradas no sistema, agrupadas por tipo (receita ou despesa) e grupo.
GET /categories⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de categorias financeiras cadastradas no sistema.
GET /categories/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma categoria financeira específica pelo seu identificador.
id (path): Identificador único da categoria
Consulte as cidades cadastradas no sistema, com estado, país e códigos oficiais (IBGE, SIAFI e SETEC).
GET /cities⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de cidades cadastradas no sistema.
name (query): Filtra por nome, sem diferenciar maiúsculas, acentos ou posição (busca por trecho).
GET /cities/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma cidade específica pelo seu identificador.
id (path): Identificador único da cidade
Consulte os vendedores cadastrados no sistema para utilizar em suas vendas.
GET /sellers⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de vendedores cadastrados no sistema (ativos e inativos).
GET /sellers/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna um vendedor específico pelo seu identificador.
id (path): Identificador único do vendedor
Consulte as formas de pagamento cadastradas no sistema para utilizar em lançamentos financeiros.
GET /payment_methods⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de formas de pagamento cadastradas no sistema. Formas de uso interno do sistema não são retornadas.
GET /payment_methods/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma forma de pagamento específica pelo seu identificador.
id (path): Identificador único da forma de pagamento
Consulte as contas e cartões cadastrados no sistema, com os dados bancários e de cartão de crédito e as empresas em que cada conta está disponível.
GET /accounts⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de contas e cartões disponíveis nas empresas em que a credencial tem permissão. Contas ativas e inativas são retornadas.
GET /accounts/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma conta ou cartão específico pelo seu identificador, desde que disponível em uma empresa em que a credencial tem permissão.
id (path): Identificador único da conta
Consulte as regras de emissão de nota fiscal cadastradas no sistema, com os campos da venda que compõem cada emissão.
GET /nf_rules⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de regras da nota fiscal cadastradas no sistema. Produto, fornecedor e pagante nulos indicam que a regra vale para todos.
GET /nf_rules/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma regra da nota fiscal específica pelo seu identificador.
id (path): Identificador único da regra da nota fiscal
Consulte, crie, altere e exclua tarefas, com responsável, pessoa vinculada, categoria e vencimento, e comente no histórico delas.
GET /tasks⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de tarefas das empresas em que a credencial tem permissão (tarefas sem empresa são visíveis em todas). Tarefas excluídas não são retornadas.
POST /tasks⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Cria uma tarefa na empresa informada em company_identifier, com responsável, categoria e vencimento. Aceita, em history, os comentários com que a tarefa nasce. O responsável é avisado por e-mail, e a tarefa nasce pendente.
GET /tasks/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna os dados de uma tarefa específica, incluindo o histórico e os campos personalizados.
id (path): Identificador único da tarefa (formato UUID).
PATCH /tasks/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Altera uma tarefa já cadastrada. Informe apenas os campos que devem mudar: o campo omitido, ou enviado como nulo ou como texto vazio, permanece como está, então um campo não é esvaziado por esta operação. O title é exceção: a tarefa precisa ter título, e enviá-lo como texto vazio é recusado. Para concluir a tarefa envie completed como true, e para reabri-la, como false. O company_identifier leva a tarefa para outra empresa e exige a permissão de criar/editar tarefas também nela; a tarefa não fica sem empresa por esta operação. Os campos personalizados não substituem: cada um enviado é gravado por cima do atual, e os demais permanecem. Comentários são enviados em Comentar na tarefa. Exige a permissão de criar/editar tarefas. Tarefa excluída não pode ser alterada: a resposta é 409. Quem participa da tarefa é avisado por e-mail da alteração, como na alteração feita no Monde. A resposta traz a tarefa alterada no mesmo formato da consulta por ID quando a credencial também tem a permissão "Ler todas as tarefas" na empresa da tarefa; sem ela, a alteração é gravada do mesmo jeito e a resposta traz apenas o id da tarefa.
id (path): Identificador único da tarefa (formato UUID).
DELETE /tasks/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Exclui a tarefa. A tarefa excluída deixa de aparecer em Consultar tarefas, mas continua disponível na consulta por ID, com deleted igual a true, e não pode mais ser alterada nem receber comentário. Tarefa concluída não pode ser excluída: reabra-a antes, enviando completed como false em Alterar tarefa. Exige a permissão de excluir tarefas na empresa da tarefa. Quem participa da tarefa é avisado por e-mail da exclusão, como na exclusão feita no Monde. Não exige Idempotency-Key: repetir a requisição depois de excluída responde 409.
id (path): Identificador único da tarefa (formato UUID).
POST /tasks/{task_id}/history⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Acrescenta um comentário ao histórico da tarefa e devolve a tarefa com o histórico atualizado — ou apenas o id da tarefa, quando a credencial não tem a permissão "Ler todas as tarefas" na empresa da tarefa. Quem participa da tarefa é avisado do comentário por e-mail, como no comentário feito no Monde. Exige a permissão de criar/editar tarefas. Tarefa excluída não recebe comentário: a resposta é 409. O histórico é só acréscimo: comentário registrado não se altera nem se exclui, e as linhas de alteração que o Monde gera não são enviadas por aqui.
task_id (path): Identificador único da tarefa (formato UUID).
Consulte as categorias de tarefas cadastradas no sistema.
GET /task_categories⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna a lista de categorias de tarefas cadastradas no sistema.
GET /task_categories/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna os dados de uma categoria de tarefa específica.
id (path): Identificador único da categoria de tarefa.
Consulte as viagens cadastradas no sistema, com cliente, vendedor, situação e o período calculado a partir das vendas vinculadas.
GET /travels⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de viagens das empresas em que a credencial tem permissão. As datas e a situação são calculadas a partir dos produtos ativos das vendas vinculadas não canceladas. Aceita filtro por data pelo início ou fim da viagem com os parâmetros date_field, date_from e date_to.
date_field (query): Campo de data usado no filtro. Valores aceitos: start_date (início da viagem) e end_date (fim da viagem), ambos calculados a partir das vendas vinculadas. Obrigatório quando date_from ou date_to é informado.
date_from (query): Filtrar viagens cujo campo escolhido em date_field seja igual ou posterior a esta data, no formato ISO 8601 (AAAA-MM-DD).
date_to (query): Filtrar viagens cujo campo escolhido em date_field seja igual ou anterior a esta data, no formato ISO 8601 (AAAA-MM-DD).
GET /travels/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma viagem específica com seus campos escalares e as referências às vendas e aos passageiros vinculados. Os valores por passageiro pertencem a cada venda, obtidos pelo endpoint da venda.
id (path): Identificador único da viagem a ser obtida
Consulte os orçamentos cadastrados no sistema, com validade, situação e o link público de visualização.
GET /quotes⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de orçamentos das empresas em que a credencial tem permissão.
GET /quotes/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna um orçamento específico pelo seu identificador.
id (path): Identificador único do orçamento
Consulte as regras de faturamento cadastradas no sistema, com a pessoa dona da regra, o período de fechamento e as condições de vencimento.
GET /invoice_rules⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de regras de faturamento cadastradas no sistema. Cada regra pertence a uma pessoa (ou a todas, quando nula) de um dos tipos cliente, fornecedor ou representante.
GET /invoice_rules/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma regra de faturamento específica pelo seu identificador.
id (path): Identificador único da regra de faturamento
Consulte as integrações com fornecedores cadastradas no sistema. As credenciais das integrações nunca são retornadas.
GET /integrations⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de integrações das empresas em que a credencial tem permissão (integrações sem empresa valem para todas). Os dados de acesso da integração (usuários, senhas e tokens) nunca são retornados.
GET /integrations/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna uma integração específica pelo seu identificador.
id (path): Identificador único da integração
Consulte as pessoas cadastradas no sistema, com dados de contato, documentos e informações adicionais.
GET /people⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de pessoas cadastradas. É uma consulta enxuta: traz apenas os escalares próprios e as referências ({id, name}) das entidades fortes (naturalidade, vendedor, promotor, quem cadastrou e a cidade do endereço). As entidades fracas (contatos, marcadores, campos personalizados, anexos, cartões e retenção da Lei Kandir) só aparecem na consulta por ID (GET /people/{id}).
name (query): Filtra por nome, sem diferenciar maiúsculas, acentos ou posição (busca por trecho).
cpf_cnpj (query): Filtra por CPF ou CNPJ (casa contra qualquer um dos dois). Informe só os dígitos, sem pontos, barras, traços ou espaços.
passport_number (query): Filtra por número do passaporte, sem diferenciar maiúsculas ou acentos (busca por trecho).
phone (query): Filtra por qualquer um dos telefones (fixo, comercial ou celular). Informe só os dígitos; casa contra qualquer trecho do número gravado, independente da máscara.
kind (query): Filtra pelo tipo da pessoa: individual (pessoa física) ou company (pessoa jurídica).
code (query): Filtra pelo código sequencial da pessoa (valor exato).
email (query): Filtra por e-mail, sem diferenciar maiúsculas ou acentos (busca por trecho).
POST /people⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Insere uma pessoa física ou jurídica. Cada requisição cria um cadastro novo: o external_id, quando informado, precisa estar livre, e o CPF/CNPJ não pode pertencer a nenhuma pessoa já cadastrada. A resposta traz a pessoa criada no mesmo formato da consulta por ID.
GET /people/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna os dados completos de uma pessoa pelo seu identificador, incluindo os blocos agrupados (dados adicionais, últimos contatos, retenções e companhia aérea) e as entidades fracas (contatos, marcadores, campos personalizados, anexos, cartões de crédito (sempre mascarados), e retenção da Lei Kandir).
id (path): Identificador único (UUID) da pessoa.
PATCH /people/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Altera uma pessoa já cadastrada. Informe apenas os campos que devem mudar: o campo omitido, ou enviado como nulo ou como texto vazio, permanece como está — um campo de texto não é esvaziado por esta operação. O name é exceção: a pessoa precisa ter nome, então enviá-lo como texto vazio é recusado. O tipo da pessoa não muda: person_kind, quando informado, precisa ser o mesmo que a pessoa já é. O external_id passa a identificar a pessoa, desde que não esteja identificando outra; o CPF/CNPJ e o código de companhia aérea não podem pertencer a outra pessoa. As listas labels e contacts funcionam por substituição: a lista enviada passa a ser a da pessoa, a lista vazia retira todos os itens e o campo omitido mantém os atuais. Os campos personalizados não substituem: cada um enviado é gravado por cima do atual, e os demais permanecem. A resposta traz a pessoa alterada no mesmo formato da consulta por ID quando a credencial também tem a permissão "Ler todas as pessoas"; sem ela, a alteração é gravada do mesmo jeito e a resposta traz apenas o id da pessoa.
id (path): Identificador único (UUID) da pessoa.
DELETE /people/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Exclui a pessoa em definitivo. Só pode ser excluída a pessoa que não tem registros vinculados — vendas (como cliente, passageiro, intermediário ou fornecedor), lançamentos financeiros, notas fiscais, orçamentos, tarefas, comissões, cartões, contas, anexos (inclusive os já removidos), entre outros — e que não é usuário do sistema nem empresa do sistema. Nesses casos a resposta é 409 e nada é alterado. Junto com a pessoa são removidos os seus contatos, marcadores e external_id, e os vínculos em que ela aparece como contato de outra pessoa; ela também deixa as regras de faturamento e os centros de custo em que estava, deixa de ser o vendedor ou o promotor de outras pessoas e deixa de estar informada nas integrações em que aparecia. A exclusão fica registrada no histórico da pessoa. Não exige Idempotency-Key: repetir a requisição depois de excluída responde 404.
id (path): Identificador único (UUID) da pessoa.
Consulte os marcadores cadastrados no sistema para classificar pessoas.
GET /labels⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna a lista de marcadores cadastrados no sistema.
GET /labels/{id}⚠️ Esse endpoint ainda não está disponível — está documentado apenas como referência do que temos planejado.
Retorna um marcador específico pelo seu identificador.
id (path): Identificador único do marcador
Consulte as contas a pagar e a receber (lançamentos financeiros) das empresas em que a credencial tem permissão. O mesmo recurso cobre os dois casos: contas a receber (transaction_kind = credit) e contas a pagar (transaction_kind = debit). Traz identificação, valores, situação, categorias, rateios, movimentações de liquidação, itens, comissões, anexos e campos personalizados.
GET /bills⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a lista de contas a pagar e a receber das empresas em que a credencial tem permissão. Por padrão, retorna só as contas em aberto e vencidas (não liquidadas e não canceladas); para incluir liquidadas ou canceladas, use o parâmetro status. Use os filtros para restringir por data (date_field com date_from/date_to), natureza (transaction_kind), tipo (kind) e situação (status). Cada lançamento vem resumido; o detalhe completo vem em GET /bills/{id}.
date_field (query): Campo de data usado no filtro. Valores aceitos: issue_date (emissão), due_date (vencimento) e settlement_date (liquidação). Obrigatório quando date_from ou date_to é informado. Para filtrar por settlement_date, inclua settled no parâmetro status, já que o padrão (open, overdue) não traz contas liquidadas.
date_from (query): Filtrar contas cujo campo escolhido em date_field seja igual ou posterior a esta data, no formato ISO 8601 (AAAA-MM-DD).
date_to (query): Filtrar contas cujo campo escolhido em date_field seja igual ou anterior a esta data, no formato ISO 8601 (AAAA-MM-DD).
transaction_kind (query): Filtra pela natureza do lançamento: credit (contas a receber) ou debit (contas a pagar). Quando ausente, retorna ambas.
kind (query): Origem do lançamento.
normal: lançamento avulso.sale_payment: pagamento de venda.sale_standalone: avulso de venda.vendor_standalone: avulso de fornecedor.vendor_invoice: fatura de fornecedor.customer_invoice: fatura de cliente.credit_card_invoice: fatura de cartão de crédito.commission: comissão.status (query): Filtra pela situação. Aceita um ou mais valores separados por vírgula:
open: não liquidada, não cancelada, com vencimento hoje ou no futuro, ou sem vencimento.overdue: não liquidada, não cancelada, vencimento anterior a hoje.settled: liquidada e não cancelada.canceled: cancelada, independente de ter sido liquidada.open e overdue; liquidadas e canceladas só voltam quando pedidas explicitamente.
number (query): Filtra pelo número do lançamento exibido no aplicativo (um por requisição). Lançamentos parcelados têm sufixo de parcela (ex.: 362-1), então informe o número exatamente como aparece.
GET /bills/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna o detalhe completo de uma conta a pagar ou receber: boleto, categorias, rateio entre empresas, rateio de centro de custo, movimentações de liquidação, itens, cobranças da fatura de cartão, comissões, anexos e campos personalizados.
id (path): Identificador único da conta a pagar ou receber.
Consulte as movimentações das contas e caixas: data, valor, sentido, dados de cheque e de cartão, e as referências para a conta, a forma de pagamento e o lançamento liquidado.
GET /account_movements⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna as movimentações das contas das empresas em que a credencial tem permissão. Cada movimentação vem resumida, só com os dados do próprio movimento; as referências para conta, forma de pagamento, conta a pagar ou receber liquidada, fatura de cartão e conta do outro lado da transferência vêm em GET /account_movements/{id}.
account_id (query): Filtra as movimentações de uma conta específica.
payment_method_id (query): Filtra as movimentações de uma forma de pagamento específica.
transaction_kind (query): ' Filtra pelo sentido do movimento.
credit: entrada de dinheiro na conta.debit: saída de dinheiro da conta.GET /account_movements/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna o detalhe completo de uma movimentação pelo identificador, com as referências para conta, forma de pagamento, conta a pagar ou receber liquidada, fatura de cartão e conta do outro lado da transferência. É o endpoint que resolve as referências a movimentações devolvidas por outros recursos, como as liquidações de uma conta a pagar ou a receber.
id (path): Identificador da movimentação.
Consulte os reembolsos das vendas: lado do reembolso, valor, datas e as referências para a venda, o produto da venda, a pessoa, a empresa e a conta a pagar ou a receber.
GET /refunds⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna os reembolsos das empresas em que a credencial tem permissão.
refund_type (query): ' Filtra pelo lado do reembolso.
customer: reembolso do cliente.vendor: reembolso do fornecedor ou do representante.GET /refunds/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna um reembolso pelo identificador. É o endpoint que resolve as referências a reembolsos devolvidas por outros recursos.
id (path): Identificador do reembolso.
Consulte os recibos e movimentos do extrato CVC: valores, comissões, saldos, datas e as referências para a empresa, o contratante, o vendedor, o intermediário, a venda, o produto da venda, a nota fiscal e quem cadastrou.
GET /cvc_statements⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna os recibos das empresas em que a credencial tem permissão. Recibo excluído não é retornado.
GET /cvc_statements/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna um recibo pelo identificador, incluindo o recibo já excluído, que vem com o campo deleted verdadeiro. É o endpoint que resolve as referências a recibos do extrato CVC devolvidas por outros recursos.
id (path): Identificador do recibo do extrato CVC.
Consulte as notas fiscais de serviço: numeração, situação, datas, valores, retenções e tributos, os dados do tomador gravados na nota (com a referência para a cidade dele), os dados da NFS-e e, na consulta por ID, os itens e as referências para pessoa, empresa, produto da venda e venda.
GET /nfs⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna as notas fiscais das empresas em que a credencial tem permissão. Notas canceladas também são retornadas: o cancelamento aparece na situação. A consulta traz apenas os campos da própria nota; para os itens e as referências, use a consulta por ID.
status (query): ' Filtra pela situação da nota fiscal.
unissued: não emitida.issued: emitida.processing: nota transmitida, aguardando o retorno.processing_cancellation: cancelamento transmitido, aguardando o retorno.awaiting_processing: nota ainda não transmitida, na fila de emissão.canceled: cancelada.awaiting_issue: aguardando emissão.awaiting_cancellation: aguardando cancelamento.period_start (query): Filtra as notas fiscais emitidas a partir desta data, no formato ISO 8601 (YYYY-MM-DD).
period_end (query): Filtra as notas fiscais emitidas até esta data, no formato ISO 8601 (YYYY-MM-DD).
GET /nfs/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna uma nota fiscal pelo identificador, com os itens e as referências para as entidades relacionadas. É o endpoint que resolve as referências a notas fiscais devolvidas por outros recursos.
id (path): Identificador da nota fiscal.
Consulte o histórico de alterações do sistema: a ação registrada, a origem, a descrição da alteração, o momento em que ela foi gravada e, na consulta por ID, as referências para o autor e para o registro auditado.
GET /logs⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna o histórico de alterações do sistema, com filtros por autor, registro auditado, ação e origem. A consulta traz apenas os campos da própria linha; para o autor e o registro auditado, use a consulta por ID. O histórico não é recortado por empresa: a credencial que tem a permissão lê todas as linhas.
person_id (query): Filtra pelo identificador do autor da alteração.
resource_id (query): Filtra pelo identificador do registro auditado.
kind (query): ' Filtra pela ação registrada.
insertion: cadastro do registro.edition: alteração do registro.deletion: exclusão do registro.custom: ação personalizada da tela que gerou o registro.export: exportação de dados.origin (query): Filtra pela origem da alteração, com o valor exato gravado no log. Um valor por chamada.
GET /logs/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna uma linha do histórico pelo identificador, com as referências para o autor da alteração e para o registro auditado.
id (path): Identificador da linha do histórico.
Consulte as definições dos campos personalizados do sistema por recurso (vendas, viagens, pessoas, contas a pagar/receber e tarefas): o identificador, o nome, o tipo, se é obrigatório e as opções cadastradas.
GET /custom_fields⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna as definições dos campos personalizados, opcionalmente filtradas pelo recurso. Cada linha traz o identificador, o recurso, o nome, o tipo, se é obrigatório, se está ativo e, nos campos do tipo lista, as opções cadastradas. As definições não são recortadas por empresa: a credencial que tem a permissão lê todas.
resource (query): ' Filtra pelo recurso (origem) do campo personalizado. Um valor por chamada; ausente lista todos os recursos.
sales: campos de vendas.travels: campos de viagens.people: campos de pessoas.bills: campos de contas a pagar e receber.tasks: campos de tarefas.GET /custom_fields/{id}⚠️ Esse endpoint já pode ser utilizado, mas, por estar em fase de testes (beta), ainda pode sofrer alterações.
Retorna a definição de um único campo personalizado pelo seu identificador. Use para resolver o nome, o tipo e as opções de um campo a partir do id retornado nas demais consultas da API.
id (path): Identificador do campo personalizado a consultar.
A API v3 está em fase beta: já disponível para uso, mas ainda em fase de testes e ajustes — campos e endpoints podem sofrer alterações. Acompanhe esta seção para as mudanças.
redirect_uri quando a agência aprova ou recusa (com o state), e os erros de cada etapa.POST /oauth/revoke, passou a estar documentada: ela exclui a conexão com a agência na hora.Em Inserir pessoa, Alterar pessoa, Inserir venda, Criar tarefa, Alterar tarefa e Comentar na tarefa, o campo enviado num formato diferente do documentado passa a responder 422, com o nome do campo, e nada é gravado. Antes o campo era ignorado e a resposta era de sucesso, sem aquele dado. Vale para a lista ou o objeto enviado como texto, número ou booleano (como "labels": "..."), para o item de lista que não é objeto (como "labels": ["<id>"] no lugar de "labels": [{ "id": "<id>" }]) e para o valor simples enviado como lista ou objeto. O campo nulo ou com texto vazio continua valendo como não enviado.
Em Consultar pessoas e Consultar cidades, o filtro enviado como lista ou valor aninhado (como ?name[]=Ana) passa a responder 400, com o nome do parâmetro. Antes o filtro era ignorado e a consulta devolvia a lista sem ele.
name, que busca pelo nome da cidade por trecho, sem diferenciar maiúsculas, acentos nem a posição do trecho no nome (ex.: ?name=sao paulo). O filtro combina com a paginação e a ordenação por nome.Alterar tarefa passou a estar disponível: altera title, description, due, category_id, assignee_id, person_id e custom_fields de uma tarefa já cadastrada. Informe apenas o que deve mudar — o campo omitido, ou enviado como nulo ou como texto vazio, permanece como está. A exceção é o title: a tarefa precisa ter título, e enviá-lo como texto vazio é recusado. Os campos personalizados enviados são gravados por cima dos atuais, e os demais permanecem.
completed conclui a tarefa (true) ou a reabre (false), e company_identifier leva a tarefa para outra empresa, o que exige a permissão Criar e editar em Tarefas também na empresa de destino.
A alteração exige a permissão Criar e editar em Tarefas e o cabeçalho Idempotency-Key. Quem participa da tarefa é avisado por e-mail, como na alteração feita no Monde.
Excluir tarefa passou a estar disponível: exclui a tarefa, que deixa de aparecer em Consultar tarefas e continua disponível na consulta por ID, com deleted igual a true. Tarefa concluída ou já excluída responde 409, e nada é alterado. Responde 204 sem corpo e não exige Idempotency-Key. Exige a permissão Excluir em Tarefas, que passou a ser oferecida na credencial da API, concedida na empresa da tarefa com licença de API que grave. Quem participa da tarefa é avisado por e-mail.
Tarefa excluída não pode ser alterada nem receber comentário: Alterar tarefa e Comentar na tarefa respondem 409.
Alterar tarefa e Comentar na tarefa respondem apenas com o id da tarefa quando a credencial não tem a permissão Ler todas as tarefas na empresa da tarefa. A gravação acontece do mesmo jeito, com o mesmo status. Quem tem a permissão de ler continua recebendo a tarefa completa, no mesmo formato da consulta por ID.
id da pessoa quando a credencial não tem a permissão "Ler todas as pessoas". A alteração é gravada do mesmo jeito, com o mesmo status 200. Quem tem a permissão de ler continua recebendo a pessoa completa, no mesmo formato da consulta por ID.Criar tarefa passou a estar disponível: informe company_identifier, title, due, category_id e assignee_id, e opcionalmente description, person_id e custom_fields. O responsável precisa ser um usuário ativo do Monde e é avisado por e-mail. A tarefa nasce pendente. Aceita Idempotency-Key para reenvio seguro.
A tarefa pode nascer com os primeiros comentários: envie history, uma lista de { "text": "..." }, no mesmo corpo da criação.
Comentar na tarefa acrescenta um comentário ao histórico de uma tarefa existente e devolve a tarefa com o histórico atualizado. Quem participa da tarefa é avisado por e-mail. O histórico é só acréscimo: não há como alterar nem excluir um comentário já registrado.
As duas escritas exigem a permissão Criar e editar em Tarefas, que passou a ser oferecida na credencial.
Na consulta de tarefas, due e completed_at passaram a sair sem o fuso horário, no mesmo formato de created_at e dos demais campos de data e hora da API: 2026-04-01T09:00:00 no lugar de 2026-04-01T09:00:00-03:00. O horário é o mesmo.
last_contacts.last_task_update_at passou a sair sem o fuso horário, no mesmo formato das demais datas de last_contacts e dos outros campos de data e hora da API: 2026-07-01T15:12:00 no lugar de 2026-07-01T15:12:00-03:00. O horário é o mesmo.POST /sales. Anexos só entram na venda que o próprio parceiro criou.Idempotency-Key. Exige a permissão "Excluir" em Pessoas, que passou a ser oferecida na credencial da API, concedida numa empresa com licença de API que grave.Inserido via API pela credencial "...", Editado via API pela credencial "..." ou Excluído via API pela credencial "...". As linhas seguintes, com os campos alterados, não mudaram. Vale para tudo o que a requisição grava: o registro, os vínculos gravados junto com ele (como os marcadores e os contatos da pessoa) e os lançamentos que a venda gera no financeiro, inclusive os da fatura do fornecedor. Em Consultar logs o person desses logs continua nulo, porque a credencial não é uma pessoa.Registro cadastrado via API, que a API gravava junto de cada cadastro, deixou de existir: quem cadastrou passou a ser a primeira linha do log do próprio registro. Em Consultar logs o cadastro feito pela API passa a trazer um log a menos.external_id passa a identificá-la desde que não esteja identificando outra, e o CPF/CNPJ e o código de companhia aérea não podem pertencer a outra pessoa. Marcadores e contatos funcionam por substituição: a lista enviada passa a ser a da pessoa, a lista vazia retira todos os itens e o campo omitido mantém os atuais. Os campos personalizados não substituem: cada um enviado é gravado por cima do atual e os demais permanecem. Exige a permissão "Inserir e editar" em Pessoas e o cabeçalho Idempotency-Key.other_fees, tip). Antes, o desconto informado no passageiro era gravado mas não abatia total nenhum, e a segunda taxa não entrava no total de taxas. Com isso o valor do produto, o total de descontos, as receitas, o faturamento e o saldo da venda passam a bater com o que o Monde calcula na tela.rav_fee_discount só é aceito quando rav_fee for maior que zero. Enviar o desconto sem a taxa passa a responder 422, como o Monde já recusa na tela.Idempotency-Key: reenviar o mesmo anexo com a mesma chave volta a ser processado, em vez de responder 409 indefinidamente.Enviar anexo passou a aceitar person em resource_type: informe o resource_id da pessoa de destino e o anexo entra no cadastro dela, aparecendo na consulta da pessoa por ID e no download. Exige, em Pessoas, a permissão Adicionar anexos, que passou a ser oferecida na credencial da API, concedida numa empresa com licença de API que grave. O restante do envio não muda: um arquivo por requisição, as mesmas extensões, o mesmo limite de 12 MB e o mesmo Idempotency-Key.
Enviar anexo deixou de exigir a permissão de consultar o recurso de destino: anexar numa venda pede apenas a permissão de anexo em vendas. A resposta muda junto: a venda em que a credencial não pode anexar passa a responder 403, no lugar do 422 "Recurso não encontrado" que saía quando faltava a permissão de consultar vendas. O 422 fica para o resource_id que não existe.
O limite de 10 requisições a cada 3 segundos do envio de anexo passa a contar toda tentativa, inclusive a que é recusada por autenticação, por permissão, por licença, por arquivo grande ou por requisição malformada. Uma sequência de tentativas recusadas agora chega ao 429.
Inserir pessoa passou a estar disponível: insere pessoa física ou jurídica com endereço, naturalidade, documentos e filiação, inscrição municipal, identificação fiscal, observações, cobrança de taxa de boleto, retenção de impostos, dados de companhia aérea, vendedor, promotor, marcadores, contatos e campos personalizados. O external_id é opcional e, quando informado, precisa estar livre; o CPF/CNPJ não pode pertencer a nenhuma pessoa já cadastrada. Exige a permissão "Inserir e editar" em Pessoas e o cabeçalho Idempotency-Key.
Em Consultar pessoa por ID, cada item de custom_fields passou a trazer o id da definição e deixou de trazer o name, como já acontecia na venda e no lançamento financeiro. O nome, o tipo e as opções vêm de Consultar campo personalizado por ID.
Os campos installments (cartão de crédito e boleto) e installment_period (boleto) saíram dos pagamentos destinados à agência em Criar venda. Eles não parcelavam nada: a venda sempre nasceu com um lançamento só, no vencimento informado. Seguem sendo aceitos no corpo da requisição e ignorados, então quem já os envia continua criando vendas do mesmo jeito.
Para parcelar um pagamento à agência, envie um pagamento por parcela no array payments, todos com a mesma forma de pagamento, conta bancária e pagante, cada um com o seu due_date e a sua parte do valor em products[].payment_amount. Cada pagamento vira um lançamento financeiro.
Em vendor.credit_card o installments não mudou: segue sendo informado na criação e devolvido na consulta da venda.
Os nós de pessoa da criação de venda (payer, intermediary, approver, requester, supplier, representative, o person de cada passageiro e o payer de cada pagamento) passaram a aceitar os mesmos campos do cadastro de pessoas: business_phone, website, city_inscription, tax_identification_number, observations, charge_billet_fee, birthplace, additional_data, tax_withholding e airline. Cada campo é aceito no tipo de pessoa a que pertence, e o payload que já era enviado não muda. O charge_billet_fee descreve o cadastro inteiro e só vale quando a venda cria a pessoa: quando o external_id ou o documento já identifica alguém, ele é ignorado. Vendedor, promotor, marcadores, contatos e campos personalizados da pessoa são aceitos apenas em Inserir pessoa.
O campo que traz o documento do produto passou a se chamar document nos produtos em que o Monde escreve "Documento" na tela de cadastro: locação de veículo e pacote de viagem (antes booking_number), seguro viagem (antes voucher_code), bilhete de trem, transporte terrestre e excursão (antes locator). Em pacote CVC o mesmo campo passou a se chamar receipt_number, o "Recibo Nº" da tela.
Os produtos cujo rótulo na tela já era outro não mudaram: bilhete aéreo segue com locator ("Localizador"), hospedagem segue com booking_number ("Reserva"), cruzeiro segue com booking_number ("Booking"), e outros e operação própria já usavam document.
Na criação de vendas, o documento do passageiro passou a ser informado em document, no lugar de ticket_number, nos produtos em que o Monde tem esse campo: seguro viagem, transporte terrestre, bilhete de trem, pacote de viagem e operação própria. O ticket_number continua sendo o número do bilhete do passageiro do aéreo, na leitura e na criação, e o ticket_number de cada assento em ground_transportations[].segments[].seats[] não mudou.
O document do produto passou a aceitar 40 caracteres em todos os produtos, o mesmo tamanho que o Monde grava. Em transporte terrestre e bilhete de trem o limite era de 20.
Os nomes antigos seguem aceitos na criação de vendas e seguem saindo na leitura, mas saíram da documentação, que passa a descrever só o nome novo. Eles serão removidos em uma etapa seguinte, com tempo para as integrações existentes se ajustarem.
Em Criar venda, o campo travel_agent passou a se chamar seller, o mesmo nome que a consulta da venda já usa e o mesmo termo do Monde.
Na consulta de vendas, o passageiro de Outros, Excursão e Operação Própria passou a trazer o document, que já é preenchido no Monde mas não era devolvido. Nesses mesmos três produtos, o other_fees saiu da resposta, porque eles não têm uma segunda taxa por passageiro. Em Operação Própria também saíram rav_fee, rav_fee_discount e agency_fee, que o produto não cobra do passageiro. Locação de Veículo não mudou.
O kind dos produtos passou a trazer excursion (excursão) e cvc_package (pacote CVC). Os pacotes CVC vinham sem tipo na resposta.
O filtro ?kind= passou a aceitar cvc_package e excursion, e é descrito como lista de valores: vários tipos separados por vírgula, como em ?kind=insurance,cruise. A chamada não muda.
Em Consultar produto por ID, o campo restitutes_lei_kandir de cada fornecimento passou a se chamar restitutes_kandir_law. O valor não muda.
Os produtos de sistema passaram a aparecer nos exemplos com system: true, e a descrição do campo foi corrigida: produto de sistema não pode ser excluído, mas pode ser editado.
Criar venda: o cargo da comissão no array commissions passou a ser informado pelo campo kind (seller, intermediary ou person), em vez de job_title_id (UUID). seller e intermediary gravam o cargo de sistema correspondente; person grava sem cargo. O external_id do destinatário continua obrigatório.
Na criação de vendas, o campo ticket_number do passageiro passou a ser aceito em operação própria, bilhete de trem e pacote de viagem, gravando o documento do passageiro — a mesma coluna que a consulta desses produtos devolve em document.
O filtro ?status= passou a ser descrito como lista de valores: vários status separados por vírgula, como em ?status=opened,closed. A chamada não muda.
?status= passou a ser descrito como lista de valores: vários status separados por vírgula, como em ?status=open,overdue. A chamada não muda.multipart/form-data, informando resource_type (por ora sale) e o resource_id da venda de destino, além de file e um description opcional. Valida a extensão (pdf, imagens, arquivos office, txt, csv), o tamanho máximo de 12 MB e o conteúdo real do arquivo. O anexo passa a aparecer na consulta da venda e no download. Aceita Idempotency-Key para reenvio seguro.payer de cada pagamento passou a aceitar um objeto de pessoa completo, o mesmo do pagante da venda, e cria a pessoa quando ela ainda não existe. Antes, só referenciava por external_id alguém já cadastrado. Repetir o external_id do pagante da venda resolve para a mesma pessoa. Quando omitido, o pagamento segue herdando o pagante da venda.Bearer no cabeçalho Authorization. A credencial é a mesma e não precisa ser reemitida, então as integrações em produção seguem funcionando. Use Bearer daqui em diante.Em Criar venda, o external_id dos produtos passou a se chamar local_id, e o mesmo vale para cada item de payments[].*.products[]. O local_id é uma chave de correlação válida apenas dentro da requisição: precisa ser único entre os produtos daquela venda, não é armazenado e pode ser reutilizado em vendas seguintes. Ele aceita apenas texto.
Na leitura de Listar vendas e Obter venda por ID, os produtos deixaram de trazer o external_id. O identificador do produto na leitura é o id.
next_cursor no nó pagination, e para pedir a próxima página basta devolvê-lo no parâmetro cursor, enquanto has_next_page for verdadeiro. Veja a seção de Paginação. O parâmetro page continua funcionando como antes para quem já integrou, mas não é mais a forma divulgada: pelo page o custo de cada página cresce com a profundidade da varredura, e pelo cursor não cresce. Quem pagina por cursor não recebe mais page no nó pagination.client_secret é exibido uma única vez e não é mais enviado por e-mail. A página também traz o snippet do botão "Conectar com o Monde".POST /oauth/homologation (HTTP Basic com client_id e client_secret). Enquanto pendente, a autorização não funciona; ao responder 200, passa a ativo. Veja a seção Credenciamento de fornecedores.payer em cada pagamento (cartão de crédito, boleto e depósito na agência; cartão, crédito e outros no fornecedor), referenciando por external_id a pessoa que efetivamente paga aquele pagamento — tipicamente o responsável financeiro informado na venda. Na agência, a Conta a Receber gerada usa esse pagante como Pessoa; no fornecedor, o pagante vai no lançamento da Conta a Pagar. Quando omitido, o pagamento herda o pagante da venda. Um external_id que não corresponde a nenhuma pessoa cadastrada devolve 422.requester (solicitante), para registrar quem pediu a venda junto da criação. É pessoa física, campo opcional, resolvido por external_id (find-or-create), como os demais papéis.commissions, para gravar comissões manuais (vendedor, intermediário ou outra função) junto da venda. O destinatário é referenciado por external_id, o mesmo informado no vendedor/intermediário; o cargo vai em job_title_id. Só é aceito quando status é closed; comissão de cargo intermediário exige que a venda tenha intermediário.cpf_cnpj. Antes, o conflito de documento estourava erro interno (500).included_services do produto da venda não é enviado, o texto do cadastro do produto é gravado; quando é enviado, o texto informado é acrescentado ao do cadastro. Antes, o campo do produto da venda ficava com apenas o que a requisição enviava.number (um por requisição): informe o número exibido no aplicativo e a consulta devolve a venda correspondente sem precisar traduzir número em UUID antes. Número não inteiro devolve 400.updated_since (data ou data-hora ISO 8601, ex.: 2026-08-01 ou 2026-08-01T14:30:00; sem fuso, considera Brasília): devolve as vendas atualizadas nesse instante ou depois, para reprocessar só o que mudou desde a última consulta, inclusive no mesmo dia. Um valor inválido devolve 400.date_field + date_from/date_to: escolha a data em date_field (start_date ou end_date, o início e o fim da viagem calculados a partir das vendas vinculadas) e informe o intervalo fechado inclusivo em date_from/date_to (ISO YYYY-MM-DD, ambos opcionais). date_field é obrigatório quando há alguma data; data em formato inválido, intervalo invertido (date_from maior que date_to) ou date_field fora da lista devolvem 400. Viagem sem vendas vinculadas não tem datas calculadas e nunca aparece em um intervalo de datas.number (um por requisição): informe o número do lançamento exibido no aplicativo. Lançamentos parcelados têm sufixo de parcela (ex.: 362-1), então informe o número exatamente como aparece.date_field + date_from/date_to: escolha a data em date_field (issue_date = emissão, due_date = vencimento, settlement_date = liquidação) e informe o intervalo fechado inclusivo em date_from/date_to (ISO YYYY-MM-DD, ambos opcionais). date_field é obrigatório quando há alguma data; data em formato inválido, intervalo invertido (date_from maior que date_to) ou date_field fora da lista devolvem 400. Filtrar por settlement_date traz só contas liquidadas (as não liquidadas não têm data de liquidação e ficam de fora do intervalo); como o status padrão (open, overdue) exclui liquidadas, inclua settled no parâmetro status ao usar settlement_date.status. O padrão continua opened; envie closed para já criar a venda fechada. O fechamento respeita todas as regras existentes (sem saldo pendente, e na base consolidadora o intermediário é obrigatório) e exige a permissão de fechar venda na credencial. Se a venda não puder ser fechada, a criação inteira é recusada com 422 e nada é gravado.Consultar vendas passou a filtrar por data com date_field + date_from/date_to: escolha a data em date_field (sale_date, departure_date ou return_date) e informe o intervalo fechado inclusivo em date_from/date_to (ISO YYYY-MM-DD, ambos opcionais). Substitui period_start/period_end, que foram removidos. date_field é obrigatório quando há alguma data; data em formato inválido, intervalo invertido (date_from maior que date_to) ou date_field fora da lista devolvem 400.
Na resposta da venda, period_start e period_end viraram departure_date e return_date — mesmos valores (início e fim da viagem, calculados pela menor e maior data dos produtos).
excursions.fees) passou a ser aceito em todos os produtos com passageiros — seguro viagem, cruzeiro, hospedagem, transporte terrestre, aluguel de carro, trem, pacote de viagem e operação própria —, alinhado ao que a leitura já usa. rav_fee, rav_fee_discount e agency_fee passaram a ser aceitos nos mesmos produtos, exceto operação própria, cujo passageiro só tem valor e taxa; other_fees (hospedagem, aluguel de carro, pacote de viagem) e tip (cruzeiro) também passaram a ser aceitos. Nos produtos que tinham nome próprio para a taxa principal — service_fee (hospedagem e transporte terrestre) e booking_fee (trem) —, os nomes antigos continuam aceitos por enquanto, mas saem da documentação em favor de fees.totals.balance: vendas criadas pela Criar venda vinham sempre com saldo 0 na leitura, mesmo tendo saldo em aberto real. Passa a refletir o saldo correto tanto na consulta em lista quanto na consulta por ID.kandir_law: a retenção de imposto por produto (valor, taxa de embarque, taxa DU/RAV e taxa de serviço, cada uma com o detalhamento por imposto — IR, CSLL, PIS e COFINS — e o total, nos regimes nacional e internacional), com a referência ao produto. Só existe para pessoa jurídica; vem null para pessoa física.city_inscription e tax_identification_number voltaram para o nível raiz da pessoa. Estavam dentro de additional_data, que só existe para pessoa física, mas os dois são dados de pessoa jurídica.closing.period_kind, o valor separate virou standalone. "Avulso" é o fechamento que deixa cada venda em uma fatura própria, e standalone é como a API já nomeia esse mesmo conceito no kind do lançamento financeiro.id; em Consultar conta a pagar ou receber por ID, credit_card_items[].id deu lugar à referência movement._summary, e o nome sem sufixo passou a ser o da consulta por ID.registered_at virou created_at em vendas, contas a pagar e receber, notas fiscais, regras da nota fiscal, tarefas, viagens, vendedores, pessoas, extrato CVC e logs — o nome mais comum para esse conceito no restante das APIs REST.registered_by virou created_by, pelo mesmo motivo, em vendas, contas a pagar e receber, notas fiscais, regras da nota fiscal, tarefas, viagens, vendedores, pessoas e extrato CVC.Ajuste do padrão de leitura em vários endpoints, na mesma direção da entrada de 2026-08-11: a consulta em lista traz os campos do próprio registro, e as associações — referências e dados de outras entidades — ficam na consulta por ID.
rg_ie, passport_number, passport_expiration_date, foreigner, foreign_identity_document, business_phone, website, cvc_code, observations, charge_billet_fee, registered_at e os nós additional_data, last_contacts, tax_withholding e airline.gender e birthdate, nas duas leituras.birthplace, seller, promoter, registered_by, contacts, labels, custom_fields, attachments e credit_cards.id: são dados que só existem dentro da pessoa.masked_number virou last_digits e passou a trazer só os quatro últimos dígitos, sem a máscara.billet, check e card, que antes só existiam na consulta por ID. São dados do próprio lançamento.credit_card_items, o id — que era o identificador da movimentação, não da linha — deu lugar à referência movement, resolvida em Consultar movimentação por ID.id. O item não tem consulta própria, e o identificador não resolvia nada.state e country saíram de Consultar cidades e ficaram em Consultar cidade por ID.group saiu de Consultar categorias e ficou em Consultar categoria por ID.bank saiu de Consultar contas e cartões e ficou em Consultar conta ou cartão por ID.kind passou a declarar os valores possíveis: insertion, edition, deletion, custom e export. Não há outros.person passou a indicar Consultar pessoa por ID, o endpoint que resolve a referência.travel, resolvida em Consultar viagem por ID. O vínculo existia só no sentido inverso.active, e Tarefas, deleted.payer_rule, supplier_rule e representative_rule, o recipient passou a vir antes de revenues e discounts.people_id: retorna as vendas em que a pessoa informada participa em qualquer papel (pagante, vendedor, intermediário, solicitante, aprovador, promotor, passageiro, fornecedor, representante ou quem cadastrou a venda). Aceita vários identificadores separados por vírgula — a venda entra quando qualquer uma das pessoas participa.Novos endpoints de leitura das definições de campos personalizados: Consultar campos personalizados e Consultar campo personalizado por ID. A consulta lista os campos personalizados por recurso (sales, travels, people, bills e tasks), com o identificador, o nome, o tipo, se é obrigatório, se está ativo e as opções cadastradas dos campos do tipo lista, e aceita o filtro resource; a consulta por ID resolve a definição de um campo a partir do id. As definições não são recortadas por empresa. O identificador de cada campo é numérico (não é um UUID como no resto da API).
O nó pagination deixou de trazer total e total_pages, e passou a trazer has_next_page. Para percorrer uma consulta inteira, peça a próxima página enquanto has_next_page for verdadeiro. O pedido não muda: page e size funcionam como antes. Contar o total exigia percorrer todos os registros que atendiam ao filtro a cada requisição, o que em bases grandes custava mais do que buscar a própria página.
Toda leitura passou a ter duas formas: uma consulta em lista, enxuta, para extrair volume, e uma consulta por ID, com o registro completo. As associações não vêm mais embutidas: vêm como referência, só com o identificador. A descrição de cada referência indica o endpoint que a resolve, e referências e coleções aparecem apenas na consulta por ID. As mudanças estão agrupadas por endpoint.
As consultas por ID novas estão documentadas antes de existirem: cada uma leva a etiqueta Em desenvolvimento até o código entrar. As consultas em lista que já existiam seguem em Beta, disponíveis para uso.
financial saíram da lista e continuam em Consultar venda por ID, que é também onde ficam as referências: pagante, vendedor, empresa, intermediário, solicitante, aprovador, promotor, operação e quem cadastrou.sale_id virou id. travel_agent virou seller, e a referência aponta para Consultar vendedor por ID — o id é o mesmo de antes, porque o vendedor compartilha o identificador da pessoa; para os dados de pessoa, use o mesmo id em Consultar pessoa por ID.company_identifier, que era o CNPJ copiado da empresa e dá lugar à referência company (na criação continua obrigatório), totals.payments e o role das comissões.value, retained_value e leftover viraram amount, retained_amount e balance; nos totais, final_value virou final_amount; nos repasses ao fornecedor, value virou amount.payments deixou de ser lista e virou um objeto com agency e vendor. Em agency, bills e refunds são listas de referência, resolvidas em Consultar conta a pagar ou receber por ID e em Consultar reembolso por ID; credit, retained_by_intermediary e legacy vêm embutidos, porque não geram lançamento financeiro. Em vendor, há uma lista por forma: credit_card, check, credit e others.cash, check, credit_card, debit_card, bank_slip, bank_deposit, others, custom e invoice). Todos eles geram um lançamento, e é o lançamento que traz a forma de pagamento, a conta, a liquidação, o boleto e os produtos cobertos. Um lançamento liquidado em várias formas aparece uma vez, e cada liquidação vem em movements, no próprio lançamento.products traz agora amount e a referência sale_product, no lugar de external_id e payment_amount. Todo pagamento embutido ganhou payer, que pode ser diferente do pagante da venda.financial, vendor virou vendor_bills e bills virou standalone_bills — as duas agora listas de referência aos lançamentos. Os itens e valores vêm do próprio lançamento.operation da venda é a referência à operação própria do cabeçalho, e o detalhe do produto de operação própria fica na coleção operations, junto dos demais produtos. Na entrada de 2026-08-07 esse campo passou a trazer o produto inteiro quando havia linha; agora ele é sempre referência.id, o que torna resolvível a referência sale_product do lançamento, da nota fiscal, do reembolso e do extrato CVC. Nos tipos others, operation e cvc_package, saíram product_name e product_with_passengers e entrou a referência product; nos outros oito tipos existe um único produto de sistema por tipo, e o nome do array já identifica qual é.currency é um código ISO (texto) na criação e na consulta; o objeto currency completo ficou exclusivo de Moedas. Nos produtos da venda, currency e exchange_rate são campos de criação: na consulta devolvem sempre BRL e 1, e os valores vêm convertidos para Real.custom_fields, cada campo passou a trazer o id da definição e deixou de trazer o name. O nome, o tipo e as opções vêm da consulta de definições de campos personalizados.description nos pagamentos de agência (cartão de crédito, boleto e depósito). Quando informado, o texto é gravado no lançamento financeiro; quando omitido, continua sendo usado "Pagamento venda". Máximo de 60 caracteres.check e card, com os dados de cheque e de cartão informados no cadastro. Antes eles só apareciam na venda, e ficavam inacessíveis enquanto o pagamento não fosse liquidado.kind, sale_separate e vendor_separate viraram sale_standalone e vendor_standalone. O filtro kind aceita os novos valores.custom_fields, cada campo passou a trazer o id da definição e deixou de trazer o name, como na venda.external_id passou a constar na consulta: a resposta já trazia o identificador que você atribuiu à pessoa, mas ele não estava documentado. Vem nulo quando a credencial que consulta não tem identificador externo para aquela pessoa.name, cpf_cnpj, passport_number, phone, kind (individual ou company), code e email. Todos são opcionais e combináveis (E lógico entre eles): name, passport_number e email casam por trecho, ignorando maiúsculas e acentos; cpf_cnpj e phone aceitam só os dígitos (a máscara é ignorada) e code é valor exato. Sem nenhum filtro, o comportamento é o mesmo de antes.supplies: cada um traz o fornecedor, os dados de comissão e os representantes.commission_value virou commission_amount, e commission_type passou a aceitar amount em vez de value.history (comentários e alterações) e os campos personalizados.category deixou de ser texto e virou referência, resolvida em Consultar categoria de tarefa por ID.client virou customer, e seller passou a apontar para o endpoint de vendedores.seller passou a apontar para Consultar vendedor por ID.status, que é derivável de active e valid_until, ambos ainda na resposta.attachment_id virou id.person.name, e o país, code (ISO 3166-1 alfa-2) e code_3 (alfa-3).labels da pessoa e category da tarefa.Criar venda passou a aceitar campos personalizados no campo custom_fields (array de {id, value}). O id é o mesmo retornado por Consultar campos personalizados; o value deve corresponder ao tipo do campo (número inteiro para numérico, número para monetário, data ISO 8601, texto para os demais). ⚠️ Campos ativos e obrigatórios do módulo de vendas passam a ser exigidos: o create devolve 422 se um deles não vier com valor.
Na leitura de vendas e de lançamentos financeiros, cada item de custom_fields passou a ser {id, value}: traz o id do campo (a referência) e o value, e deixou de trazer o name. O nome, o tipo e o restante da definição são obtidos em Consultar campo personalizado por ID ou em Consultar campos personalizados, para o consumidor sempre ler a referência e não um dado projetado que pode desatualizar.
Criar venda passou a aceitar o produto de operação própria no campo operation (objeto único; no máximo um por venda). O produto é informado por product_id e, conforme a configuração dele, os valores vão por passengers ou por quantity × unit_price (com unit_fee e a taxa de serviço oculta agency_fee, um valor único da linha); o fornecedor é a própria empresa da venda.
Na leitura (Listar vendas e Obter venda por ID), o campo operation passou a trazer o detalhe completo do produto de operação própria; antes trazia só id e name.
Novos endpoints de leitura do histórico de alterações: Consultar logs e Consultar logs por ID. A consulta traz a ação registrada, a origem, a descrição da alteração e o momento em que ela foi gravada, com filtros por autor, registro auditado, ação e origem; a consulta por ID acrescenta as referências para o autor e para o registro auditado. O histórico não é recortado por empresa.
Os itens de Obter conta a pagar ou receber por ID mudaram: customer_items e vendor_items foram substituídos por um único items, que traz todos os itens do lançamento, inclusive os de pagamento de venda, que antes não saíam em array nenhum. O item passou a trazer só as próprias colunas (description, cost_center, checked, amount) mais as referências sale, sale_product e cvc_statement; os dados do produto da venda saíram, e a fonte deles é Obter venda por ID.
Cada linha de credit_card_items passou a trazer id e a referência bill, e perdeu description e person. O id é o da movimentação, então dá para consultá-la em Obter movimentação por ID.
Cada linha de commissions ganhou a referência person, e o campo leftover passou a se chamar balance.
O lançamento perdeu sale_number, balance, status, overdue_days e settled_late, e ganhou canceled, checked, invoice_closed, system_generated e recurrence_group_id. A visualização por ID ganhou as referências sale e invoice_rule. No filtro status, o valor paid passou a settled.
Novos endpoints de leitura do extrato CVC: Consultar extrato CVC e Consultar extrato CVC por ID. A consulta traz o número do recibo, as datas de movimentação, venda, cancelamento, embarque e retorno, o nome do produto, o nome do pacote, os totais, as comissões, o depósito, os saldos e as marcas de importado, editado, conferido e excluído; a visualização por ID acrescenta o tipo do movimento e as referências para empresa, contratante, vendedor, intermediário, venda, produto da venda, nota fiscal e quem cadastrou. Recibo excluído fica fora da consulta, mas continua acessível por ID. Escopo por empresa.
Novos endpoints de leitura de notas fiscais: Consultar notas fiscais e Consultar notas fiscais por ID. A consulta traz numeração, situação, natureza da operação, datas, valores, os dados do tomador gravados na nota com a referência para a cidade dele, as retenções e tributos e os dados da NFS-e, com filtros de situação e de período de emissão; a visualização por ID acrescenta os itens da nota e as referências para pessoa, empresa, produto da venda, venda e quem cadastrou ou cancelou. Escopo por empresa.
Novos endpoints de leitura de reembolsos: Consultar reembolsos e Consultar reembolsos por ID. Trazem o lado do reembolso (cliente ou fornecedor), o valor, a descrição, a emissão e o vencimento, e a visualização acrescenta as referências para venda, produto da venda, pessoa, empresa e conta a pagar ou a receber, com escopo por empresa.
attachments: cada anexo traz id, description, extension, content_type e download_url, com o conteúdo acessível por um link de download temporário.operation (objeto com id e name); antes o identificador vinha em operation_id.commissions: o rateio por pessoa e função (vendedor, intermediário e outros), com valor da comissão, valor retido e saldo.financial: observações financeiras, os repasses aos fornecedores e os lançamentos de contas a pagar e a receber vinculados à venda.Além do Basic Auth, um parceiro homologado pelo Monde pode acessar a API v3 em nome de uma agência de viagens, via OAuth 2.0 (Authorization Code + PKCE), sem que a agência compartilhe a senha de uma credencial. O que o parceiro pode fazer é definido na homologação, e a agência vê e aprova essa lista ao autorizar.
Todos os endpoints desta seção ficam em https://web.monde.com.br.
redirect_uri.redirect_uri é uma só por parceiro e precisa usar https. Ela precisa ser idêntica, caractere por caractere, na autorização e na troca do token (uma barra no fim já é diferença). Endereços http, inclusive localhost e 127.0.0.1, não são aceitos.client_id e o client_secret aparecem nessa página; o secret é exibido uma única vez, então guarde-o na hora. Se precisar vê-lo de novo, solicite a regeneração ao Monde.client_secret só no seu backend. Ele nunca vai para o navegador nem para o app do usuário.client_id e client_secret (HTTP Basic). Enquanto a homologação está pendente, a autorização não funciona. curl -X POST https://web.monde.com.br/oauth/homologation -u "SEU_CLIENT_ID:SEU_CLIENT_SECRET"
200 com {"status":"active"}: a conexão passa a ativa. Chamar de novo devolve a mesma resposta.401 com corpo vazio: client_id ou client_secret errado, ou parceiro desativado pelo Monde.state e um code_verifier novos e guarde os dois na sessão do usuário. O code_verifier é um texto aleatório de 43 a 128 caracteres; o code_challenge é BASE64URL(SHA256(code_verifier)), sem o = no fim. PKCE é obrigatório e só aceita S256: ele é o que impede outro sistema de trocar um code interceptado. 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')Redirecione o usuário da agência para a URL de autorização, com os valores codificados para URL:
GET https://web.monde.com.br/oauth/authorize?response_type=code&client_id=SEU_CLIENT_ID&redirect_uri=SUA_REDIRECT_URI&state=STATE&code_challenge=CODE_CHALLENGE&code_challenge_method=S256
scope: o que o parceiro pode fazer vem da homologação.client_id não é de um parceiro ativo e homologado, se a redirect_uri não é a cadastrada, ou se falta o code_challenge ou o code_challenge_method não é S256, o Monde responde 400 numa página própria e não volta para a redirect_uri.redirect_uri com o code e o mesmo state que você enviou: SUA_REDIRECT_URI?code=agencia%7CujES3JCJylJRoM3j_kGeavaD2hFqz2oqw1Lazq_u0rs&state=STATEQuando a agência recusa:
SUA_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
state com o da sessão. Se for diferente ou faltar, descarte a resposta.code é opaco. Use o valor decodificado da URL do jeito que veio, sem cortar nem trocar caracteres. Ele vale 10 minutos e só pode ser trocado uma vez.redirect_uri quando quem entrou não é administrador da agência, nem quando a empresa não tem a licença de API que as permissões do parceiro exigem. Nesses casos o usuário vê a explicação numa página do Monde.href aponta para a URL de autorização que você monta no seu backend a cada acesso, com um code_challenge PKCE novo (passo 2 acima), nunca um link estático. O símbolo do Monde é hospedado por nós: https://web.monde.com.br/logo-monde-conectar.svg (colorido, para fundo claro) e https://web.monde.com.br/logo-monde-conectar-branco.svg (branco, para fundo azul). Três variações: <a href="URL_DE_AUTORIZACAO" 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"> Conectar com o Monde</a>
<a href="URL_DE_AUTORIZACAO" 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"> Conectar com o Monde</a>
<a href="URL_DE_AUTORIZACAO" 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">Conectar com o Monde</a>
application/x-www-form-urlencoded; o mesmo corpo em JSON (application/json) também é aceito. 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=SUA_REDIRECT_URI" --data-urlencode "client_id=SEU_CLIENT_ID" --data-urlencode "client_secret=SEU_CLIENT_SECRET" --data-urlencode "code_verifier=CODE_VERIFIER"Resposta
200: { "access_token": "YWdlbmNpYXw2ZjFj...", "token_type": "Bearer", "scope": "full_access", "created_at": 1790602784 } O access_token não expira e não vem refresh_token. Guarde-o no backend, um por agência conectada, e trate-o como senha. 400 com {"error":"invalid_grant","error_description":"..."}: code vencido ou já trocado, code_verifier que não corresponde ao code_challenge, ou redirect_uri diferente da usada na autorização. Recomece pela autorização.400 com {"error":"invalid_request","error_description":"..."}: o code_verifier não foi enviado.401 com {"error":"invalid_client","error_description":"..."}: client_id ou client_secret errado.404 com corpo vazio: o code chegou alterado.https://web.monde.com.br/api/v3 com o token no cabeçalho Authorization (o token já carrega a agência). Authorization: Bearer SEU_ACCESS_TOKENPara confirmar que a conexão funciona sem criar dado, chame
GET /api/v3/sales com o token: curl https://web.monde.com.br/api/v3/sales -H "Authorization: Bearer SEU_ACCESS_TOKEN" -H "Content-Type: application/json"
403 com {"errors":["Você não tem permissão para executar essa ação."]}: o token é válido e a integração está pronta. O parceiro cria vendas, mas não as lê.401 com {"errors":["Credenciais de acesso não são válidas."]}: o token é inválido ou a conexão foi excluída. Recomece pela autorização.POST /sales.401.curl -X POST https://web.monde.com.br/oauth/revoke --data-urlencode "token=SEU_ACCESS_TOKEN" --data-urlencode "client_id=SEU_CLIENT_ID" --data-urlencode "client_secret=SEU_CLIENT_SECRET"A resposta é
200 com {}. A conexão com a agência é excluída na hora e o token para de funcionar. Para conectar de novo, recomece pela autorização. 403 com {"error":"unauthorized_client",...}: client_id ou client_secret errado, ou o token não pertence a este client_id. Nada é revogado.