¿Por qué tu automatización crea registros duplicados?

Un webhook es una notificación que un sistema envía a otro cuando ocurre algo. Stripe documenta que un mismo evento puede llegar más de una vez. Recibirlo nuevamente no debería crear automáticamente otro registro empresarial.

Empieza con una pregunta concreta: si una solicitud de servicio se entrega dos veces, ¿el negocio debería ver una solicitud o dos? Acuerda el resultado previsto antes de elegir una herramienta. Diseñar reintentos que conserven ese resultado es el propósito de la idempotencia.

No atribuyas todos los registros parecidos a un reintento. Un cliente puede enviar dos solicitudes legítimas. Las reglas deben distinguir la entrega repetida de una solicitud de otra solicitud de la misma persona.

Registra el sistema y la cuenta de origen, el identificador original del evento y la solicitud a la que se refiere. GitHub, por ejemplo, documenta que el reenvío solicitado de un webhook conserva su identificador X-GitHub-Delivery original. Comprueba el comportamiento del proveedor concreto; no supongas que todas las plataformas usan los mismos campos.

Recomendamos definir la identidad en dos niveles: la notificación recibida y la acción empresarial que solicita. El identificador del evento por sí solo puede no indicar si una segunda notificación corresponde a una solicitud ya creada. Decide qué tipos de evento crean registros y cuáles actualizan uno existente.

El correo electrónico por sí solo no identifica bien una solicitud: una persona puede necesitar varios trabajos. Los identificadores ausentes o contradictorios deberían pasar a revisión, en lugar de tratarse silenciosamente como una solicitud nueva.

Pregunta al desarrollador cómo evita el flujo que dos intentos simultáneos creen el mismo registro. Una secuencia separada de 'buscar coincidencia y después crear' puede dejar un intervalo entre ambas operaciones. La decisión de unicidad necesita protección en el almacenamiento o sistema de destino.

PostgreSQL documenta restricciones de unicidad sobre una columna o una combinación de columnas. También importa exigir los identificadores: su tratamiento predeterminado de NULL puede permitir filas repetidas aunque exista una restricción de unicidad. Es una opción de implementación, no una exigencia de sustituir tu base de datos.

Un registro local único no impide por sí solo enviar otro correo o duplicar una tarea en otra plataforma. Revisa por separado cada acción externa.

Proponemos los estados recibido, en curso, completado y requiere revisión. Define qué significa cada uno y quién puede resolver una operación detenida. Aceptar una notificación no demuestra que se haya actualizado el CRM o creado correctamente la tarea posterior.

Antes de reintentar una acción cuyo resultado sea incierto, busca en el destino evidencia de que ya ocurrió. Cuando el destino admita claves de idempotencia, comprueba su alcance, conservación y reglas de reutilización. No supongas que una clave garantiza todos los pasos posteriores. Si no puedes confirmar el resultado, detén el reintento y solicita revisión.

Conserva un historial útil: identificador de operación, hora del intento, referencia del destino y resultado. Limita los datos del cliente en los registros, asigna accesos y acuerda cuánto tiempo se necesita la evidencia para recuperar fallos. Son decisiones del proyecto, no un plazo universal de conservación.

Stripe también documenta que no garantiza el orden de entrega de eventos. Esto justifica comprobar las reglas de orden de cada integración que quieras utilizar.

Prepara una prueba donde una actualización de estado antigua llegue después de una nueva. Decide qué fuente determina el estado vigente y cómo se deriva a una persona un conflicto incierto. Evita que únicamente la hora de llegada sobrescriba un estado empresarial confirmado.

Este ejemplo es hipotético, no un resultado medido de un cliente: envía cinco notificaciones en el orden E41, E41, E42, E42, E41. Supongamos que E41 y E42 representan, cada uno, una solicitud de servicio nueva y distinta. El resultado esperado son dos solicitudes y tres entregas repetidas resueltas sin crear solicitudes adicionales.

Después amplía la prueba más allá de esa secuencia sencilla:

• Entrega la misma notificación simultáneamente a dos procesos de trabajo.
• Interrumpe el proceso después de que actúe el destino, antes de registrar la finalización local.
• Envía dos solicitudes auténticas del mismo cliente; conserva ambas.
• Entrega una actualización retrasada y comprueba la regla de orden acordada.
• Elimina el identificador obligatorio; comprueba que la excepción sea visible.
• Verifica el remitente antes de actuar con el método documentado por el proveedor.
• Comprueba que una persona pueda investigar y reanudar con seguridad una operación incierta.

CARRAS ofrece automatización empresarial, integración de sistemas y desarrollo de software personalizado. Comparte las herramientas implicadas, un ejemplo sin datos sensibles del registro repetido y el resultado que espera tu equipo. El primer entregable útil es un plan acordado de identidad, reintentos y recuperación para ese flujo.

La compatibilidad depende de las API existentes, los permisos y el comportamiento del destino. Un piloto acotado debería demostrar las pruebas acordadas antes de ampliarse. Esta lista no afirma que una integración concreta de Carras ya las haya superado.