IOSOR

IOSOR Guias

Webhooks SMS inbound: retries, ordem de eventos e idempotência na receção

Guia B2B do caminho de receção: como os webhooks SMS inbound fazem retry, por que a ordem não é garantida e como handlers idempotentes protegem ops pré-pagas e macros de suporte.

Gerir webhooks de SMS inbound exige uma arquitetura preparada para duplicados, atrasos de carriers e eventos fora de ordem. Como qualquer sistema de entrega at-least-once, o endpoint de receção deve implementar idempotência rigorosa e validação de sequenciamento para evitar o processamento duplicado de palavras-chave como STOP. O IOSOR entrega SMS inbound, palavras-chave STOP/HELP e eventos de entrega como webhooks pré-pagos white-label, garantindo a resiliência necessária para integrações B2B críticas.

Porque os webhooks fazem retry

Na maioria das plataformas, webhooks inbound prometem entrega at-least-once com retries, não ordem mágica exactly-once.

  • POSTs duplicados do mesmo evento lógico
  • Chegadas tardias após timeout
  • Entregas ocasionais fora de ordem relativamente a outro tipo de evento

A UX de produto ainda pode parecer ordenada se a sua store aplicar um merge determinístico — não se esperar que o fio nunca falhe.

Os três modos de falha para os quais deve desenhar

Traço de retry Pergunta do comprador Resposta saudável
Backoff Os retries saturam a app? Backoff exponencial / com jitter documentado
Orçamento Até quando a plataforma retenta? Horizonte de retry escrito
Assinatura Pode rejeitar falsificações? Callbacks autenticados
Os seus 5xx E se estiver down 10 minutos? Retries continuam; recupera de forma idempotente .

Trate um pico de entregas duplicadas como prova de que o sistema de retry funciona — não como incidente, a menos que os side effects não sejam idempotentes.

Idempotência: a propriedade que corrige os três

Inbound não está livre de dinheiro nem de side effects de ops:

  • Auto-replies podem debitar a carteira pré-paga
  • O handling de STOP deve suprimir futuros envios de marketing
  • Macros de suporte que abrem tickets não devem abrir três tickets para três POSTs

Checklist de um handler de receção idempotente:

  1. Persistir o inbound event id antes de side effects
  2. Short-circuit duplicados com o outcome anterior
  3. Fazer os envios de auto-reply levarem a sua própria chave de idempotência
  4. Registar correlação: inbound id → linha de carteira → reply id

Ordem de eventos: porque “last write wins” é perigoso

Webhook events for the same message are not guaranteed to arrive in occurrence order. A retry of an earlier queued event can land after a later delivered event. If your handler overwrites status with whatever just arrived, a stale late event can silently regress a delivered message. Compare timestamps (or a monotonic sequence) before writing.

Compliance-critical inbound keywords deserve the strictest idempotency. A duplicated STOP must never double-log an opt-out or send two confirmations. A duplicated HELP must never fire two help messages to the same number in the same minute. Route keyword processing through the same dedupe table as regular inbound messages.

Sinais de alerta

  • “Nunca fazemos retry” (vai perder eventos de compliance)
  • Sem event id — só timestamps
  • Docs que assumem ordem global estrita
  • Tempestades de auto-reply sem rasto na carteira
  • Ops que exige portal de terceiros para replay de inbound.

Comece com IOSOR

No console: Inbound SMS webhook retries stay idempotent; no double MO side-effects.. Nomeie o dono e os gates antes de escalar.

Relacionado: inbound autoreply loop wallet drain inbound carrier latency webhook time.

Resumo IOSOR

Disciplina ops de plantão—não brochure.

Faça: name owner + gate. Não: skip the gate.

Este guia foi útil?

Guias relacionados