Una reserva que no llega al CRM, un expediente creado dos veces, un recordatorio enviado después del pago: estos incidentes pueden deberse a una automatización que no está preparada para los imprevistos. En 2026, conectar WordPress, una herramienta de reservas y un programa de gestión no basta. Para una pyme de Niza o Cannes, también importa preguntarse: ¿qué ocurre cuando falla la conexión?

Un webhook es una notificación entre aplicaciones

Un webhook permite que un servicio avise a otra aplicación cuando se produce un evento. Por ejemplo, una plataforma de pagos comunica un cobro al CRM, que actualiza la ficha del cliente. Esta notificación suele llegar a una dirección web preparada para recibirla.

El mecanismo parece sencillo. Sin embargo, hay que distinguir entre el evento, su entrega y la acción que desencadena. Recibir una notificación no significa que toda la cadena haya terminado su trabajo.

Confirmar la recepción sin perder el trabajo pendiente

Según el servicio, la falta de respuesta o un error pueden provocar un nuevo envío. Los plazos y las opciones de recuperación varían: no debe suponerse que todos los proveedores se comportan igual.

Pida a su proveedor que separe la recepción de las operaciones largas. Si una notificación válida requiere procesamiento, el sistema debería almacenarla primero de forma duradera y después confirmar su recepción conforme a las reglas del proveedor. Una cola puede organizar el trabajo posterior en segundo plano. GitHub recomienda expresamente el procesamiento asíncrono para responder con rapidez.

Esta confirmación no demuestra que el CRM se haya actualizado. Si ese paso falla, el sistema debe conservar la tarea y prever un nuevo intento. Responder inmediatamente sin garantizar su almacenamiento puede hacer que el trabajo desaparezca tras una avería.

Evitar que una notificación repetida genere un duplicado

Shopify documenta el uso de un identificador de entrega para detectar notificaciones repetidas. En su integración, elija el identificador adecuado para cada proveedor y registre su estado: recibido, en proceso, completado o con error.

No marque una acción como completada en cuanto llegue. Si el procesamiento se interrumpe después, podría ignorarse el siguiente intento aunque la operación no haya terminado. Pida también una protección contra el procesamiento simultáneo del mismo evento.

El comportamiento esperado tiene un nombre técnico: idempotencia. Repetir la misma operación debe producir el mismo resultado de negocio. Así, una reserva ya registrada actualiza el expediente existente en lugar de crear otro. Esta protección también debe cubrir acciones externas, como enviar un mensaje. Si la API de destino admite una clave de idempotencia, utilícela conforme a su documentación; de lo contrario, prevea una comprobación del resultado antes de repetir una acción cuyo desenlace sea incierto.

Gestionar los retrasos y recuperar los datos que faltan

Stripe no garantiza el orden de entrega de los eventos. Por tanto, una notificación antigua no debe sobrescribir sin comprobaciones un estado más reciente del CRM. Según la API, verifique la versión de los datos o consulte su estado actual antes de realizar un cambio sensible.

Shopify también recomienda comprobaciones periódicas mediante API para conciliar los datos de ambos sistemas. Ajuste la frecuencia a su actividad y a los límites del servicio. Por ejemplo, compare las reservas confirmadas con los expedientes del CRM y examine las diferencias antes de corregirlas.

Controles que conviene solicitar antes de la puesta en marcha

Pruebe una interrupción y su recuperación, además de una transmisión correcta:

  • Reenviar el mismo evento sin crear un nuevo expediente.
  • Simular una caída del CRM y comprobar después la recuperación.
  • Recibir un evento antiguo después de otro más reciente.
  • Activar una alerta cuando una tarea quede bloqueada.
  • Verificar la autenticidad de las notificaciones con el mecanismo del proveedor, incluida su firma cuando esté disponible.

La documentación de GitHub explica, por ejemplo, cómo verificar una firma mediante un secreto compartido. Los registros deberían permitir localizar el identificador, la hora, el resultado y cualquier error sin copiar innecesariamente los datos de los clientes.

Adaptar la fiabilidad a su actividad

Un autónomo en Mónaco y una empresa de reservas en los Alpes Marítimos tienen necesidades distintas. Empiece por el flujo cuyo fallo tendría el mayor coste. NIKAIA.NET puede ayudarle a diseñar integraciones PHP, WordPress y CRM con reglas de recuperación explícitas e incidencias visibles.

Puntos que verificar antes de publicar

Revisar las políticas actuales de entrega y reintento de los proveedores, los identificadores disponibles, los mecanismos de firma, la compatibilidad con claves de idempotencia y los límites de las API. Comprobar que los ejemplos correspondan a los conectores realmente utilizados.