Documentação oficial das APIs públicas da plataforma Unno.Use estas APIs para integrar seu sistema ao ecossistema Unno: originar crédito, acompanhar
contratações e receber eventos de mudança de estado.Comece por aqui#
1.
Acesse o portal UNNO com um usuário no perfil MARTER-CORBAN para ter acesso ao menu Configurações > Integraçoes > API keys.
2.
Crie a credencial de defina os escopos de acesso. Anote a credencial em lugar seguro (client_id e client_secret).
3.
Troque as credenciais por um token em POST /api/v1/auth/token.
4.
Envie o token em Authorization: Bearer <access_token> nas demais chamadas.
5.
Reutilize o mesmo token até o expires_in — não gere um por requisição.
Mudanças na API#
Novidades, depreciações e prazos de adequação são publicados no documento Changelog e avisos de
mudança. Quando uma mudança exige ação do seu lado, a chamada afetada também responde com os
headers Deprecation e Sunset durante a transição. Registre esses headers no seu log.Ambientes#
| Ambiente | Base URL |
|---|
| Produção | https://gtw.unnotech.com.br/public |
Convenções que valem para toda a API#
Escrita é assíncrona. Os POST que iniciam trabalho respondem 202 Accepted assim que
registram a intenção — a execução segue em background. Você acompanha por GET ou por webhook.
Um 202 significa "aceitamos e vamos processar", nunca "concluído".Campos em snake_case, tanto no corpo que você envia quanto no que recebe. Datas em ISO-8601;
instantes em UTC (2026-07-27T18:45:00Z).Toda escrita exige Idempotency-Key. É um valor que você gera (um UUID serve) e que torna o
reenvio seguro: repetir a chamada com a mesma chave e o mesmo corpo devolve o resultado original,
sem duplicar a operação. É a proteção contra timeout de rede virar contratação em dobro. Chave
reutilizada com corpo diferente responde 409 IDEMPOTENCY_KEY_REUSED.X-Api-External-Id correlaciona com o seu sistema. Opcional, mas recomendado: informe o seu
identificador da operação e ele volta ecoado nas respostas, nos erros e nos webhooks. Com ele você
reconcilia sem precisar guardar o nosso id — inclusive quando a resposta da criação se perdeu.
Aceita até 64 caracteres, entre letras, dígitos e . _ : -.Algumas rotas têm quota diária. Hoje as duas aberturas de solicitação —
POST /api/v1/fgts/applications e POST /api/v1/clt/applications —, cada uma com 100 chamadas por
dia por parceiro e balde próprio; as demais não têm teto. As respostas dessas rotas trazem os headers
DailyQuota-Limit, DailyQuota-Remaining e DailyQuota-Reset, e o estouro responde
429 QUOTA_EXCEEDED. Quotas maiores são negociadas com o comercial — ver o guia de quota diária.
Um 403 ACCESS_BLOCKED nessas rotas é outra coisa: bloqueio administrativo, que não passa na virada
do dia.Erros#
Toda falha usa o mesmo envelope, em qualquer endpoint e qualquer status:{
"error": {
"code": "OFFER_EXPIRED",
"message": "A oferta selecionada expirou. Refaça a cotação.",
"correlation_id": "req_7f3a9c21b8e04d5f",
"api_external_id": "PEDIDO-2026-0001",
"details": [
{ "field": "customer.cpf", "code": "INVALID_FORMAT", "message": "O CPF deve conter exatamente 11 dígitos" }
]
}
}
Três regras para tratar erro sem sofrer:#
1.
error.code é o contrato; error.message não é. O código, uma vez publicado, nunca muda de
nome nem de status HTTP. A mensagem é humana e pode ser reescrita a qualquer momento — não faça
parsing dela.
2.
Trate código desconhecido pelo grupo do status HTTP. A lista de códigos cresce com o tempo.
Um valor novo em um 409 deve cair no seu tratamento genérico de conflito, não quebrar o parser.
3.
correlation_id sempre vem preenchido. É a chave da chamada no nosso journal: ao acionar o
suporte, cite esse id e localizamos as duas pernas da requisição na hora.
O bloco details[] só aparece em 422 VALIDATION_FAILED, com field no caminho de ponto sobre o
corpo enviado.Recusa do banco não é erro de API. Quando o banco recusa uma contratação, a chamada foi
bem-sucedida — a recusa é desfecho de negócio e chega dentro do estado do recurso
(offers[].rejection_reason), não neste envelope.
Modificado em 2026-10-01 02:47:07