Black Friday 2024. Un vendedor gestionaba tres tiendas desde un único almacén, y los pedidos de TikTok Shop llegaban al WMS con seis horas de retraso. El SKU estrella se agotó en cuarenta minutos; la plataforma seguía mostrando stock disponible. Más de trescientas sobeventas, y la línea de atención al cliente colapsó. El equipo del almacén se sintió injustamente acusado — el stock estaba ahí; los pedidos simplemente llegaron tarde. La causa raíz no estaba en el almacén. Estaba en el diseño de la ingesta de pedidos, mal elegido desde el primer día.
Hace diez años, multicanal significaba «tenemos una tienda en Shopify». Hoy es Shopify, Amazon, TikTok Shop y Walmart a la vez, con pedidos entrando a un solo WMS desde cuatro frentes. Solo hay dos formas de canalizarlos: el polling — preguntar a cada plataforma cada pocos minutos «¿hay pedidos nuevos?» — o los webhooks, donde la plataforma envía los pedidos nuevos en el momento en que ocurren. La elección decide si la latencia de tus pedidos se mide en minutos o en segundos, y si duermes o apagas incendios en los días pico.
La diferencia no es solo la velocidad
La mayoría lo trata como una elección entre rápido y lento. Eso es ingenuo. Los dos enfoques difieren en cuatro ejes:
Latencia. La latencia del polling equivale a tu intervalo de sondeo: sondea cada cinco minutos y la latencia media es de dos minutos y medio. Los webhooks llegan en segundos. Nadie nota dos minutos y medio en un martes normal. Cuando un SKU estrella se vende en cuarenta minutos, ese retraso multiplicado por cuatro plataformas es sobeventa.
Costo. El polling gasta tu presupuesto de llamadas a la API. La SP-API de Amazon impone límites de frecuencia estrictos; si superas tu cuota, te ralentizan. Cuanto mayor sea tu volumen, más a menudo sondeas y más cerca navegas del muro del límite de frecuencia. Los webhooks no consumen tu cuota — la plataforma envía, tú recibes.
Fiabilidad. El polling rara vez pierde un pedido — si preguntaste, obtuviste la respuesta. Los webhooks mueren de dos maneras: la plataforma envió y tú nunca lo recibiste (un parpadeo de red), o lo recibiste y no lo procesaste bien (reinicio del servicio). Por eso los webhooks exigen reintentos e idempotencia: el mismo pedido enviado tres veces debe existir exactamente una vez en el WMS. He visto a más de una operación aprenderlo durante el pico, cuando la creación duplicada de pedidos significó envíos dobles.
Soporte de plataforma. No todas las plataformas ofrecen webhooks. Los de Shopify son maduros, TikTok Shop ofrece notificaciones push de pedidos, Amazon se apoya en su mecanismo de Notificaciones SP-API — cada uno con su propia semántica. Consulta la documentación actual para desarrolladores de cada plataforma; no apliques el conocimiento de integración del año pasado a las APIs de este año.
El caso de Amazon merece una advertencia especial. Los límites de frecuencia de SP-API son por operación y se aplican de verdad — conozco un 3PL que sondeaba el estado de los pedidos de forma agresiva durante un pico de Prime Day, fue ralentizado durante casi una hora, y pasó esa hora a ciegas mientras los pedidos se acumulaban. Su solución fue un limitador token-bucket de su propio lado más backoff exponencial, que es lo que deberían haber construido el primer día. Si sondeas Amazon, presupuesta tu cuota como si fuera dinero: asigna a cada tarea una asignación de llamadas, registra el consumo y alerta al 80%. Ser ralentizado durante el pico es una herida autoinfligida.
Mi recomendación: elige según el volumen de pedidos
Olvida el debate tecnológico. Mira tu propio volumen y elige el nivel que corresponda:
Menos de 500 pedidos al día: el polling basta. Sondea las cuatro plataformas cada cinco minutos. La latencia es aceptable, el desarrollo le toma a un ingeniero unos días. Invierte el tiempo ahorrado en la reconciliación.
De 500 a 5,000 al día: webhooks como vía principal, polling de respaldo. Los webhooks manejan el tiempo real; una extracción completa cada hora atrapa lo que los webhooks dejaron caer. La mejor combinación de valor por esfuerzo que conozco, y la configuración más común entre los vendedores medianos con los que he trabajado.
Más de 5,000 al día: webhooks hacia una cola de mensajes, más reconciliación. Los envíos caen en una cola para absorber los picos, los consumidores deduplican de forma idempotente, y una reconciliación total nocturna compara los pedidos de la plataforma contra los pedidos del WMS. Prueba de carga una tormenta de envíos antes del pico — las plataformas envían más tarde y duplican más durante sus propios grandes eventos, y entrar sin pruebas es volar a ciegas.
Sea cual sea tu nivel, tres reglas son innegociables. Una: haz del ID de pedido de la plataforma una clave única global y descarta silenciosamente los duplicados. Dos: verifica siempre las firmas de los webhooks — he visto una operación que se saltó la verificación para ahorrar tiempo y terminó con la base de datos inundada de pedidos falsificados. Tres: mantén funcionando una tarea de reconciliación total cada hora. Este es el seguro de vida de todo almacén multicanal — los webhooks fallan, el polling pierde pedidos, la reconciliación no miente.
Esa tarea de reconciliación merece una nota de diseño propia, porque la mayoría de los equipos la construyen mal. No compares «pedidos creados en la última hora» — compara el conjunto completo de pedidos abiertos de cada plataforma contra los pedidos abiertos del WMS, por ID de pedido de plataforma. La tarea debe producir exactamente tres listas: pedidos de la plataforma que faltan en el WMS (brecha de ingesta — tráelos), pedidos del WMS que faltan en la plataforma (cancelados o reembolsados en origen — márcalos para revisión), y desajustes de estado (enviado en un lado, pendiente en el otro — investiga). Ejecútala cada hora, avisa a alguien sobre la primera lista, y registra las otras dos. Una hora de ingeniería aquí te salva un Black Friday.
¿Ese vendedor de la historia inicial? Migró a webhooks más reconciliación cada hora. El siguiente Black Friday: 20,000 pedidos en cuatro plataformas, cero sobeventas. Ningún patrón de ingesta es inherentemente superior — solo existe el que coincide con tu volumen. Cuenta tus pedidos primero, luego elige el conducto. Nunca al revés.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
