Skip to main content
Toda falha é um objeto JSON com um único message. O status é a parte legível por máquina.
O catálogo completo está em Erros da API. Esta página é sobre o que seu cliente deve fazer.

A tabela de retry

Não existe Retry-After em um 429. Faça backoff no seu próprio ritmo: exponencial, com jitter. Um intervalo fixo em vários workers os ressincroniza no próximo pico, e é assim que um rate-limit breve vira um sustentado.

Por que um 500 é seguro para repetir

500 Cannot send message significa que o gateway aceitou sua requisição e não conseguiu enfileirá-la. Qualquer cobrança é revertida. Isso é uma propriedade deliberada do ingresso, e não um acidente: o crédito é reservado antes de enfileirar e devolvido quando o enfileiramento falha. Então um retry custa uma mensagem, não duas. É exatamente a garantia que torna um retry automático defensável aqui, e não em um 402.

Construa para o recibo, não para a resposta

O erro de integração mais comum é tratar um 200 como entrega. A resposta de submissão é enviada antes do roteamento rodar, então aceitação e entrega são afirmações não relacionadas. Uma mensagem pode ser aceita e depois recusada por um remetente não aprovado, descartada por falta de rota ou rejeitada pela operadora. E nada disso pode aparecer na chamada original.
1

Guarde o messageId

É a única coisa que correlaciona seu registro com tudo o que vem depois.
2

Trate o envio como 'submetido', não 'enviado'

Um estado separado no seu próprio modelo, para que a diferença fique visível.
3

Mova para um estado final somente em um recibo de nível 2

ACCEPTD e BUFFRED chegam como nível 1 e outro recibo vem em seguida.
4

Expire no seu próprio relógio

Uma mensagem que nunca recebe um recibo final também deve expirar no seu sistema, ou ela fica “submetida” para sempre.

Erros que você encontra em produção, não em testes

Sua conta tem a aprovação de sender ID obrigatória. O from usado não foi aprovado, ou você o omitiu e o nome do seu login também não está aprovado.Não é passível de retry e não é corrigível em código. Precisa de uma aprovação do seu provedor.
Sua conta só envia textos aprovados. Uma mensagem que funciona em staging e falha em produção é geralmente isto.Espaços em branco são normalizados antes da comparação, então espaços e quebras de linha extras não são a causa. Uma palavra trocada, um ponto final adicionado ou uma variável em posição diferente é.
O crédito é reservado em blocos, não por mensagem. Cerca de vinte mensagens por vez, e as recargas são assíncronas. Uma mensagem que chega enquanto a próxima reserva está em andamento é recusada mesmo com saldo remanescente.Esse é transitório: repita. Um 402 que persiste com saldo saudável não é, e vale reportar.
Todos os outros campos tratam _ e - como o mesmo caractere. custom_tlvs é a única exceção e mantém o sublinhado.

Relacionados

Todos os status

O catálogo completo com o que provoca cada um.

Recibos de entrega

A metade da história que a resposta não conta.