Responses and retry times
Return200 OK or 204 No Content after durable acceptance. Any 2xx is treated as success. Do not redirect. The request timeout is 10 seconds.
Each delay below is measured from the preceding failed attempt. These are earliest scheduled times, not guaranteed arrival times. The overall deadline is two hours after the delivery was first queued.
Network errors, timeouts,
408, 425, 429, and 5xx responses retry. Redirects and other 4xx responses are permanent failures. Automatic delivery also stops when attempts are exhausted or the deadline is reached. An invalid destination or payload needs investigation rather than repeated acceptance attempts.
These are five scheduled attempts, not a guarantee of exactly five physical requests. Always deduplicate by event_id, even after apparent success: the receiver may commit successfully while its response times out.
Delivery history and dead state
Open Webhooks → Deliveries in the dashboard to see each delivery’s status, attempt times, last response code, next retry, and failure reason. A dead delivery will not resume automatically. Share a safe delivery reference, not the customer payload or signing header. Changing an endpoint URL does not redirect existing automatic retries to the new address. Retries of existing deliveries keep the address they started with. Pausing an endpoint cannot recall an HTTP request that has already been sent.Manual replay
After fixing the receiver or destination, an owner or admin can select Retry on the failed delivery (or ask your FloKit contact). Replay retains the same body andevent_id and uses the current active destination and signing credentials. Your receiver must still deduplicate it because an earlier request may already have been accepted.
Troubleshooting
See signature verification and the durable receiver example.