Los webhooks son el mecanismo con el que Meta notifica a tu sistema eventos que ocurren en WhatsApp: mensajes entrantes, cambios de estado y otros eventos configurados. Sin webhooks, una integración solo sabría lo que ella envía; no tendría una visión confiable de lo que responde el usuario ni del estado posterior del mensaje.
Flujo básico
Meta realiza una solicitud HTTP a un endpoint público de tu aplicación. Tu servidor valida la solicitud, responde rápidamente y procesa el evento. En producción, conviene separar recepción de procesamiento: el endpoint confirma y coloca el evento en una cola; trabajadores internos actualizan CRM, ejecutan automatizaciones o notifican agentes.
Verificación y seguridad
- Utiliza HTTPS.
- Valida el proceso de verificación del webhook al configurar la suscripción.
- Verifica firmas de solicitudes según la documentación aplicable.
- No registres tokens ni datos sensibles en logs públicos.
- Aplica idempotencia porque un evento puede reintentarse.
- Mantén tiempos de respuesta bajos y procesa tareas pesadas fuera del request.
Evita duplicados
Guarda un identificador de evento o mensaje procesado. Si el mismo webhook llega dos veces, tu sistema debe reconocerlo y no crear dos pedidos, dos leads o dos respuestas. La idempotencia es especialmente importante cuando un evento dispara acciones con costo o efectos externos.
Qué monitorear
| Señal | Alerta |
|---|---|
| HTTP 5xx | Tu endpoint está fallando. |
| Latencia alta | Riesgo de reintentos y backlog. |
| Cola creciente | Procesadores no dan abasto. |
| Eventos sin correlación | Puede existir inconsistencia de IDs. |
| DLQ | Eventos que requieren análisis manual. |
Diseña para reintentos desde el primer día
Las redes fallan. Tu endpoint puede responder tarde o reiniciarse después de guardar un evento pero antes de confirmar. Por eso debes asumir que un webhook puede llegar más de una vez. Usa claves idempotentes y transacciones para que procesar el mismo evento dos veces no duplique mensajes ni acciones.
Correlaciona cada evento
Conserva IDs externos y tus IDs internos. Cuando un usuario reporta que “el mensaje no llegó”, necesitas recorrer la cadena: mensaje creado por tu sistema, ID devuelto por Meta, webhook de estado y registro en CRM. Sin correlación, el soporte termina revisando logs manuales sin saber qué buscar.
Plan de contingencia
Define qué ocurre si el CRM está caído pero el webhook sigue llegando. Una cola durable puede conservar eventos hasta que el servicio vuelva. Establece una dead-letter queue para eventos que fallaron repetidamente y una interfaz o procedimiento para reprocesarlos después de corregir la causa.