Skip to main content
Ramifique pelo status HTTP e por 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.
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. Num multipart/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 é.
Um nome de modelo repetido quase nunca dá 409. O caminho normal é o Pombo renomear sozinho, acrescentando -2, -3, e devolver 201 com um modelo novo. Como a API não lista modelos, esse modelo fica inalcançável. Veja Idempotência.
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.
Corrija a divergência antes de repetir. A mesma requisição devolve o mesmo conflito. Chave idempotente reutilizada. Esse corpo vem sem http_code, porque é lançado e não devolvido.
A chave já foi usada com outro corpo. Veja Idempotência.

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 traz http_code.
O request_id é o mesmo valor do cabeçalho x-request-id. Registre-o.
Um 500 em POST /notifications não garante que nada foi enviado. Consulte antes de repetir: uma notificação extrajudicial emitida não pode ser cancelada.

Depuração

Toda resposta traz o cabeçalho x-request-id.
Registre esse valor junto com os seus próprios logs. É por ele que o suporte encontra a requisição exata, e sem ele a investigação começa por adivinhação. Ao abrir um chamado, informe o x-request-id, o horário e o notification_id, quando houver.