¿Qué es Webhook?

En una configuración de webhook, la aplicación receptora registra una URL con la aplicación remitente y le indica qué eventos debe notificar. Cuando ocurre uno de esos eventos, la aplicación remitente realiza una solicitud HTTP POST a la URL registrada con una carga útil JSON que describe el evento. El receptor devuelve una respuesta 2xx para confirmar; si no lo hace, la mayoría de los remitentes reintentarán con retroceso exponencial.

Un flujo típico de bufete de abogados: CallRail recibe una llamada y envía un webhook a su CRM (GoHighLevel) con el número de la persona que llama, el número de seguimiento y la URL de la grabación de la llamada. GHL procesa el webhook, crea o actualiza un contacto y puede enviar su propio webhook a su agente de voz con IA o flujo de trabajo n8n.

El sondeo hace que el receptor llame a una API en un horario preguntando "¿qué hay de nuevo desde la última vez?" —simple pero de alta latencia y derrochador a bajas tasas de eventos. Los webhooks hacen que el remitente envíe los eventos a medida que ocurren —baja latencia y eficiente a bajas tasas, pero el receptor debe ser accesible y el modelo de seguridad es más complejo (verificación de firma, lista blanca de IP). Las APIs en tiempo real (WebSockets, SSE, gRPC streaming) mantienen una conexión abierta —lo mejor para tasas de eventos muy altas o tráfico bidireccional, pero operativamente más pesadas que los webhooks.

Para la mayoría de las integraciones de tecnología legal, los webhooks son la opción predeterminada correcta. CallRail → GHL → Clio funciona con webhooks. Los agentes de voz con IA suelen invocar llamadas a herramientas a través de webhooks a su CRM y sistema de gestión de práctica.

Tres cosas suelen afectar a los equipos nuevos en webhooks. (1) Idempotencia —los webhooks pueden entregarse más de una vez durante los reintentos. El receptor necesita manejar eventos duplicados (típicamente verificando un ID de evento y omitiendo repeticiones). (2) Verificación de firma —cualquiera que conozca la URL puede enviar una solicitud POST. Los webhooks de producción deben verificar un encabezado de firma para confirmar que la solicitud realmente provino del remitente esperado. (3) Manejo de fallos —si el receptor está caído cuando llega un webhook, el evento se pierde a menos que el remitente reintente (la mayoría lo hace, con límites). Es prudente construir una pequeña cola o búfer entre la recepción del webhook y el procesamiento posterior.