ublicamos uma breve análise sobre SMPP vs REST no início deste ano. A questão continua a surgir com mais nuances do que aquele artigo permitia, então aqui está o guia de decisão mais completo — aquele que realmente usamos para orientar novos clientes corporativos durante o planeamento da integração.
A diferença fundamental reside no modelo de conexão.
Uma API HTTP funciona com requisições e respostas em conexões de curta duração. Você envia uma mensagem via POST, recebe uma resposta e a conexão pode ser fechada. Já o SMPP é uma sessão TCP persistente e com estado — você se conecta uma única vez, mantém o socket aberto e transmite PDUs (submit_sm, deliver_sm) em ambas as direções por horas ou dias. Essa única diferença arquitetónica determina praticamente todas as compensações práticas descritas a seguir.
Taxa de transferência e latência
- HTTP: cada mensagem acarreta a sobrecarga do handshake TCP + TLS, a menos que se agrupem as ligações de forma agressiva. A BroadNet não define limites de taxa fixos por conta (veja limites de taxa da API), mas em volumes elevados, a sobrecarga por pedido torna-se o estrangulamento.
- SMPP: sem handshake por mensagem. Uma única conexão suporta confortavelmente centenas a milhares de TPS; a taxa de transferência é limitada pelo tamanho da janela negociada e pelo SMSC, não pelo estabelecimento da conexão.
- Para tráfego OTP, o SMPP elimina a etapa crítica do handshake TLS — o que é significativo quando se tenta transmitir um código de verificação em menos de dois segundos.
Comprovativos de entrega
Com o SMPP, os relatórios de entrega chegam como PDUs `deliver_sm` na mesma conexão em que você submete os dados — em tempo real, em banda, sem infraestrutura adicional. Com uma API HTTP, os relatórios de entrega regressam como callbacks de webhook para um endpoint que você aloja, o que significa que você precisa executar um serviço HTTPS publicamente acessível e de alta disponibilidade, além de conciliar os callbacks com as submissões. Nenhuma das duas abordagens está errada; são apenas compromissos operacionais diferentes.
Custo operacional — a parte que as equipas subestimam
Uma integração HTTP é algo que um único desenvolvedor de backend implementa numa tarde e praticamente esquece. Uma integração SMPP é infraestrutura: você precisa lidar com o ciclo de vida de vinculação/desvinculação, keepalives de enquire_link, reconexão automática com backoff, gestão de janelas, rastreio de números de sequência e failover adequado em múltiplas vinculações. Isso exige responsabilidade de engenharia contínua e real. Muitas equipas que são tecnicamente qualificadas para SMPP se beneficiam mais com HTTP simplesmente porque não querem operar uma pilha de protocolos de telecomunicações persistente.
Uma regra prática simples
- Tráfego com formato de aplicação abaixo de várias centenas de mensagens por segundo, equipa pequena — utilize a API HTTP.
- Para volume contínuo de várias centenas de mensagens por segundo ou necessidade de binds persistentes, OTP com latência crítica, se você é um agregador ou se já possui infraestrutura SMPP, utilize o SMPP 3.4.
- Necessidades mistas — muitos clientes da BroadNet usam SMPP para tráfego em massa e acionado por gatilhos, enquanto mantêm o HTTP para ferramentas internas de baixo volume. Não há nenhuma regra que impeça o uso de ambos.
O BroadNet expõe o mesmo mecanismo de encaminhamento, conformidade com o Sender ID e capacidade de entrega tanto em SMPP 3.4 quanto em HTTPS. O protocolo escolhido altera o formato da integração, não a qualidade da mensagem ou as rotas.
Algo que não é um fator decisivo.
O custo por mensagem é idêntico em todos os protocolos da nossa rede — escolher SMPP não gera desconto e escolher HTTP não acarreta sobretaxa. Escolha com base no modelo de conexão, nas necessidades de latência e na quantidade de recursos operacionais que a sua equipa deseja ter. Não se baseie numa diferença de preço que não existe.
Para a comparação completa lado a lado, veja SMPP vs API HTTP (REST) para SMS.