Skip to main content
Você pode chegar ao FireFlo por duas vias, e a escolha depende principalmente do volume e do que seu stack já fala.

REST

JSON sobre HTTPS. Uma chamada, uma mensagem. Comece por aqui, a menos que você tenha um motivo para não fazê-lo.

SMPP

Um bind persistente. Maior throughput, e o que as próprias operadoras falam.
Tudo depois da aceitação é idêntico. Mesmo roteamento, mesma tarifação, mesmas aprovações, mesmos recibos. A escolha afeta como você entrega uma mensagem, não o que acontece com ela.

Três coisas que surpreendem as pessoas

Vale conhecer antes da sua primeira integração, em vez de durante o seu primeiro incidente.
A resposta de submissão é enviada antes do roteamento rodar. Então 200, ou ESME_ROK, significa aceito para roteamento, e nada mais.Uma mensagem pode ser aceita e depois recusada, descartada ou falhar no roteamento, e a única forma de saber é por um recibo de entrega. Se sua integração tratar aceitação como entrega, ela vai errar exatamente nos casos que importam.
Em uma conta com whitelisting obrigatório, um from não aprovado é recusado, e também é um corpo de mensagem que não corresponde a nenhum template aprovado.Isso é normal para destinos regulados. O DLT indiano é o exemplo mais visível. Se seus envios funcionam em testes e falham em produção, é a primeira coisa a checar.
dlr_url e dlr-url são um único campo, e enviar os dois dá 400 em vez de valer o último.A única exceção é custom_tlvs, que mantém o sublinhado. custom-tlvs é um argumento desconhecido.

Para onde ir em seguida