> ## Documentation Index > Fetch the complete documentation index at: https://developers.portao3.com.br/llms.txt > Use this file to discover all available pages before exploring further. # Referência da API > Como a referência da API do Portão 3 está organizada e como lê-la 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: ```text theme={null} https://api..v2.portao3.com.br ``` **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: ```text theme={null} Authorization: Bearer ``` Consulte o [Início rápido](/quickstart) 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](/#authentication) 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](/quickstart) 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](mailto: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 | Serviço | O que você pode fazer | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Identity** | Fazer login e renovar tokens, gerenciar usuários, organizações, MFA e clientes de API | | **Banking** | Gerenciar contas, carteiras e cartões; enviar e receber PIX; emitir e pagar boleto; consultar o razão de transações | | **Billing** | Gerenciar contratos, negociações, faturas, lançamentos e extratos; liquidar faturas; orquestrar a emissão de NFSe | | **Payment Links & Checkout** | Criar links de pagamento, executar checkouts hospedados, gerenciar produtos e fornecedores | | **Accounting** | Configurar emissores fiscais e emitir, cancelar e baixar documentos fiscais NFSe | | **Customer** | Gerenciar registros de pagadores/clientes, buscar clientes por hash, exportar dados de clientes | | **Platform** | Operações agregadas entre carteiras, cartões, pagamentos, pagamentos em lote e relatórios | | **Notification** | Configurar roteamento de notificações, canais e destinos de webhook | | **Rule Engine** | Definir políticas de segurança de transações e gerenciar saldos de carteira bloqueados | | **Scheduling** | Agendar transferências futuras de PIX, boleto e entre carteiras e acompanhar sua execução | | **Travel** | Buscar inventário de aéreo, hotel, ônibus e veículo; gerenciar passageiros; criar, emitir e cancelar reservas de viagem | | **Shortlinks** | Criar URLs curtas em `links.portao3.com.br` | 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.