error_code. Nunca por code.
Resumo
Deu certo
Algo na sua requisição precisa mudar
Foi do nosso lado
403 não existe nesta API. Um recurso de outra organização responde 404, e não há modelo de
permissão por credencial: toda credencial pode tudo o que a API oferece.O envelope
Quatro campos, não dois.number | string
Identificador do erro. Numérico (
10000 + http_code) na validação genérica, texto nos erros
específicos. Não ramifique por este campo.number
O status HTTP repetido no corpo. Presente quando o erro é devolvido diretamente, ausente quando é
lançado e passa pelo tratador geral. Nunca exija este campo no cliente.
string
required
Descrição da falha, para diagnóstico. Não é estável e está em inglês ou em português.
string
O campo para ramificar, quando existe. A maioria dos
400 não o traz: ele marca as recusas que
um cliente costuma querer tratar em código, não todas. Quando estiver ausente, use o status HTTP e
leia a message para diagnóstico. A lista completa está logo abaixo.Por que não ramificar por
code. Duas operações vizinhas devolvem tipos diferentes no mesmo
status: um 404 de GET /templates/{id} traz 10404, e um de GET /notifications/{id} traz
"NOT_FOUND". Um if (err.code === 10404) funciona em uma e falha em silêncio na outra.Os valores de error_code
Sete valores, e é esta a lista inteira.
Todo o resto vem sem
error_code, e aí o status HTTP é o que você tem. Em 400 isso inclui:
corpo JSON mal formado, channel fora dos dois canais, attachment_id enviado, Idempotency-Key
mal formada ou longa demais, telefone fora do formato, recipient_tax_id_type fora do enum,
parameters que não é objeto e todas as recusas de
multipart/form-data: ordem das partes, partes demais, tipo de arquivo e tamanho.
Se você já tem código lendo code
Se você já tem código lendo code
O campo
code carrega uma lista diferente de error_code, às vezes numérica (10000 + http_code) e às vezes em texto. Não ramifique por ele: o tipo muda entre operações vizinhas. Esta
tabela existe só para quem já tem código lendo o campo.400
A validação para no primeiro erro, e a ordem é a desta tabela. Ela importa porque tudo aqui acontece antes da reserva de crédito: nenhum envio é descontado enquanto você acerta o formato. Nummultipart/form-data, as recusas de parte vêm antes de todas as outras, porque as partes são lidas
primeiro.
As recusas de
multipart/form-data, todas 10400 e todas sem error_code:
ORGANIZATION_ID_FORBIDDEN tem duas redações. Em POST /notifications: organization_id is not accepted on this endpoint: the API key decides the organization. Em POST /templates:
organization_id must not be sent as a body field: it is taken from the API key. Mesmo
error_code.401
A resposta é idêntica nos três casos: o Pombo não informa qual deles ocorreu.
402
Único erro que se resolve sem alterar a requisição.
404
Um
template_id de outra organização em POST /notifications também responde 404, e não 403: a
distinção revelaria que o identificador existe.
Esse
404 vem direto da rota, então não traz request_id no corpo, ao contrário dos erros que
passam pelo tratador geral. O cabeçalho x-request-id está sempre presente: use o cabeçalho.409
Três causas, e o corpo diz qual é.
Conflito de contato. Os contatos são unificados pelo
tax_id, então o mesmo CPF com um telefone
diferente conflita em vez de criar uma segunda pessoa. O corpo traz campos extras para você
reconciliar.
string
tax_id_phone_mismatch, phone_tax_id_mismatch ou name_mismatch.object
O contato já cadastrado.
object
Os dados enviados, para comparação.
http_code, porque é lançado e não
devolvido.
413
Nada foi enviado e nada foi cobrado. A
message informa o tamanho e o limite.
É o único 413 desta API. Um anexo grande demais é 400, não 413.
422
O
10422 só acontece na criação do modelo, nunca no envio, e o corpo não diz qual regra falhou:
traz só Content policy violation detected.
429
500
O corpo é reduzido e não trazhttp_code.
request_id é o mesmo valor do cabeçalho x-request-id. Registre-o.
Depuração
Toda resposta traz o cabeçalhox-request-id.
x-request-id, o horário e o notification_id, quando houver.
