Changelog e avisos de mudança

Mudanças na API pública, da mais recente para a mais antiga. Quando uma mudança exige adequação do seu lado, ela traz um prazo. Depois dele, a integração que não se adaptou passa a receber erro.

Cada entrada tem um tipoNovoMelhoriaDepreciaçãoBreaking change

Nenhuma mudança com prazo em aberto. Nada exige adequação da sua integração no momento.

Enquanto uma depreciação está em aberto, as chamadas afetadas respondem normalmente, mas com três headers a mais. Vale registrá-los no seu log para ver o aviso sem precisar abrir esta página.

Header	Exemplo	Significado
`Deprecation`	`@1790737200`	Desde quando o uso está depreciado, em segundos Unix (RFC 9745).
`Sunset`	`Mon, 05 Oct 2026 03:00:00 GMT`	A partir de quando a chamada passa a ser recusada (RFC 8594).
`Link`	`<https://docs.unnotech.com.br/…>; rel="deprecation"`	Onde está a explicação.

07 out 2026

Novo

`notices` nas ofertas CLT: parcela ajustada ao máximo do fundo

GET/api/v1/clt/applications/{application_id}

Toda oferta CLT passa a publicar notices, uma lista de avisos sobre a própria oferta — em
offers[], no best_offer da busca por api_external_id e no detalhe da solicitação. Lista vazia
quando não há nada a avisar.

O primeiro aviso é INSTALLMENT_ADJUSTED_TO_FUND_LIMIT. O fundo que analisa o crédito aprova, por
prazo, uma parcela máxima — em geral abaixo da margem consignável — e um teto de valor liberado ou
financiado. Quando o pedido passa de um desses tetos, a condição deixava de ser ofertada. Agora ela é recalculada para o máximo que o fundo
libera e sai com o aviso — por isso a oferta pode não bater com a parcela ou o valor pedidos.

"notices": [
  {
    "code": "INSTALLMENT_ADJUSTED_TO_FUND_LIMIT",
    "message": "Valor ajustado ao máximo que o fundo pode ofertar neste prazo. Por isso a oferta pode não bater com o valor pedido na simulação.",
    "params": {
      "fund_installment_limit": 324.76,
      "requested_installment": 463.00
    }
  }
]

Decida pelo code. A message vem pronta para exibir ao operador e pode mudar de redação.

params varia por code. Aqui vem o teto que limitou a oferta — fund_installment_limit
(parcela) e/ou fund_disbursement_limit (valor liberado) —, e requested_installment só aparece
quando a simulação foi pedida por parcela.

O conjunto de códigos é aberto: ignore os que não conhecer.

Nada quebra: o campo é novo e opcional na leitura, e as ofertas anteriores a esta mudança
chegam com a lista vazia.

30 set 2026

Depreciação

`user_uuid` obrigatório na originação

POST/api/v1/fgts/applicationsPOST/api/v1/clt/applications

Em vigor desde05/10/2026 às 00:00 (Brasília)

O campo user_uuid identifica o operador do seu time que conduz a venda. Informado, ele aparece
como usuário digitador da proposta e recebe a comissão. Omitido, a proposta fica com o usuário
padrão da API, "Originação (Sistema)", e a comissão não é atribuída a ninguém.

Hoje o campo é opcional. A partir do prazo, passa a ser obrigatório.

O que você precisa fazer

Garanta que a sua api-key tenha o scope users:read, além de proposals:write.

Mapeie cada operador do seu sistema para o uuid dele na plataforma, com
GET /api/v1/users?cpf=<cpf do operador>. O valor não muda: guarde o mapeamento no seu cadastro.

Envie o user_uuid no corpo da abertura da solicitação:

{
  "customer": { "cpf": "12345678909" },
  "user_uuid": "7c1e4b2a-9f3d-4a8e-b6c5-2d1f0e9a8b7c"
}

O passo a passo completo, com as regras de validação, está nos guias de cada produto.

Até o prazo

A chamada sem user_uuid continua sendo aceita e responde 202, com os headers Deprecation,
Sunset e Link descritos acima.

Depois do prazo

A chamada sem user_uuid responde 422 VALIDATION_FAILED, e a solicitação não é aberta:

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Erro de validação.",
    "correlation_id": "req_7f3a9c21b8e04d5f",
    "details": [
      {
        "field": "user_uuid",
        "code": "REQUIRED",
        "message": "user_uuid é obrigatório desde 05/10/2026. Informe o operador que conduz a operação — consulte GET /api/v1/users. Detalhes do aviso de mudança: https://docs.unnotech.com.br/changelog-e-avisos-de-mudan%C3%A7a-2461068m0#user-uuid-obrigatorio-na-originacao"
      }
    ]
  }
}

A recusa acontece antes do registro de idempotência. Depois de corrigir o corpo, dá para reenviar
com a mesma Idempotency-Key.

Guia: Originação FGTS — Vincular a operação ao seu operador

Guia: Originação CLT — Vincular a operação ao seu operador

23 set 2026

Novo

`table_id` ao lado de `table_name` nas ofertas

GET/api/v1/clt/applications/{application_id}GET/api/v1/fgts/applications/{application_id}

Toda oferta passa a publicar table_id junto do table_name — em offers[], no best_offer da
busca por api_external_id e no detalhe da solicitação.

O nome é rótulo comercial: muda quando a bancarizadora renomeia a tabela ou publica uma "2.0". O
uuid é o mesmo do cadastro de tabelas e atravessa a renomeação, então é por ele que você casa a
oferta com a sua própria configuração.

Nada quebra: table_name continua onde estava, e o campo novo é opcional na leitura.

table_id sai nulo em dois casos: oferta cuja bancarizadora não devolveu a tabela da condição, e
oferta anterior a esta mudança — não houve backfill de propósito, porque derivar o uuid pelo nome
hoje atribuiria à oferta antiga uma tabela que pode ter sido renomeada desde então. Nesses casos o
table_name segue bom para exibir, e sem serventia para casar configuração.

01 set 2026

Melhoria

Quota diária por parceiro nas aberturas de solicitação

POST/api/v1/fgts/applicationsPOST/api/v1/clt/applications

As duas aberturas de solicitação passam a ter teto diário: 100 chamadas por dia cada uma, em
baldes separados — gastar as 100 do FGTS não tira nada do CLT.

O contador é do parceiro, não da chave de API: se você opera com mais de uma chave, todas somam
no mesmo balde. O dia é o dia civil no fuso de Brasília (America/Sao_Paulo), sem janela
deslizante e sem carregar sobra de um dia para o outro.

Toda resposta nessas rotas traz três headers:

Header	O que diz
`DailyQuota-Limit`	seu teto do dia nessa rota
`DailyQuota-Remaining`	quantas chamadas ainda restam
`DailyQuota-Reset`	segundos até o saldo voltar cheio

Estourado o teto, a chamada responde 429 QUOTA_EXCEEDED com Retry-After, e não chega a ser
processada — nada é criado do outro lado. Atenção para não confundir com RATE_LIMIT_EXCEEDED,
que chega com o mesmo 429: esse é transitório e passa em segundos, enquanto QUOTA_EXCEEDED só
se resolve na virada do dia ou com o teto maior. Distinga pelo error.code.

Acompanhar o que você já abriu não consome quota: o detalhe da solicitação, o status, a margem,
o KYC e o aceite seguem sem teto — o polling do fluxo de originação não é penalizado.

Guia: Quota diária

20 ago 2026

Novo

`status` no PATCH de usuário liga e desliga o acesso aos seus parceiros

PATCH/api/v1/users/{user_uuid}

O PATCH de usuário passa a aceitar status, com ACTIVE e INACTIVE. Dá para desligar um
operador que saiu do time e religá-lo depois sem recriar nada.

{ "status": "INACTIVE" }

O status age nos seus vínculos, não no cadastro. Ele liga ou desliga o acesso do usuário ao
parceiro do token e a todos os sub-parceiros abaixo dele. O cadastro não é apagado nem bloqueado na
plataforma, e vínculos com parceiros fora da sua hierarquia continuam como estavam: um usuário
que também opera em outra rede segue operando nela.

status: "ACTIVE" é como se desfaz um DELETE — que desliga exatamente os mesmos vínculos. O
usuário volta com o mesmo user_uuid, o mesmo grupo e o mesmo histórico. Recriá-lo do zero não
é equivalente: geraria outro user_uuid.

Vale conhecer:

Vale na hora — o token do usuário é invalidado, sem esperar expirar.

Idempotente — pedir a situação que já vale responde 200 e não muda nada.

Não cria — um user_uuid que nunca existiu continua respondendo 404.

Combinável — dá para mudar a situação e corrigir dados na mesma chamada.

Reativação ampla — ACTIVE religa todos os vínculos na sua hierarquia. Para mexer em um
parceiro só, use PUT /api/v1/partners/{partner_id}/users/{user_id}/status/INACTIVE.

17 ago 2026

Novo

Originação CLT na API pública

POST/api/v1/clt/applications

O consignado CLT fica disponível na API pública, com o mesmo desenho do FGTS: abre a solicitação,
acompanha por polling, aceita a oferta.

A diferença está no começo. A solicitação nasce em AWAITING_AUTHORIZATION, aguardando o
consentimento do trabalhador na Dataprev/CTPS Digital. Obtido o consentimento, ela caminha sozinha
para MARGIN_QUERY e depois AWAITING_SIMULATION, quando os vínculos e a margem de cada um já
estão conhecidos e a cotação pode ser pedida.

Dois desfechos terminais são específicos do CLT e precisam de tratamento no seu lado:
AUTHORIZATION_UNAVAILABLE, quando o CPF não consta na base da Dataprev, e NO_MARGIN, quando
nenhum vínculo tem margem consignável disponível.

Guia: Originação CLT

Changelog e avisos de mudança

notices nas ofertas CLT: parcela ajustada ao máximo do fundo#

user_uuid obrigatório na originação#

O que você precisa fazer#

Até o prazo#

Depois do prazo#

table_id ao lado de table_name nas ofertas#

Quota diária por parceiro nas aberturas de solicitação#

status no PATCH de usuário liga e desliga o acesso aos seus parceiros#

Originação CLT na API pública#

`notices` nas ofertas CLT: parcela ajustada ao máximo do fundo

`user_uuid` obrigatório na originação

O que você precisa fazer

Até o prazo

Depois do prazo

`table_id` ao lado de `table_name` nas ofertas

Quota diária por parceiro nas aberturas de solicitação

`status` no PATCH de usuário liga e desliga o acesso aos seus parceiros

Originação CLT na API pública