# O custo operacional de uma integração de SMS: binds, webhooks e modos de falha

> Não se trata apenas de uma questão de taxa de transferência. O modelo de conexão, a gestão de DLR (Distributed Resource Layer), o custo operacional e os modos de falha são todos diferentes. Uma estrutura prática para escolher a integração certa.

- URL canônico: https://www.broadnet.me/pt/blog/smpp-vs-http-api-decision-guide
- Idioma: pt
- Última atualização: 2026-10-20
- Editor: BroadNet (https://www.broadnet.me)

- Publicado em: 2026-04-28
- Autor: BroadNet Engineering

Publicamos 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](https://www.broadnet.me/developers/rate-limits)), 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](https://www.broadnet.me/compare/sms-api-vs-smpp).