Cómo recuperar eventos cuando una integración estuvo detenida

Delimita el hueco y las fuentes disponibles

Anota último trabajo confirmado, comienzo de la interrupción y momento de recuperación. Comprueba qué conserva el proveedor: eventos, historial de entregas o cursor de cambios. Stripe documenta mecanismos para gestionar eventos no entregados, pero cada servicio tiene ventanas y filtros propios. Verifica esas condiciones antes de depender de ellas. Si el periodo perdido supera lo recuperable, identifica qué consulta del estado actual permitirá reconciliar el resultado.

Distingue pendiente de no aplicado

Un evento puede fallar en la entrega después de que tu receptor haya persistido o ejecutado parte del trabajo. Compara con el registro local y el destino antes de reenviarlo. Prepara una recuperación que pueda coexistir con reintentos automáticos y nuevas entradas. Usa la misma protección de identidad y efectos en ambos caminos; una herramienta manual que omite esos controles puede duplicar lo que la ruta normal hacía correctamente.

Reanuda por tramos verificables

Separa lectura del histórico y ejecución, filtra los tipos pertinentes y limita concurrencia. Guarda avance solo cuando el tramo esté registrado de forma duradera. Para recursos compatibles, Microsoft Graph ofrece consulta delta; sus tokens pueden dejar de servir y exigir sincronización completa. Un cursor no es una copia del historial eterno. Define qué hacer si se invalida y cómo evitar que reconstruir el estado dispare acciones antiguas ya resueltas.

Decide qué reconstrucción no debe enviar avisos

Separar reconstrucción de estado y ejecución de efectos evita que una recuperación histórica mande comunicaciones fuera de contexto. Identifica acciones que todavía tienen utilidad y otras que ya caducaron, con autorización del responsable. Restaurar una ficha actual no obliga a emitir cada aviso intermedio que habrías enviado durante la caída.

Si el negocio necesita conservar esos hechos para auditoría operativa, regístralos como recuperados y mantén su fecha original diferenciada de la fecha de procesamiento. No cambies el histórico para aparentar que el sistema estuvo disponible. Antes de liberar la recuperación completa, ejecuta un tramo pequeño con operaciones ya conocidas y comprueba tanto el destino como los canales de salida. Una cola vacía con correos duplicados sería una recuperación incorrecta aunque todos los eventos figuren completados.

Cierra el hueco con una conciliación

Compara referencias esperadas, procesadas, revisadas y pendientes dentro de la ventana. Incluye cambios gestionados manualmente durante la caída. En un ejemplo hipotético, un operador pudo crear el pedido directamente y la recuperación deberá enlazarlo, no repetirlo. Prueba una interrupción con eventos ya aplicados, otros no recibidos y entregas nuevas simultáneas. El cierre requiere explicar cada diferencia y dejar los casos ambiguos asignados, aunque el receptor vuelva a responder correctamente. Guarda ese cierre junto al registro de la incidencia.

Fuentes y documentación

• Stripe: gestionar endpoints de webhook — Recuperación de eventos no entregados y coexistencia con entregas automáticas.
• Microsoft Graph: delta query — Paginación y tokens para recursos compatibles; contempla repeticiones y reinicio de sincronización.