¿Qué es un webhook y por qué los necesita tu pyme?
Definición clara, cómo funciona, diferencias con APIs REST tradicionales, casos prácticos pyme y buenas prácticas para implementarlos de forma robusta.
Actualizado mayo 2026
Webhook: la forma en que un sistema avisa a otro de que ha pasado algo.
Un webhook es una petición HTTP que un sistema envía automáticamente a una URL de otro sistema cuando ocurre un evento. La idea: en lugar de que el sistema receptor pregunte cada rato "¿hay novedades?", el sistema emisor avisa proactivamente "ha pasado X". Se le llama también "HTTP callback" o "reverse API".
Ejemplo: Stripe envía un webhook a tu servidor cada vez que se produce un pago, una suscripción cambia o un reembolso ocurre. Tu servidor recibe ese aviso con los detalles del evento en formato JSON y actúa: enviar factura, actualizar CRM, marcar pedido como pagado. No tienes que preguntar a Stripe constantemente; Stripe te avisa.
La diferencia con una API REST tradicional: con la API, tú llamas al sistema externo para obtener información (pull). Con webhooks, el sistema externo te llama a ti cuando hay novedad (push). Webhooks son eficientes (no consultas en vacío) y casi tiempo real (segundos de retardo). En pymes son la base de cualquier integración seria entre apps SaaS.
Anatomía de un webhook en cinco partes.
URL de destino
El receptor publica una URL pública (ej. https://api.mipyme.io/webhooks/stripe). El emisor envía ahí las peticiones HTTP POST cuando hay un evento. La URL es la dirección donde escuchas.
Payload (cuerpo)
JSON con los datos del evento: tipo, identificador, datos asociados. Ejemplo Stripe: {"type": "payment_intent.succeeded", "data": {...}}. Tu código lo parsea y reacciona.
Cabeceras de seguridad
Firma criptográfica (HMAC) en una cabecera del tipo X-Signature. Verifica que el webhook viene del emisor legítimo y no de un atacante. Sin esta verificación, cualquiera puede mandar webhooks falsos.
Respuesta HTTP
Tu servidor responde con código 2xx (200, 201, 204) si todo OK. Códigos 4xx/5xx indican problema. Si fallas, el emisor reintenta (con backoff exponencial en sistemas serios).
Idempotencia
Los webhooks pueden llegar duplicados (por reintentos). Tu código debe ser idempotente: procesar el mismo evento varias veces produce el mismo resultado, no efectos secundarios.
Cola de retries
Sistemas serios (Stripe, GitHub) reintentan webhooks fallidos durante horas/días con backoff exponencial. Da margen para incidencias pero exige idempotencia en tu lado.
Seis usos reales de webhooks en pymes B2B.
Pagos Stripe → contabilidad
Cada pago confirmado en Stripe dispara webhook a tu sistema, que crea factura en Holded y manda email cliente. Cero trabajo manual al cierre de mes.
Forms → CRM en tiempo real
Typeform o Tally envían webhook con cada nuevo lead. Tu servidor o tu n8n lo recibe, enriquece y crea oportunidad en HubSpot en segundos. Velocidad de respuesta crítica.
GitHub/GitLab → CI/CD
Push a la rama main dispara webhook a Vercel o Netlify que despliega automáticamente. Patrón estándar de cualquier desarrollo moderno.
Calendly → onboarding
Reserva nueva en Calendly dispara webhook que crea oportunidad CRM, manda email pre-reunión con agenda, prepara carpeta Drive con plantillas.
WhatsApp Cloud API → atención al cliente
Mensaje entrante en tu número de WhatsApp Business dispara webhook a tu sistema que clasifica con IA y enruta al equipo correcto.
Email parsing → ticketing
Email a soporte@... pasa por Mailgun/SendGrid que dispara webhook a tu sistema. Crea ticket, asigna, responde automáticamente con acuse.
Seis reglas para webhooks robustos en producción.
Verifica siempre la firma HMAC
Sin verificación, cualquiera puede hacer peticiones a tu endpoint falsificando datos. Comprueba que la cabecera firma con la clave secreta acordada antes de procesar.
Responde rápido (menos de 5 s)
Si tu lógica es lenta, encola el evento (Redis, SQS, Pub/Sub) y procesa asíncronamente. Responde 200 enseguida. Si tardas, el emisor reintenta y se duplican eventos.
Idempotencia obligatoria
Cada webhook trae un ID único de evento. Guárdalo y comprueba antes de procesar: si ya lo viste, ignora. Evita duplicar facturas, emails, registros.
Logs detallados
Loguea cada webhook recibido con timestamp, payload y resultado. Imprescindible para depurar problemas en producción. Si falla algo, sin logs no sabes qué pasó.
Endpoint con alta disponibilidad
Si tu servidor está caído, pierdes webhooks (aunque los buenos reintentan). Usa hosting fiable (Vercel, Cloudflare Workers, Railway) con SLA 99.9%+.
Monitorización y alertas
Alerta si pasan X minutos sin webhooks (puede indicar problema), si hay tasa elevada de 5xx, si el payload viene malformado. Detección temprana evita acumulación.
Webhooks en el ecosistema técnico pyme.
Los webhooks son complemento de las APIs REST: la API es para que tú consultes (pull), el webhook es para que el sistema te avise (push). Una integración seria usa ambas. Webhooks reducen latencia y consumo de cuotas API.
Las herramientas no-code como Zapier, Make y n8n exponen webhooks entrantes (URLs públicas que disparan flujos) y consumen webhooks salientes. Permiten usar webhooks sin escribir código.
Si en tu pyme las integraciones críticas (CRM-ERP, pagos, atención al cliente) no usan webhooks, hay sincronizaciones lentas o procesos manuales innecesarios. En Magnetia diseñamos integraciones serias con webhooks como parte de automatización de procesos con IA. Ver también guía integrar CRM y ERP en pyme.
Dudas que nos hacéis llegar
¿Integraciones lentas o procesos manuales por falta de webhooks?
Diseñamos integraciones serias con webhooks robustos, idempotentes y monitorizados. Cofinanciable por Kit Consulting.