> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flokitai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Delivery, retries, and troubleshooting

> Understand attempts, permanent failures, endpoint revisions, and manual replay.

<Note>
  Production activation is performed per Company, App, and environment. Confirm a successful test delivery before enabling business side effects in your receiver.
</Note>

## Responses and retry times

Return `200 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:

| Attempt | Offset in seconds | Time        |
| ------- | ----------------- | ----------- |
| 1       | 0                 | Immediately |
| 2       | 60                | 1 minute    |
| 3       | 300               | 5 minutes   |
| 4       | 900               | 15 minutes  |
| 5       | 3600              | 1 hour      |

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, and `event_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

| Symptom                           | Check                                                                                                                              |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Signature mismatch                | Verify exact raw bytes; parsing and reserializing changes the signed message. Check the selected Company's complete secret string. |
| Timestamp rejected                | Synchronize the receiver clock; the default tolerance is five minutes in either direction.                                         |
| Failure after rotation            | Install the new Company secret in every receiver before the 24-hour overlap expires. Accept any valid `v1` signature.              |
| Redirect response                 | Configure the final HTTPS URL directly. FloKit follows zero redirects.                                                             |
| TLS or DNS failure                | Check public DNS, certificate validity, certificate hostname, and reachability.                                                    |
| Private endpoint rejected         | Use a public HTTPS receiver. Private, loopback, link-local, metadata, multicast, and reserved addresses are not permitted.         |
| Repeated event                    | Check the durable unique constraint on `event_id`. Duplicate receipt must not create another business job.                         |
| Accepted but not processed        | Inspect your durable job store. A `2xx` acknowledges acceptance; it does not prove your background business work completed.        |
| Delivery marked dead              | Fix the recorded cause, then replay from Admin. Automatic retries do not continue after the deadline.                              |
| Waiting for questionnaire context | Inspect the checkout finalization and snapshot status; partial answers are never sent.                                             |

For implementation examples, see [signature verification](/webhooks/signatures) and the [durable receiver transaction](/webhooks/setup#accept-durably).