Enviar o primeiro SMS pela API de um fornecedor leva uma tarde. O que vem depois — o que significa "enviado", o que acontece quando uma requisição expira, como um mensagem se atribui a um resultado de negócio e quanto custa trocar de fornecedor — é o que decide se a integração permanece sustentável ou vira um imposto permanente.
Um contrato interno estável, não chamadas ao SDK do fornecedor
A decisão mais importante é evitar que o código da aplicação chame diretamente o SDK de um fornecedor. Vale definir um contrato interno próprio — destino, corpo ou template, classe de tráfego, remetente, referência própria — e deixar tudo o que é específico do fornecedor atrás de um adaptador. Assim, incorporar um segundo fornecedor vira um novo adaptador, não uma reescrita.
Referências próprias e idempotência diante de timeouts ambíguos
É preciso gerar uma referência própria para cada mensagem antes de chamar o fornecedor, porque o caso interessante é aquele em que a requisição expira sem resposta: a mensagem pode ou não ter sido enviada. Vale usar chaves de idempotência do fornecedor quando existirem, ou consultar pela referência própria antes de tentar novamente, e definir uma política explícita por classe de tráfego para os casos ambíguos.
Remetente, registro e classe de tráfego
A identidade do remetente não é um valor livre: dependendo do mercado pode exigir sender ID alfanumérico registrado, número longo ou código curto, com prazos de registro de semanas. A classe de tráfego deve ser um campo obrigatório em todo envio, porque determina remetente, rota e se a mensagem é permitida naquele mercado.
Codificação e segmentação
GSM-7 permite 160 caracteres por segmento simples; um único caractere Unicode — uma aspa curva, um emoji, um nome acentuado — converte toda a mensagem para UCS-2, reduzindo o limite para 70. Como a cobrança é por segmento, vale calcular a codificação antes do envio, salvar a contagem no registro da mensagem e validar templates ao salvá-los.
Mapeamento de status, webhooks e retries
Cada fornecedor tem seu próprio vocabulário de status e erros; vale mapeá-los para um conjunto canônico próprio e tratar valores não reconhecidos como um alerta explícito. Os webhooks precisam de verificação de assinatura, proteção contra replay, tolerância a duplicatas e à chegada fora de ordem de eventos, e processamento assíncrono com reconciliação periódica de mensagens presas. Os retries devem ter um único responsável de política, com tentativas limitadas e um prazo final após o qual a mensagem é descartada em vez de entregue tarde.
Medição e saída do fornecedor
O comprovante de entrega é um proxy fraco do resultado: vale medir na camada de aplicação — conclusão da ação, cliques, taxas de resposta e opt-out — com um ID de correlação que abranja todo o percurso. A Flowstates fornece rotas de mensageria e pode operar essa camada; os clientes também podem manter seus próprios contratos via BYOV ou combinar ambos os modelos sob um único contrato operacional.
Os limites de segurança do SMS
O SMS comum não é criptografado ponta a ponta: o conteúdo fica visível para intermediários na cadeia de entrega e é armazenado em texto simples no aparelho, muitas vezes na tela de bloqueio. Nunca se deve enviar senhas, números de conta completos ou dados de saúde; códigos de uso único devem ter vida curta, vinculados à sessão que os solicitou, e nunca acompanhados do identificador da conta.