Find the window you missed
Establish two moments: the last event your application processed, and the time your endpoint started responding again. If you store each eventid as the best practices page recommends, read the first moment from your own records. Otherwise use the start and the end of the incident.
A window wider than the outage is safe when your handler is idempotent, because an event you already processed causes no further work.
List the events in that window
Call List events with the window assince and until. Both accept a calendar date such as 2026-01-15 or an ISO 8601 datetime such as 2026-01-15T09:00:00Z. Your API key decides the mode: a test key returns test events and a live key returns live events.
Server
Response
data the same payload Fintoc posted to your endpoint, so your handler needs no changes to accept it.
Narrow the window further when you know what you lost:
typefilters the response to one event type, such astransfer.outbound.succeeded.resource_idfilters the response to events about one resource, such as a transfer or a payment intent.
Page through the results
limit returns up to 300 events per page and defaults to 30. While more events remain, the response carries a Link header with the URL of the next page and rel="next". Follow that URL, or send starting_after with the id of the last event you received.
Server
Response
Link header.
Reprocess the events
Pass each event to the handler that already processes live webhooks. Reusing the handler keeps both paths in agreement about how an event updates your application.Test the recovery
Run the recovery intest mode before you depend on it:
- Stop your webhook endpoint and send test events from the dashboard.
- List those events with your
testAPI key and the window you just created. - Start your endpoint again and run the recovery over the response.