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

Acesse o portal UNNO com um usuário no perfil MARTER-CORBAN para ter acesso ao menu Configurações > Integraçoes > API keys.

Crie a credencial de defina os escopos de acesso. Anote a credencial em lugar seguro (client_id e client_secret).

Troque as credenciais por um token em POST /api/v1/auth/token.

Envie o token em Authorization: Bearer <access_token> nas demais chamadas.

Reutilize o mesmo token até o expires_in — não gere um por requisição.

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 . _ : -.

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:

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.

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.

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.

Visão geral da API

Comece por aqui#

Ambientes#

Convenções que valem para toda a API#

Erros#

Três regras para tratar erro sem sofrer:#

Comece por aqui

Ambientes

Convenções que valem para toda a API

Erros

Três regras para tratar erro sem sofrer: