Codigos de Erro

Toda resposta de erro usa o envelope detail; o conteúdo pode ser uma string (código do erro) ou um objeto estruturado com code e message:

{"detail": "codigo_do_erro"}

HTTP Status Codes

Status	Uso
`200`	Sucesso
`201`	Recurso criado
`202`	Aceito (processamento assincrono)
`204`	Sucesso sem body (delete)
`401`	Nao autenticado
`403`	Autenticado, mas sem permissao: scope insuficiente ou limite de policy (ver Scopes e Limites e Taxas)
`404`	Recurso nao encontrado
`409`	Conflito de estado
`422`	Validacao falhou
`423`	Conta bloqueada
`429`	Rate limit excedido
`502`	Falha no provedor externo de assinatura (so nas rotas de contrato)
`503`	Servico indisponivel

Cada operacao declara no openapi.json exatamente quais destes status ela pode devolver, com a lista de codigos possiveis na descricao da resposta — prefira o contrato a esta pagina quando quiser saber o que UMA rota especifica retorna.

Nao ha 400 em nenhuma rota publica: erro de corpo/parametro sai sempre como 422.

502 e 503 sao coisas diferentes e nao se substituem: 503 e uma dependencia NOSSA indisponivel; 502 e o provedor externo de assinatura que falhou ou nao respondeu, e so aparece nas rotas de contrato (/v1/operations/{id}/contract/* — ver Assinatura embedded). Os dois sao re-tentaveis com backoff.

Formatos de validacao (`422`)

Algumas validacoes manuais da regra de negocio retornam detail como string:

{
  "detail": "some_stock_items_not_found"
}

Falhas de schema (campo ausente, tipo errado, valor fora de faixa, JSON malformado) retornam detail como objeto, no mesmo envelope aninhado dos demais erros estruturados da API — code + message + chaves especificas. Aqui o code e sempre validation_error e o detalhe por campo vem em errors:

{
  "detail": {
    "code": "validation_error",
    "message": "Request validation failed for body.fees.floating_days: Input should be greater than or equal to 0",
    "errors": [
      {
        "loc": ["body", "fees", "floating_days"],
        "msg": "Input should be greater than or equal to 0",
        "type": "greater_than_equal"
      }
    ]
  }
}

Cada item de errors traz obrigatoriamente loc (caminho do campo), msg (mensagem) e type (tipo da falha) — os mesmos campos de antes, agora sob detail.errors. O Pydantic pode acrescentar input (valor recebido) e ctx (parametros da regra); trate-os como opcionais.

Rotas de autenticacao: input vem redigido

Nas rotas sob /v1/auth/ (POST /v1/auth/token, POST /v1/auth/login) o corpo carrega credencial — e num erro de campo ausente o input traria o corpo inteiro, com client_secret / password. Nessas rotas, e so nelas, o valor de input e substituido por "[REDACTED]":

{
  "detail": {
    "code": "validation_error",
    "message": "Request validation failed for body.client_id: Field required",
    "errors": [
      {
        "loc": ["body", "client_id"],
        "msg": "Field required",
        "type": "missing",
        "input": "[REDACTED]"
      }
    ]
  }
}

O diagnostico nao muda: loc diz qual campo falhou, msg e type dizem por que, e o ctx de restricao (min_length, max_length) continua vindo. Some so o valor. Nas demais rotas o input segue ecoando o valor recebido, para depuracao.

Mudanca de formato

Ate a versao anterior, falhas de schema devolviam detail como lista crua ({"detail": [{"loc": ..., "msg": ..., "type": ...}]}). O conteudo e o mesmo — mudou so o envelope: detail virou objeto e a lista passou para detail.errors.

Se voce le os erros por campo direto de detail, ajuste para detail.errors. Os SDKs oficiais (Node e Python) ja aceitam os dois formatos: continue usando err.fieldErrors / err.errors.

Ao tratar 422, o detail pode assumir tres formas — e o schema HTTPValidationError do OpenAPI declara as tres:

Forma	Quando	Como identificar
Objeto com `code: "validation_error"` + `errors`	Falha de schema	`detail.code === "validation_error"`
Objeto com `code` + `message`, sem `errors`	Regra de negocio estruturada (limite, CET, scopes, idempotencia)	`detail.code` presente e `detail.errors` ausente
String	Regra de negocio legada	`typeof detail === "string"`

Apenas a primeira forma foi unificada nesta versao; as outras duas seguem em formato livre. Os objetos de limite, CET e scopes aparecem nas secoes abaixo.

O loc de validation_error aponta o nome DEPRECADO do campo

Vale tambem para a primeira forma: o loc de cada item de detail.errors traz o nome deprecado, mesmo quando o seu payload usou so o canonico — porque quem esta na lista required do contrato ainda e o nome antigo. Ex.: omitir requested_net_future_value num POST /v1/stock/simulate-anticipation devolve

{"detail": {"code": "validation_error", "errors": [
  {"loc": ["requested_advance_value"], "type": "missing"}
]}}

— e nao loc: ["requested_net_future_value"]. Se voce mapeia loc para os campos do seu formulario, mapeie a partir do nome deprecado (ou normalize pelo de-para de Valores do Recebivel).

Vocabulario publico (`_future_value` / `_present_value`)

Cada valor monetario da API tem dois nomes aceitos: o canonico (net_future_value, gross_future_value, requested_net_future_value, ...) e o deprecado (net_face_value, gross_face_value, requested_advance_value, ...) — mesmo numero, mesma semantica. Os quatro codigos abaixo existem para que a convivencia nunca seja resolvida em silencio: nenhum deles escolhe um valor por voce, todos recusam o pedido inteiro antes de qualquer efeito.

Codigo	HTTP	Descricao
`VOCABULARY_CONFLICT`	422	O nome canonico e o deprecado do MESMO valor vieram no payload com numeros diferentes. Sao sinonimos: envie um dos dois, ou os dois com o mesmo valor (`"10000"` e `10000.00` sao o mesmo numero). `detail.fields` lista cada par em conflito com `public_field`, `public_value`, `deprecated_field` e `deprecated_value`. Enviar so um dos nomes, ou `null` no que voce nao usa, nunca gera este erro
`DEDUCTIONS_REQUIRED_WITH_GROSS`	422	`gross_future_value` foi usado sem `gross_future_value_deductions` no mesmo payload. Usar o nome canonico do BRUTO obriga a declarar a diferenca para o `net_future_value` — envie `0` se nao houver deducoes. O nome deprecado `gross_face_value` segue aceito sozinho, exatamente como antes. `detail.fields` nomeia os dois campos
`VALUE_DECOMPOSITION_MISMATCH`	422	Vieram os tres valores e a conta nao fecha: `net_future_value` tem que ser EXATAMENTE `gross_future_value` menos `gross_future_value_deductions`, sem tolerancia de centavo (os tres sao declarados por voce). `detail` traz os tres valores recebidos mais `expected_net_future_value`
`REQUESTED_VALUE_AMBIGUOUS`	422	`requested_net_future_value_percent` veio junto do valor ABSOLUTO solicitado (`requested_net_future_value` ou `requested_advance_value`). Os dois sao mutuamente exclusivos: informe o percentual do NFV ou o valor em BRL. `detail.fields` lista os campos envolvidos. So existe em `POST /v1/simulate` e `POST /v1/operations/direct` — as portas de `/v1/stock/*` antecipam sempre 100% dos itens e nao aceitam percentual

Dentro do detail de um erro, os campos usam os nomes DEPRECADOS

O espelhamento canonico vale para os requests e para as respostas de sucesso. O corpo de um erro nao entra nessa regra: as chaves e as mensagens dos detail das secoes abaixo citam net_face_value, gross_face_value, requested_advance_value, discount_brl e total_net_face_value, e nao trazem a versao canonica ao lado — mesmo quando voce enviou o payload no vocabulario canonico.

Na pratica: ao ler um erro, procure detail.net_face_value, nao detail.net_future_value (que nao existe). A excecao sao os quatro codigos desta secao, que nasceram no vocabulario novo e nomeiam os campos canonicos em detail.fields. Todos os exemplos de detail nesta pagina estao no vocabulario que a API realmente emite.

Onde cada um pode ocorrer esta declarado na propria operacao, em "Codigos possiveis nesta operacao" (openapi.json): VOCABULARY_CONFLICT nas seis portas que aceitam o vocabulario novo; DEDUCTIONS_REQUIRED_WITH_GROSS e VALUE_DECOMPOSITION_MISMATCH nas que aceitam gross_future_value_deductions (POST /v1/stock, PATCH /v1/stock/{item_id}, POST /v1/simulate, POST /v1/operations/direct); REQUESTED_VALUE_AMBIGUOUS nas duas que aceitam o percentual.

Exemplo de VOCABULARY_CONFLICT:

{
  "detail": {
    "code": "VOCABULARY_CONFLICT",
    "message": "O mesmo valor foi informado nos dois vocabularios com numeros DIFERENTES. Os nomes novo e deprecado sao sinonimos exatos: envie apenas um deles, ou os dois com o MESMO valor. O pedido foi recusado sem efeito colateral — nada e escolhido em silencio.",
    "fields": [
      {
        "public_field": "net_future_value",
        "public_value": "1000000.00",
        "deprecated_field": "net_face_value",
        "deprecated_value": "100.00"
      }
    ]
  }
}

Auth

Codigo	HTTP	Descricao
`not_authenticated`	401	Nenhuma credencial enviada
`invalid_credentials`	401	Email/senha incorretos — inclui a conta bloqueada quando a senha não é provada. E-mail inexistente, senha errada e conta bloqueada com senha errada devolvem o mesmo status e o mesmo corpo (ver Protecao contra brute force)
`invalid_client_credentials`	401	Credencial de API invalida, revogada ou expirada — nao so no token exchange: sai tambem em qualquer rota autenticada por Bearer (a credencial por tras do token e relida a cada request) e no caminho legado por `X-Client-Id`/`X-Client-Secret`
`token_expired`	401	JWT expirado
`invalid_token`	401	JWT malformado
`user_locked`	423	Senha correta e conta bloqueada (30 min apos 5 falhas). Com senha errada a resposta e `401 invalid_credentials`. Passados os 30 min o desbloqueio e automatico e o contador zera

invalid_client_credentials num endpoint de negocio

Receber este codigo fora do POST /v1/auth/token significa que a credencial que emitiu o token deixou de valer (revogacao ou expiracao) — a revogacao e imediata, nao espera o token expirar. Renovar o token nao resolve: o proprio token exchange vai recusar. Emita uma credencial nova. Ver Autenticacao.

Scopes

Os endpoints da API exigem scopes granulares no token — veja a tabela completa de scopes. Os erros de scope retornam um objeto estruturado em detail (em vez do formato simples {"detail": "codigo"}):

Codigo	HTTP	Quando	Campos em `detail`
`scope_not_allowed`	403	`POST /v1/auth/token` pedindo scope fora do permitido para a credencial	`code`, `message`, `allowed_scopes`
`scope_insufficient`	403	Endpoint chamado sem o scope exigido no token	`code`, `required`, `granted`, `message`

Exemplo (scope_insufficient):

{
  "detail": {
    "code": "scope_insufficient",
    "required": "operation:create",
    "granted": ["operation:read", "simulation:create"],
    "message": "Token lacks required scope: operation:create"
  }
}

Estoque

Codigo	HTTP	Descricao
`stock_item_not_found`	404	Item nao encontrado
`stock_item_not_in_stock`	409	Item nao esta IN_STOCK
`stock_item_cannot_be_cancelled`	409	Item nao pode ser cancelado
`some_stock_items_not_found`	422	Alguns IDs nao existem
`stock_item_{id}_not_available`	409	Item especifico nao disponivel
`STOCK_REQUESTED_VALUE_MISMATCH`	422	`requested_advance_value` diferente da soma dos `net_face_value` dos itens em `stock_item_ids` — veja abaixo
`STOCK_ITEM_NFV_NOT_POSITIVE`	422	Algum item de `stock_item_ids` tem `net_face_value` menor ou igual a zero e nao e antecipavel (o NFV e a base do desagio). `detail.items` lista `stock_item_id`, `external_id` e o valor de cada item recusado; corrija com `PATCH /v1/stock/{item_id}` ou tire o item do lote
`STOCK_ITEM_NFV_ABOVE_GROSS`	422	Item com `net_face_value` maior que `gross_face_value`. O NFV e o valor de face BRUTO menos os descontos ja aplicados ao lastro, entao nunca o supera. Vale em `PATCH /v1/stock/{item_id}` (avaliado contra os valores RESULTANTES — o campo enviado cruzado com o que ja esta gravado) e nas 2 rotas de antecipacao, que rejeitam item JA GRAVADO nesse estado (`detail.items` nomeia cada um). Em `POST /v1/stock` o mesmo invariante e falha de schema (`validation_error`)
`STOCK_ITEM_DISCOUNT_EXCEEDS_BASE`	422	O desagio calculado para algum item ficou maior ou igual ao seu `net_face_value` — a antecipacao teria valor liquido zero ou negativo. Emitido por `POST /v1/stock/request-anticipation` e `POST /v1/stock/simulate-anticipation` (mesmo veredito nas duas). Acontece tipicamente com `fixed_discount_brl` (desconto NOMINAL, que nao escala com o valor do item) sobre item pequeno, ou com `fees.total_liquid_value_brl` proximo de zero. `detail.items` nomeia cada item recusado com `stock_item_id`, `external_id`, `net_face_value` (a base) e `discount_brl` (o desagio calculado)

STOCK_REQUESTED_VALUE_MISMATCH retorna um objeto estruturado em detail. O fluxo de estoque antecipa sempre 100% dos itens selecionados, entao requested_advance_value so pode confirmar o total do lastro; pedir uma fracao (ou mais que o total) e recusado em vez de ser ignorado. Para antecipacao parcial, use POST /v1/operations/direct.

{
  "detail": {
    "code": "STOCK_REQUESTED_VALUE_MISMATCH",
    "message": "requested_advance_value deve ser igual a soma do net_face_value (Net Face Value) dos itens em stock_item_ids: o fluxo de estoque antecipa 100% dos itens selecionados e nao implementa antecipacao parcial. Para antecipar uma fracao do NFV use POST /v1/operations/direct.",
    "requested_advance_value": "6000.00",
    "total_net_face_value": "10000.00",
    "stock_item_count": 1
  }
}

Vale nas duas portas do estoque (POST /v1/stock/request-anticipation e POST /v1/stock/simulate-anticipation), com o mesmo veredito: o que a simulacao recusa, o create tambem recusa.

Simulacao e criacao direta

Estas duas portas (POST /v1/simulate e POST /v1/operations/direct) compartilham tres validacoes de valor por recebivel — para elas, o MESMO payload recebe o MESMO 422 com o MESMO detail nas duas, e a simulacao nao cota o que o create recusa:

teto requested_advance_value <= net_face_value;
fees.total_liquid_value_brl acima do face total da operacao;
desagio maior ou igual a base do recebivel (RECEIVABLE_DISCOUNT_EXCEEDS_BASE).

A simulacao nao e um espelho completo do create — fora dessas tres, as portas divergem por design:

Faixa de taxa da policy (CET): no create e enforcement (422 CET_OUT_OF_BOUNDS); na simulacao e consultivo — ela responde 200 com os numeros, e o /v1/portal/simulate ainda devolve o bloco policy_verdict para o wizard decidir. Deliberado: o objetivo e mostrar o preco fora da faixa, nao esconde-lo.
Cardinalidade do lote: too_many_receivables_max_<N> existe so no create (o limite vem do numero de linhas que o contrato assinado comporta, que a simulacao nao gera). Um lote acima do limite simula normalmente e so e recusado na criacao.
Limites agregados de exposicao, gates de estoque e exclusao mutua de fees: enforcement apenas no create.

Codigo	HTTP	Descricao
`originator_policy_not_configured`	422	Originador sem policy de taxas
(string) `total_liquid_value_brl exceeds total face value`	422	`fees.total_liquid_value_brl` acima da soma dos `requested_advance_value` — o desagio resultante seria NEGATIVO. `detail` e uma string (shape legado, preservado)
(string) `Receivable <external_id>: requested_advance_value (...) cannot exceed net_face_value (...)`	422	Teto do antecipavel: nao se antecipa mais que o `net_face_value` (NFV) do recebivel. `detail` e uma string (shape legado, preservado). Reporta o PRIMEIRO recebivel ofensor na ordem do payload
`RECEIVABLE_DISCOUNT_EXCEEDS_BASE`	422	O desagio calculado para algum recebivel ficou maior ou igual ao seu `requested_advance_value` — a antecipacao teria valor liquido zero ou negativo. Acontece tipicamente com `fixed_discount_brl` (desconto NOMINAL, que nao escala com o valor do recebivel) ou com `fees.total_liquid_value_brl` proximo de zero. `detail.receivables` nomeia cada ofensor com `external_id`, `requested_advance_value` (a base) e `discounted_value` (o desagio calculado). Avaliado DEPOIS da redistribuicao do alvo liquido

Operacoes

Codigo	HTTP	Descricao
`operation_not_found`	404	Operacao nao existe
`operation_cannot_be_cancelled`	409	Operacao ja em andamento
`operation_cannot_be_approved`	409	Status nao permite aprovacao
`operation_cannot_be_denied`	409	Status nao permite negacao

Contrato e assinatura

Rotas /v1/operations/{id}/contract/* — ver Assinatura embedded.

Codigo	HTTP	Descricao
`operation_not_in_signable_state`	409	O estado da operacao nao permite disparar o contrato. Voce so dispara em `PRE_APPROVED`, `APPROVED_DIRECT` ou `CONTRACT_ERROR` (re-disparo apos falha) — em `WAITING_APPROVAL`, espere a aprovacao
`contract_already_exists`	409	O contrato ja foi despachado (em geral pelo envio automatico). Nao e falha: leia as URLs em `GET /v1/operations/{id}/contract/signers`
`contract_not_found`	404	A operacao nao tem contrato ativo (ainda nao foi despachado, ou a operacao e de outro originador)
`contract_not_dispatched`	409	Ha registro do contrato, mas o documento ainda nao existe no provedor. Estado TRANSITORIO da janela de despacho — re-tente com backoff
`zapsign_unavailable`	502	O provedor de assinatura falhou ou nao respondeu ao consultar os signatarios. Re-tentavel

O disparo (POST .../send-for-signature) tambem pode devolver 502 com zapsign_create_failed, zapsign_add_signer_failed, zapsign_update_signer_failed ou zapsign_template_inventory_failed. Em todos eles nenhum documento parcial fica vivo: o despacho e contido (o documento e removido no provedor) e a operacao fica CONTRACT_ERROR, re-disparavel pela mesma rota.

Limites e Taxas

Erros de limite/CET retornam um objeto estruturado em detail (em vez do formato simples {"detail": "codigo"}).

Os codigos desta secao se dividem em duas familias, e a diferenca muda o que voce faz com a resposta:

Familia	O que aconteceu	O que resolve
VALOR (`LIMIT_MAX_OPERATION_VALUE`, `LIMIT_MIN_OPERATION_VALUE`, `LIMIT_AGGREGATE_EXPOSURE`)	a operacao existe e nao cabe: o numero pedido esta fora do permitido, ou a exposicao em aberto do recorte estourou	mudar o numero (ou esperar a liquidacao, no caso do agregado)
CONFIGURACAO (`LIMIT_CONFIG_MISSING`, `LIMIT_ENTITY_CONFIG_MISSING`)	falta limite configurado na policy — nao ha o que comparar	acao humana no Backoffice; re-tentar sem configurar da o mesmo `403`

As duas familias tem detail.code e detail.message; os outros campos diferem, e por isso vem um exemplo de cada abaixo. Quando os dois defeitos coexistem, o de configuracao e reportado primeiro (ele nao depende do numero da operacao).

Familia VALOR

{
  "detail": {
    "code": "LIMIT_MAX_OPERATION_VALUE",
    "source": "assignor",
    "max_allowed_brl": "50000.00",
    "requested_brl": "75000.00",
    "message": "Valor da operacao R$75000.00 excede o limite (assignor) R$50000.00"
  }
}

O LIMIT_AGGREGATE_EXPOSURE e da mesma familia, com os campos do recorte que estourou (source, scope, limit_brl, limit_origin, open_exposure_brl, requested_brl):

{
  "detail": {
    "code": "LIMIT_AGGREGATE_EXPOSURE",
    "source": "assignor",
    "scope": "assignor:3f2a1c88-...",
    "limit_brl": "200000.00",
    "limit_origin": "entity_override",
    "open_exposure_brl": "190000.00",
    "requested_brl": "30000.00",
    "message": "Exposicao em aberto do recorte assignor:3f2a1c88-... (R$190000.00) somada a operacao (R$30000.00) excede o limite do recorte R$200000.00 (assignor)"
  }
}

`limit_origin` — de onde veio o teto que travou

source diz qual recorte travou; limit_origin diz de onde saiu o numero. Os dois juntos sao o que distingue "voce estourou um teto" de "este ente esta bloqueado", que sao situacoes com remediacoes opostas:

`limit_origin`	Significado	O que fazer
`configured`	O numero veio do default da policy para aquele lado (`entity_default_limit_brl` / `payer_default_limit_brl`).	Operar dentro do teto, ou pedir aumento do default no Backoffice.
`entity_override`	O numero veio do limite proprio daquele ente, no vinculo. Manda sempre — maior ou menor que o default, inclusive `0`.	Ajustar o limite individual do ente no Backoffice.
`anchored_side_closed`	Nao ha numero configurado. A policy ancora o risco naquele lado e ninguem definiu o default do lado, entao o ente entra travado (`limit_brl: "0"`).	Definir o default do lado, ou dar limite proprio ao ente.
`side_default_zero`	O default daquele lado foi configurado como `0` — bloqueio deliberado (`limit_brl: "0"`).	Se a trava foi intencional, dar limite proprio apenas aos entes que devem operar (allowlist).

Ancoragem de risco: ausencia significa coisas opostas em cada lado

Numa policy sem ancoragem (o default de hoje), ausencia de teto num ente significa "sem limite por aqui".

Numa policy com ancoragem, isso vale so para o lado nao ancorado — e o que estiver configurado nele continua valendo. No lado ancorado, ausencia significa bloqueio: o ente entra com limit_brl: "0" e nada passa por ele (limit_origin diz se foi anchored_side_closed ou side_default_zero).

E assim que se escreve uma allowlist: default do lado ancorado em 0 ou ausente, e limite proprio apenas nos entes que devem operar.

Familia CONFIGURACAO

Estes NAO tem source nem max_allowed_brl

Nao ha limite para citar — e disso que eles falam. Um cliente que le detail.source sem checar o code primeiro quebra aqui.

LIMIT_ENTITY_CONFIG_MISSING — a policy tem limite agregado, mas nenhum por ente (cedente ou sacado) valendo para esta operacao:

{
  "detail": {
    "code": "LIMIT_ENTITY_CONFIG_MISSING",
    "configured_levels": ["policy_total"],
    "entity_levels_required": ["assignor", "payer", "policy_entity_default", "policy_payer_default"],
    "message": "Nenhum limite POR ENTE (cedente ou sacado) vale para esta operacao: o teto da tese inteira (policy-total) e o teto por operacao controlam o agregado, mas nao substituem o limite do ente. Configure o limite individual do cedente ou do sacado (ou o default por cedente da policy) no Backoffice — e, sob ancoragem de risco, no lado em que o risco esta ancorado."
  }
}

configured_levels diz quais recortes de limite chegaram a esta operacao; entity_levels_required, quais deles satisfazem a regra — um basta, seja o limite proprio do cedente ou de um sacado, seja o default por lado da policy.

Este codigo NAO tem variante "por ancoragem"

Sob ancoragem de risco o lado ancorado sempre entra na conta com um numero — o teto configurado, ou 0 quando nao ha teto (ver limit_origin acima). Como sempre existe recorte por ente, este codigo nao aparece nesse caminho: a recusa vem como LIMIT_AGGREGATE_EXPOSURE com limit_brl: "0", que e uma recusa de limite e nao de configuracao.

Versoes anteriores desta pagina descreviam aqui um detail com missing_entity_scopes listando os entes descobertos do lado ancorado. Esse campo nao existe mais e aquela resposta nao e mais produzida.

LIMIT_CONFIG_MISSING e o caso extremo da mesma familia: nenhum limite agregado configurado (nem a tese). Mesmo formato, sem os campos de recorte.

Tabela

Codigo	HTTP	Familia	Descricao
`LIMIT_MAX_OPERATION_VALUE`	403	valor	Valor da operacao acima do maximo permitido (cedente, sacado ou originador). `source` indica a camada mais restritiva
`LIMIT_MIN_OPERATION_VALUE`	403	valor	Valor da operacao abaixo do minimo exigido por alguma camada
`LIMIT_AGGREGATE_EXPOSURE`	403	valor	Exposicao em aberto do recorte, somada a esta operacao, excede o limite daquele recorte. `scope` diz QUAL recorte e `limit_origin` DE ONDE veio o teto. Com `limit_brl: "0"` significa ente travado (lado ancorado sem teto)
`LIMIT_CONFIG_MISSING`	403	configuracao	Nenhum limite agregado configurado na policy — nada a comparar (fail-closed)
`LIMIT_ENTITY_CONFIG_MISSING`	403	configuracao	Ha limite agregado, mas falta limite POR ENTE valendo para a operacao. Desde a `1.4.0`
`CET_OUT_OF_BOUNDS`	422	—	Taxa efetiva resultante fora do intervalo `[min, max]` da policy do originador

Rate limit

Ha dois limites e ambos valem (veja Rate Limits). Os dois respondem 429 com o header Retry-After e com o mesmo formato de detail — objeto com code, scope, limit_rpm, retry_after_seconds e message. O campo scope diz qual bucket negou:

Codigo	HTTP	Quando	`detail.scope`
`rate_limit_exceeded`	429	Credencial de integracao estourou o teto de requisicoes/minuto	`token`
`rate_limit_exceeded`	429	IP de origem estourou o teto da rota	`ip`

Exemplo (por token — o de origem so muda scope, limit_rpm e message):

{
  "detail": {
    "code": "rate_limit_exceeded",
    "scope": "token",
    "limit_rpm": 120,
    "retry_after_seconds": 60,
    "message": "Token excedeu o limite de 120 requisicoes por minuto. Aguarde 60s antes de retentar."
  }
}

Titulos

Codigo	HTTP	Descricao
`title_not_found`	404	Titulo nao encontrado
`title_balance_locked`	409	Saldo do titulo bloqueado

Idempotencia

Codigo	HTTP	Descricao
`idempotency_key_reused_with_different_body`	409	Mesma chave, body diferente

Payables

Codigo	HTTP	Descricao
`payable_not_found`	404	Payable nao encontrado
`payable_already_settled`	409	Payable ja liquidado

HTTP Status Codes​

Formatos de validacao (422)​

Vocabulario publico (*_future_value / *_present_value)​

Auth​

Scopes​

Estoque​

Simulacao e criacao direta​

Operacoes​

Contrato e assinatura​

Limites e Taxas​

Familia VALOR​

limit_origin — de onde veio o teto que travou​

Familia CONFIGURACAO​

Tabela​

Rate limit​

Titulos​

Idempotencia​

Payables​