Production activation is performed per Company, App, and environment. Confirm a successful test delivery before enabling business side effects in your receiver.
Responses and retry times
Return200 OK or 204 No Content after durable acceptance. FloKit treats any 2xx as success. Do not redirect. FloKit uses a 10-second request timeout. Each scheduled attempt below is measured from the preceding failed attempt, so a slow first attempt does not compress the later ones. The overall 2-hour deadline is still measured from when the delivery is first queued. These are earliest scheduled times, not guaranteed arrival times:
Network errors, timeouts,
408, 425, 429, and 5xx responses retry. Redirects and other 4xx responses are permanent failures. Invalid destinations, missing signing material, or invalid frozen payloads stop delivery and require investigation. The delivery deadline is two hours after it was first queued; no automatic partner attempt starts at or after that deadline.
These are five scheduled attempts. At-least-once infrastructure can rarely repeat a physical send around a process crash. A receiver that committed but timed out may therefore see the same event again. Always deduplicate by event_id, including after apparent success.
Delivery history and dead state
In Admin, open Webhooks → Deliveries and select the delivery. Inspect its status, Payment and Subscription references, endpoint revision, attempt timeline, last response code, next retry, and dead reason. The signature and secret are never part of the displayed headers. A delivery becomes dead on a permanent failure, exhaustion of all attempts, an invalid destination or payload, missing signing material, or deadline expiry. Payload inspection is privileged because it may contain sensitive answers and an email address. Avoid copying that content into support tickets or logs. Changing an endpoint URL creates a new revision. Automatic retries remain pinned to the original revision. Pausing an endpoint stops new delivery creation and cancels work that has not begun sending. An HTTP request already sent cannot be recalled.Manual replay
After correcting the receiver or endpoint, select Retry for a dead delivery and provide a reason. Replay keeps the same frozen body, hash, andevent_id, uses the current active endpoint revision and valid signing secrets, and starts a new attempt generation. Old-generation tasks are ignored. Your receiver may already have stored the event, so deduplication still applies.
Troubleshooting
For implementation examples, see signature verification and the durable receiver transaction.