Definición
Un webhook es un mecanismo de comunicación automatizada entre sistemas: cuando ocurre un evento específico (por ejemplo, un pedido nuevo, un cambio de estado logístico o una actualización de inventario), la plataforma origen envía automáticamente una notificación HTTP POST a una URL previamente configurada. A diferencia de las APIs tradicionales donde tú preguntas, aquí el sistema te avisa.
En el contexto DTC (Direct-to-Consumer) y cross-border eCommerce, los webhooks son el pegamento que une tu tienda Shopify, tu ERP, tu WMS, tu proveedor logístico y tu pasarela de pago sin intervención manual.
Analogía
Imagina que tienes una tienda física y contratas a un mensajero. Con una API tradicional, tú debes llamar cada 5 minutos a la central para preguntar: "¿Hay pedidos nuevos? ¿Hay pedidos nuevos?". Eso consume recursos y añade latencia.
Con un webhook, la central te llama solo cuando entra un pedido. Tu mensajero recibe el aviso al instante, con los datos ya empaquetados (número de pedido, SKU, dirección, importe). No preguntas: te informan. Eso es un webhook: una llamada entrante automática disparada por un evento.
Fórmula técnica
Un webhook se define por cuatro parámetros:
Webhook = URL_destino + Evento_disparador + Payload(JSON/XML) + Método_HTTP
- URL destino: endpoint HTTPS público (ej. https://tuapp.com/hooks/pedidos)
- Evento disparador: order.created, fulfillment.updated, payment.captured
- Payload: cuerpo con datos estructurados (típicamente JSON)
- Método HTTP: casi siempre POST, a veces PUT
Ejemplo de payload típico:
{
"event": "order.created",
"order_id": "SP-2024-88731",
"total": 149.90,
"currency": "EUR",
"items": 3,
"timestamp": "2024-11-15T10:23:41Z"
}
Comparativa: Webhook vs. Polling vs. API REST
| Característica | Webhook | Polling | API REST (pull) |
|---|---|---|---|
| Dirección | Push (servidor → tú) | Pull (tú → servidor) | Pull (tú → servidor) |
| Latencia típica | 200–800 ms | 30–300 s | 1–5 s |
| Consumo de peticiones | 1 por evento | 12–720 por hora | Bajo demanda |
| Coste servidor | Muy bajo | Alto | Medio |
| Complejidad setup | Media (endpoint + firma) | Baja | Baja |
| Ideal para | Pedidos, tracking, pagos | Reportes diarios | Consultas puntuales |
| Riesgo principal | Fallos de entrega | Datos obsoletos | Rate limits |
Aplicaciones reales en DTC cross-border
1. Sincronización de pedidos: Shopify envía un webhook a tu ERP cuando se crea un pedido. Sin webhooks, un negocio con 500 pedidos/día tendría que hacer 500 llamadas API adicionales, incrementando el coste de infraestructura un 40–60 %.
2. Tracking logístico en vivo: Tu proveedor 3PL (ej. Cainiao, YunExpress) dispara un webhook cada vez que el paquete cambia de estado. Esto permite actualizar la página de seguimiento del cliente en menos de 1 segundo.
3. Confirmación de pago: Stripe o Adyen envían un webhook payment_intent.succeeded. Tu sistema libera el pedido a almacén automáticamente. Sin esto, el 12 % de los pedidos quedarían en limbo por timeout.
4. Gestión de devoluciones: Cuando el cliente abre una disputa en tu portal, un webhook avisa al equipo de atención al cliente y al sistema de reembolsos en simultáneo.
5. Sincronización de stock multi-canal: Si vendes en Amazon, TikTok Shop y tu web DTC, cada venta dispara un webhook que descuenta inventario en los tres canales en menos de 2 segundos, evitando overselling.
Errores comunes (y cómo evitarlos)
1. No verificar la firma HMAC. Cualquiera puede enviar un POST falso a tu endpoint. Siempre valida la cabecera X-Signature con tu secreto compartido.
2. No implementar reintentos idempotentes. Los webhooks pueden llegar duplicados. Si no usas un event_id único, procesarás el mismo pedido dos veces. Los proveedores serios reintentan hasta 5 veces con backoff exponencial.
3. Responder con códigos incorrectos. Tu endpoint debe devolver 200 OK en menos de 5 segundos. Si devuelves 500 o tardas más, el emisor asumirá fallo y reintentará, saturando tu sistema.
4. Ignorar el orden de llegada. En eventos de fulfillment, un shipped puede llegar antes que un packed. Usa timestamps o secuencias para ordenar.
5. Exponer secretos en logs. Nunca registres el payload completo con datos de tarjeta o tokens. Cumple PCI-DSS y GDPR.
6. No monitorizar fallos. Configura alertas si tu tasa de éxito baja del 99 %. Un webhook perdido = un pedido no enviado = un cliente enfadado.
7. URLs no HTTPS. Los emisores serios rechazan endpoints HTTP. Usa siempre TLS 1.2+.
Datos concretos del sector
- Latencia media de un webhook bien configurado en Shopify → ERP: 340 ms.
- Reducción de costes de infraestructura al migrar de polling a webhooks en un DTC con 10 000 pedidos/mes: ~55 %.
- Tasa de fallo de webhooks sin reintentos: 8–15 %. Con reintentos exponenciales: <0.5 %.
- Ahorro de llamadas API: un negocio que pasaba de 720 000 peticiones/mes a 12 000 webhooks/mes reduce su factura cloud un 62 %.
Términos relacionados
- API REST: interfaz donde tú inicias la petición.
- Polling: consulta periódica programada.
- Endpoint: URL que recibe el webhook.
- Payload: cuerpo de datos enviado.
- HMAC: firma criptográfica para validar autenticidad.
- Idempotencia: propiedad que evita procesar el mismo evento dos veces.
- Backoff exponencial: estrategia de reintentos con espera creciente.
- Event-driven architecture: paradigma basado en eventos, del que el webhook es la pieza básica.
- 3PL: operador logístico tercerizado que suele emitir webhooks de tracking.
- OMS / ERP: sistemas que consumen webhooks para orquestar pedidos.
En resumen: si tu negocio DTC cross-border mueve más de 100 pedidos al día y aún dependes de polling o de importaciones CSV manuales, los webhooks no son una mejora: son una necesidad operativa. Bien implementados, con firma HMAC, idempotencia y monitorización, convierten tu stack en un sistema reactivo en tiempo real, reducen costes cloud y eliminan la principal causa de pedidos bloqueados: la desincronización entre plataformas.
