Identifica la ventana que perdiste
Define dos momentos: el último evento que procesó tu aplicación y la hora en que tu endpoint volvió a responder. Si guardas elid de cada evento como recomienda la página de buenas prácticas, toma el primer momento de tus propios registros. Si no, usa el inicio y el final del incidente.
Una ventana más amplia que la caída es segura cuando tu handler es idempotente, porque un evento que ya procesaste no genera trabajo adicional.
Lista los eventos de esa ventana
Llama a Listar eventos con la ventana ensince y until. Ambos aceptan una fecha como 2026-01-15 o un datetime ISO 8601 como 2026-01-15T09:00:00Z. Tu API key define el modo: una key de test devuelve eventos de test y una de live devuelve eventos de live.
Server
Response
data el mismo payload que Fintoc envió a tu endpoint, así que tu handler lo acepta sin cambios.
Acota más la ventana cuando sabes qué perdiste:
typefiltra la respuesta a un tipo de evento, comotransfer.outbound.succeeded.resource_idfiltra la respuesta a los eventos de un recurso, como una transferencia o un payment intent.
Pagina los resultados
limit devuelve hasta 300 eventos por página y por defecto son 30. Mientras queden eventos, la respuesta incluye un header Link con la URL de la página siguiente y rel="next". Sigue esa URL, o envía starting_after con el id del último evento que recibiste.
Server
Response
Link.
Reprocesa los eventos
Entrega cada evento al handler que ya procesa los webhooks en vivo. Reutilizar el handler mantiene los dos caminos de acuerdo sobre cómo un evento actualiza tu aplicación.Prueba la recuperación
Ejecuta la recuperación en modotest antes de depender de ella:
- Detén tu webhook endpoint y envía eventos de prueba desde el dashboard.
- Lista esos eventos con tu API key de
testy la ventana que acabas de crear. - Levanta tu endpoint de nuevo y ejecuta la recuperación sobre la respuesta.