SMPP vs. API HTTP de SMSC: qual protocolo sua plataforma deve usar?

Quando você conecta uma plataforma de mensageria ao mundo externo, na prática está escolhendo como ela se comunica com as operadoras, e há duas respostas de uso amplo. Uma é o SMPP, o protocolo binário de telecomunicações que transporta SMS de aplicação para pessoa (A2P) há décadas. A outra é uma API HTTP, o mesmo modelo de requisição e resposta que sustenta o restante da web. Os dois não são exatamente rivais, e sim ferramentas para tarefas diferentes, e a conclusão honesta, que este guia desenvolve, é que qualquer coisa que se possa chamar de plataforma séria acaba suportando os dois. Veja o que realmente os diferencia, e por quê.

O que é o SMPP e por que as operadoras ainda o utilizam

O SMPP (Short Message Peer-to-Peer) é um protocolo binário usado sobre uma conexão TCP de longa duração, por convenção na porta 2775. Em vez de abrir uma nova conexão para cada mensagem, como faz uma requisição web, um cliente SMPP estabelece uma sessão persistente chamada bind, em um de três modos: transmitter (somente envio), receiver (somente recepção) ou transceiver (ambos em uma única conexão). Depois do bind, ele transmite continuamente pacotes binários compactos chamados PDUs: um submit_sm para enviar uma mensagem, um deliver_sm para receber uma mensagem ou uma confirmação de entrega, e um enquire_link como heartbeat para manter a sessão ativa.

O motivo pelo qual operadoras e grandes agregadores ainda padronizam o uso do SMPP é a eficiência em volume. Um bind persistente elimina a sobrecarga, por mensagem, de estabelecer uma conexão, e o SMPP suporta janelamento (windowing): o remetente pode manter várias mensagens em trânsito antes de aguardar as confirmações, de modo que um único bind saudável pode sustentar de centenas a alguns milhares de mensagens por segundo. Ele também foi criado especificamente para esse domínio, com campos nativos para sender ID, codificação de dados, períodos de validade, entrega agendada e flags de entrega registrada (registered delivery). Quando o seu tráfego é medido em milhões de mensagens por dia, essa densidade e esse controle não são luxo: são a diferença entre um servidor e dez.

O preço dessa capacidade é a complexidade. O SMPP mantém estado (stateful), então você precisa gerenciar os binds, reconectar em caso de queda, responder aos heartbeats, respeitar a janela e correlacionar as confirmações assíncronas pelo ID da mensagem. Ele também tende a exigir uma relação de IP estável, e por isso os binds com operadoras costumam ficar atrás de uma allowlist de IP ou de uma pequena VPN, e não expostos na internet aberta.

Onde as APIs HTTP de SMSC se encaixam

Uma API HTTP faz a escolha oposta. Você envia uma requisição por mensagem (ou por pequeno lote) para uma URL, recebe uma resposta JSON ou de formulário, e não há sessão a manter. A autenticação é um token ou uma chave em um cabeçalho, as confirmações de entrega retornam como chamadas de webhook para uma URL hospedada por você, e tudo passa por firewalls e balanceadores de carga comuns sem tratamento especial. Para um desenvolvedor, integrar um fornecedor HTTP leva uma tarde; integrar uma pilha SMPP é um projeto.

Essa simplicidade é exatamente o motivo pelo qual os fornecedores HTTP se multiplicaram. Muitos provedores regionais, agregadores de WhatsApp e RCS e novos participantes do mercado de CPaaS oferecem HTTP primeiro e SMPP apenas sob solicitação, ou nem oferecem. Para volumes baixos e médios, ou para um país que você alcança por meio de um único fornecedor especializado, uma rota HTTP não é uma concessão: é a escolha sensata. A sobrecarga por mensagem é maior e a vazão máxima bruta é menor do que a de um bind SMPP bem ajustado, mas você escala da forma convencional, horizontalmente, fazendo mais requisições simultâneas, e para a maioria dos revendedores esse limite está muito acima do tráfego real.

A limitação honesta está no controle e na consistência. Cada fornecedor HTTP define seus próprios nomes de campo, sua própria forma de representar Unicode e mensagens longas, e seu próprio formato de callback de DLR. Ao trabalhar com cinco fornecedores HTTP, você terá, na prática, integrado cinco produtos ligeiramente diferentes.

As diferenças reais: vazão, DLRs e codificação

Três detalhes técnicos causam quase todos os problemas na prática, por isso vale a pena ser preciso sobre eles.

Vazão e controle de fluxo. A vazão do SMPP é determinada pelo tamanho da janela e pela latência de ida e volta: com uma janela de, por exemplo, 10 PDUs sem confirmação e um link rápido, um único bind envia muito tráfego, e as operadoras impõem uma taxa contratada que você não pode ultrapassar, sob pena de sofrer limitação (throttling). A vazão do HTTP é determinada pelo número de requisições simultâneas que você faz e pelo limite de taxa (rate limit) do fornecedor, geralmente expresso em requisições por segundo. O resultado prático: o SMPP favorece um pequeno número de conexões persistentes bem gerenciadas, enquanto o HTTP favorece um pool de workers fazendo chamadas em paralelo. O desenho da fila e dos workers da sua plataforma muda de acordo.

Confirmações de entrega. É aqui que integrações simplistas falham. No SMPP, o DLR não é uma resposta ao seu submit; ele chega depois, sem ter sido solicitado, como um deliver_sm no seu bind, e você precisa associá-lo à mensagem original pelo ID que a operadora atribuiu no momento do envio. Se você não estiver escutando, ou se perder o bind, perde as confirmações. No HTTP, o DLR é um callback que o fornecedor envia por POST para o seu webhook, o que significa que o seu endpoint precisa estar acessível, ser idempotente (os fornecedores repetem as tentativas) e ser capaz de fazer a correlação pela sua própria referência. O conceito é o mesmo (entregue, com falha, expirada, rejeitada, desconhecida), mas são dois mecanismos totalmente diferentes para capturar de forma confiável.

Codificação de caracteres. O SMS não tolera erros nesse ponto. O alfabeto GSM 03.38 comporta 160 caracteres em uma única mensagem de 7 bits; ao sair dele (um emoji, muitos caracteres acentuados ou não latinos), a mensagem passa para UCS-2, que comporta apenas 70 caracteres por parte. Textos mais longos são divididos em segmentos unidos por um cabeçalho de dados do usuário, e cada segmento é cobrado. O SMPP expõe isso diretamente pelo campo data_coding e espera que você faça isso corretamente. Os fornecedores HTTP geralmente tentam abstrair essa questão, mas o fazem de forma inconsistente, e um fornecedor que rebaixa silenciosamente uma mensagem Unicode ou conta os segmentos de forma errada vai gerar custos sem aviso ou corromper o texto. Qualquer que seja o protocolo, a codificação é algo que a sua plataforma precisa tratar de forma deliberada, sem depender de que o fornecedor acerte.

Por que uma plataforma séria suporta os dois

Reunindo essas diferenças, a conclusão é direta. Sua melhor rota para um país pode ser um bind SMPP com uma operadora nacional; sua única rota para o próximo pode ser um especialista HTTP; o failover para ambos pode ser um terceiro fornecedor, no protocolo que ele oferecer. Se a sua plataforma só suporta um, suas opções de roteamento caem pela metade e suas negociações com fornecedores ficam condicionadas a uma limitação técnica, em vez de serem guiadas por preço e qualidade de entrega.

É por isso que um gateway maduro executa uma pilha SMPP e um cliente HTTP lado a lado e, normalmente, também oferece os dois aos seus próprios clientes: um servidor SMPP no qual os clientes técnicos fazem bind e uma API HTTP para todos os demais. O valor real da plataforma não está em nenhum dos dois protocolos, e sim na camada acima deles (o motor de roteamento, o faturamento, a normalização das confirmações de entrega), que torna a escolha do protocolo invisível para quem envia uma mensagem. Uma plataforma self-hosted como o Smppcube inclui tanto um servidor SMPP de nível de operadora quanto uma API HTTP justamente para que o operador, e não o protocolo, decida como o tráfego flui. Se você está avaliando operar essa stack por conta própria, o guia do gateway self-hosted trata do lado operacional.

Um único adaptador HTTP genérico para fornecedores (como funciona na prática)

A armadilha dos fornecedores HTTP, o fato de cada um ser sutilmente diferente, tem solução, e a solução é um padrão que vale a pena entender antes de comprar ou desenvolver. Em vez de escrever código específico para cada fornecedor, espalhado pela base de código, você define uma única interface interna, um formato normalizado único para “envie uma mensagem” e “aqui está uma confirmação de entrega”, e depois escreve um adaptador leve por fornecedor, que traduz entre as particularidades do fornecedor e esse formato interno.

Cada adaptador concentra exatamente as diferenças: como esse fornecedor faz a autenticação, como ele nomeia os campos de destino e de texto, como ele quer que o Unicode seja sinalizado e como converter o seu callback de DLR específico para o conjunto comum de status da plataforma. Tudo o que está acima (a fila, o roteador, o faturamento, os relatórios) se comunica apenas com a interface interna e não sabe nem precisa saber qual fornecedor está por trás. Integrar um novo fornecedor HTTP passa então a exigir uma configuração e um pequeno adaptador, e não uma reconstrução, e adicionar depois provedores de voz via API segue exatamente o mesmo padrão. É assim que uma plataforma se mantém aberta a dezenas de fornecedores regionais sem ser prejudicada pelas inconsistências deles, e esse é o desenho que um gateway self-hosted já deveria implementar, para que você nunca precise mexer em código de protocolo ao adicionar uma rota.

Qual você deve escolher?

Se você é um revendedor integrando seu primeiro fornecedor e ele oferece HTTP, comece por aí: é mais rápido de integrar, fácil de testar e suficiente para validar o seu negócio. Adicione SMPP quando o volume, um relacionamento com uma operadora ou um cliente técnico que queira fazer bind com você justificarem a infraestrutura adicional. Se você é um agregador ou uma operadora com volume significativo e acordos diretos com operadoras, o SMPP não é opcional: é o protocolo que os seus fornecedores usam.

O contraponto honesto a tudo isso: se puder evitar, não escolha protocolo nenhum. Escolha uma plataforma que já suporte os dois e oculte a diferença, para que sua energia vá para a qualidade das rotas e para os clientes, e não para a manutenção de uma pilha de protocolo binário. Esse é o propósito de comprar um gateway em vez de desenvolver um, e você pode ver como fica uma opção self-hosted, de sua propriedade integral, na página de preços. O protocolo deve ser um detalhe que você configura, nunca uma barreira que limita o seu negócio.