Skip to main content
A referência é agrupada por serviço. Cada serviço é uma API separada com sua própria URL base, listada em cada página de endpoint:
Shortlinks é a exceção: ele roda no domínio customizado api.links.portao3.com.br e está disponível apenas em produção (sem servidor de desenvolvimento).

​
Autenticação

A menos que um endpoint indique o contrário, toda requisição exige um token JWT bearer emitido pelo serviço Identity:
Consulte o Início rápido para saber como obter e renovar tokens. Alguns endpoints são públicos por design — por exemplo, os endpoints de login e recuperação de senha sob /auth, verificações de saúde de serviço (GET /health) e as páginas de checkout hospedadas para links de pagamento. Algumas operações sensíveis também exigem o PIN de transação do usuário em um cabeçalho pin — consulte Autenticação na introdução.
Alguns fluxos de autenticação carregam mais opções do que o esquema gerado mostra atualmente: POST /auth/sign-in também aceita credenciais de cliente de API (HTTP Basic + grantType: "client_credentials"), e POST /auth/confirm-mfa recebe email, userCode e session. O Início rápido documenta esses fluxos de ponta a ponta.

​
Multi-tenancy

Endpoints cujo caminho começa com /realms/{realmId}/organizations/{organizationId}/ têm escopo de tenant: o token que você envia deve pertencer àquele realm e ter permissão para aquela organização. Seus IDs são fornecidos durante o onboarding.

​
Como ler a referência

Estas páginas são geradas diretamente do código-fonte da API, portanto caminhos, métodos e parâmetros sempre refletem as APIs implantadas. Os esquemas de requisição e resposta estão sendo disponibilizados progressivamente:
  • Endpoints com um corpo de requisição ou resposta documentado mostram o esquema exato que a API valida — nomes de campos, tipos, formatos e valores de enum permitidos vêm diretamente do código.
  • Endpoints ainda sem um corpo documentado continuam listados com seu caminho completo, parâmetros e requisitos de autenticação, mas o formato do corpo é omitido em vez de suposto. A cobertura se expande a cada release.
Os serviços com a cobertura tipada mais rica hoje são Identity, Scheduling, Accounting, Customer, Platform e Rule Engine.
Precisa de um esquema que ainda não está documentado? Envie um e-mail para suporte@portao3.com.br e nós o priorizaremos.

​
Endpoints internos

A referência é gerada a partir da superfície completa da API, então também lista um pequeno número de endpoints que dão suporte às próprias operações do Portão 3 — caminhos sob /support ou /internal, e receptores de webhook para nossos provedores de pagamento. Eles aparecem por completude, mas não fazem parte de uma integração típica e a maioria não está disponível para credenciais de clientes.

​
Serviços

Não sabe por onde começar? Billing gerencia o ciclo de vida de acordos e faturas entre você e suas contrapartes; Payment Links & Checkout é para coletar pagamentos avulsos por meio de uma página hospedada; Banking é onde o dinheiro efetivamente se movimenta (PIX, boleto, carteiras, cartões).

​
Travel

O serviço Travel agrupa as APIs de viagem corporativa em quatro verticais — aéreo, hotel, ônibus e veículo:
  • Proxy de busca — POST /travel/{vertical}/searches e os respectivos endpoints GET distribuem uma única consulta para os provedores de inventário de cada vertical e retornam ofertas normalizadas.
  • Diretório de passageiros — /travel/passengers armazena perfis reutilizáveis de viajantes (documentos, contato, campos personalizados) que as viagens referenciam por ID.
  • Ciclo de vida da viagem — /travel/trips e /travel/trips/{tripId}/items/{itemId} modelam uma viagem como um contêiner de itens (um por segmento reservado) que percorrem uma máquina de estados criar → emitir → cancelar, com history para auditoria.
  • Receptor de webhook TaaS — callbacks de provedores Travel-as-a-Service caem em um receptor de webhook interno que avança o estado dos itens de forma assíncrona, então você pode confiar no estado da viagem e do item em vez de consultar os provedores diretamente.
O Travel emite uma família de eventos TRAVEL_RESERVATION_* (created, issued, cancelled e estados relacionados) que o serviço Notification consome para enviar e-mails transacionais a viajantes e administradores.