IOSOR

IOSOR Guías

Webhooks SMS inbound: reintentos, orden de eventos e idempotencia al recibir

Guía B2B del camino de recepción: cómo reintentan los webhooks SMS inbound, por qué el orden no está garantizado y cómo handlers idempotentes protegen ops prepago y macros de soporte.

El SMS outbound se lleva los dashboards. El inbound es donde aterrizan STOP, HELP y las respuestas de clientes — y donde handlers ingenuos inventan tickets duplicados, dobles efectos de monedero y fantasmas de cumplimiento “nunca recibimos el STOP”. Si su camino de recepción asume entrega exactamente-una-vez y en orden, fallará en el primer outage real.

IOSOR empaqueta el messaging inbound en la misma superficie white-label prepaga que el outbound: eventos verificables, payloads brand-safe, sin vivir en un portal ops ajeno para reconciliar una tormenta de respuestas.

Por qué los webhooks reintentan

En la mayoría de plataformas, los webhooks inbound prometen entrega al-menos-una-vez con reintentos, no orden mágico exactly-once.

  • POSTs duplicados del mismo evento lógico
  • Llegadas tardías tras un timeout
  • Entregas ocasionales fuera de orden frente a otro tipo de evento

La UX de producto puede sentirse ordenada si su store aplica un merge determinista — no si espera que el cable nunca falle.

Los tres modos de fallo que debe diseñar

Failure mode What happens What breaks if you ignore it
Duplicate delivery Same event ID arrives 2+ times Double-counted replies, doubled STOP, duplicate threads
Out-of-order events A later-timestamped event arrives first A delivered status regresses to sent
Partial/ambiguous failure You processed but the ack was lost The platform retries work you already did

Idempotencia: la propiedad que arregla los tres

El inbound no está libre de dinero ni de side effects de ops:

  • Los auto-replies pueden debitar el monedero prepago
  • El manejo de STOP debe suprimir futuros envíos de marketing
  • Las macros de soporte que abren tickets no deben abrir tres tickets por tres POSTs

Checklist de un handler de recepción idempotente:

Orden de eventos: por qué “last write wins” es peligroso

Supuestos falsos comunes:

  1. STOP llega antes del siguiente envío de marketing (hay carrera)
  2. El DLR outbound llega antes de la respuesta inbound (caminos independientes)

STOP, HELP y otras keywords inbound necesitan la misma disciplina

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.

Empezar con IOSOR

Saque los logs de webhook inbound de la semana y cuente IDs de evento que llegaron más de una vez. Reproduzca un duplicado y un par fuera de orden (failed, luego delivered). El receptor guarda un efecto: una fila de inbox, una escritura STOP, un toque de cartera. Last-write-wins que deshace STOP falla. Es idempotencia al recibir y orden de reintentos, no validación de firma ni candado de pasarela antes de la cola.

Conclusión IOSOR

Los webhooks inbound reintentan. La idempotencia al recibir es la única respuesta segura; el orden no es promesa.

Haga: clave el evento e ignore el gemelo. No haga: last-write-wins sobre STOP ni debitar el mismo evento dos veces.

¿Fue útil esta guía?

Guías relacionadas