Skip to main content
By the end of this guide, your application can rebuild the state it lost while your webhook endpoint was missing events. Your endpoint misses events when your server is down, when your handler fails after Fintoc records the delivery, or when a deploy drops requests. Fintoc stores every event it generates for your organization, so you can fetch the window you lost and process it yourself.

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 event id 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 as since 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
Each event carries in 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:
  • type filters the response to one event type, such as transfer.outbound.succeeded.
  • resource_id filters 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
Events come back most recent first, so each page walks further back in time. The last page arrives without a 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.
Collect all pages before you process them, then reverse the full list. The API returns each page with the most recent event first, and pagination moves backward in time.

Test the recovery

Run the recovery in test mode before you depend on it:
  1. Stop your webhook endpoint and send test events from the dashboard.
  2. List those events with your test API key and the window you just created.
  3. Start your endpoint again and run the recovery over the response.
Your application ends in the same state as if it had received the events live.