Pular para o conteúdo principal
Formato do erro O Lerian Consignado retorna erros como problem details RFC 9457, com o media type application/problem+json:
Definições de campos
  • type – Uma URI que identifica o erro no catálogo de erros da Lerian. Construída como https://errors.lerian.studio/v1/<code>.
  • title – O texto do status HTTP (por exemplo, Unprocessable Entity).
  • status – O código de status HTTP.
  • detail – Uma explicação legível por humanos desta ocorrência. Em uma resposta 5xx, o Consignado sanitiza o detail para internal error, para que uma causa interna nunca apareça no corpo. Um código 5xx que nomeia uma falha upstream ou um desfecho desconhecido mantém um detail escrito para você, como DATAPREV_TIMEOUT. Baseie sua lógica em code e no status, não no detail.
  • code – Um identificador estável para o erro. As tabelas abaixo listam os códigos CLT-NNNN e os códigos nomeados que várias operações compartilham. Algumas operações respondem com códigos próprios, como CURSOR_EXPIRED na varredura de inventário de registros. Veja Códigos por operação. Uma requisição que falha na validação de schema não traz code: ela responde 422 com o detail validation failed, ou 400 quando o corpo não pode ser interpretado, e a lista errors nomeia cada campo.
  • errors – Lista opcional de detalhes de erro individuais, cada um com um location, um message e um value.
  • instance – O trace ID da requisição, quando o gateway a rastreou. Informe-o ao reportar uma falha à Lerian.
  • upstream – O erro que um sistema upstream retornou e que o gateway repassa. Ele vem do Dataprev nas operações do trilho, e do Streaming Hub nas operações de subscription. Ele contém o code e o message desse sistema, e sobrevive à sanitização de 5xx que limpa o detail. Veja Códigos de motivo do Dataprev.
  • refusal – Em uma recusa de lance: o motivo que o gateway registrou para o lance, com source, field, rule e detail. Uma recusa do Dataprev também traz o code do Dataprev.

400: Requisição inválida


401: Não autorizado


403: Proibido


404: Não encontrado


409: Conflito


CLT-0007 com o detail an identical request is already in flight marca uma requisição que o gateway ainda não terminou. Repita essa requisição sob a mesma chave de idempotência. Conflitos de comando respondem com um código nomeado no lugar de CLT-0007, para que um cliente consiga diferenciá-los. Leia code e detail juntos antes de repetir a requisição. Essas grafias de código fazem parte do contrato de wire e não mudam. Após DATAPREV_CREDENTIAL_REQUIRED, envie o certificado Dataprev, as credenciais OAuth e o código de solicitante do tenant, e depois envie a requisição novamente. Após DATAPREV_CREDENTIAL_REVOKED, envie um novo certificado e um novo cliente OAuth juntos com PUT /v1/credentials/dataprev. Após DATAPREV_CREDENTIAL_REJECTED, corrija as credenciais de cliente OAuth do tenant e depois envie uma leitura novamente. Uma escrita pode ter deixado o comando parado: veja Opere o Lerian Consignado antes de enviá-la novamente.

410: Removido


A varredura paginada de inventário de registros emite um cursor com uma janela limitada de repetição.

413: Entidade da requisição muito grande


Um corpo de averbação que traz a CCB assinada, o pacote de evidências, a evidência de assinatura ou data_hora_assinatura é recusado. Ele responde 413 com 1 MiB ou mais, e 422 com o detail validation failed abaixo disso. Envie-os para POST /v1/consignado/contracts/{numero_contrato}/ccb-attachment depois que o Dataprev aceitar a averbação.

422: Entidade não processável


Algumas recusas respondem com um código nomeado no lugar de CLT-0006. Nada chegou ao Dataprev. A descrição diz o que fazer em seguida. Os códigos de contabilização, de FIRST_DEDUCTION_BEFORE_COMPETENCIA a CONTRACT_NOT_BOOKABLE, valem apenas para um contrato enviado com o bloco de contabilização. Uma averbação responde todos os códigos de contabilização, exceto FORMALIZATION_DEADLINE_EXCEEDED. A documentação dela responde apenas DECLARED_DATES_OUT_OF_ORDER e FORMALIZATION_DEADLINE_EXCEEDED. Uma importação de contrato com booking responde todos os códigos de contabilização, exceto FIRST_DEDUCTION_BEFORE_COMPETENCIA. Uma averbação com o bloco de contabilização também responde RATE_OUTSIDE_PRODUCT_RANGE. Um comando enviado novamente com uma chave de idempotência que uma requisição anterior já consumiu pode responder um de quatro códigos nomeados. A requisição anterior pode já ter chegado ao Dataprev. Não envie o comando novamente, nem com esta chave nem com uma nova. Leia o estado atual do registro que o comando altera. A resposta ao leilão de portabilidade é a exceção: a referência dela explica como um reenvio com uma nova chave revela o resultado.

429: Muitas requisições


Aguarde o tempo indicado no header Retry-After e depois envie a requisição novamente.

500: Erro interno do servidor


501: Não implementado


Um 501 responde a uma operação que seu deploy não habilitou. As rotas permanecem montadas, então a resposta chega por requisição, em vez de como um path ausente. Estas operações respondem 501 até que seu deploy as habilite:
  • downloads de artefato de contrato
  • correções de contrato
  • envio de lance
  • operações que chegam ao Dataprev
A revogação de credenciais do Dataprev responde 501 em um deploy cujas credenciais são estáticas. O detail traz internal error, porque o Consignado sanitiza o detail em uma resposta 5xx. A revogação de credenciais é a exceção: o detail dela diz que as credenciais são estáticas. Baseie sua lógica no status.

502: Gateway inválido


503: Serviço indisponível


Uma resposta DATAPREV_UNAVAILABLE ou DATAPREV_TIMEOUT também traz upstream quando o Dataprev enviou o código e a mensagem próprios.

504: Timeout do gateway


Códigos por operação


Algumas operações respondem com códigos próprios, nomeados a partir da operação: FUNDO_*, ORIGINADOR_*, CESSAO_*, CEDED_CREDIT_*, SALDO_DEVEDOR_*, REGISTRO_B3_*, e os códigos de cursor e de filtro das operações de listagem. A referência da API enumera todos os códigos no campo code do schema de erro. As operações do código de instrumento B3, GET e PATCH /v1/consignado/contracts/{numero_contrato}/registro-b3, respondem com estes códigos.

Códigos de motivo do Dataprev


O Consignado repassa os códigos de motivo do Dataprev, em vez de mapeá-los para códigos próprios. Isso mantém uma recusa legível em relação ao que o Dataprev disse. Leia cada código de motivo em relação à especificação do Dataprev, não a esta página. O Dataprev pode publicar um código que esta página não lista, e o gateway ainda assim o entrega a você. Eles chegam até você em dois lugares. Em uma recusa. O membro upstream traz o code e o message do próprio Dataprev. Uma recusa com vários códigos os lista separados por vírgula. O membro contém os códigos e as frases do Dataprev, com tamanho limitado, e não um corpo de resposta. Um 422 o traz para uma rejeição determinística. DATAPREV_UNAVAILABLE e DATAPREV_TIMEOUT o trazem para uma falha de repetir-mais-tarde. Uma recusa do Dataprev a um comando em upstream fica retida sob a chave de idempotência dele. Um refusal de lance também, qualquer que seja o source dele. A mesma chave retorna a mesma recusa, então envie uma requisição corrigida sob uma nova chave. Um lance recusado com source dataprev também retém a solicitação, então qualquer novo lance para essa solicitação responde BID_SOLICITACAO_TAKEN. Uma recusa que o gateway faz por conta própria, sem upstream e sem membro refusal de lance, não retém a chave, então uma requisição corrigida pode ir sob a mesma chave. Uma execução de garantia FGTS e um comando que responde códigos RAIL_COMMAND_* são a exceção: eles retêm a chave desde antes de chamar o Dataprev. Quando um reenvio responde que uma requisição anterior já detém a chave, como IDEMPOTENCY_KEY_REUSE ou RAIL_COMMAND_PAYLOAD_MISMATCH, siga a instrução desse código. Em respostas de contrato e margem. Vários campos de resposta emparelham um código de motivo do Dataprev com o rótulo próprio do Dataprev para ele. Uma leitura de margem publica blockType e ineligibilityReason, que formam o par code e description. Uma leitura de contrato publica motivo_exclusao, origem_averbacao, origem_exclusao, portabilidade_situacao e situacao_bloqueio_garantia, que formam o par codigo e descricao. Cada campo contém um código numérico e o texto que o Dataprev retornou ao lado dele. Trate o conjunto como aberto. Mapeie os códigos de motivo sobre os quais sua integração age, e repasse o restante com seus rótulos, para que um código ainda não mapeado continue legível para um operador.