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

# Webhook delivery and retries

> How Darwin delivers webhooks: answer 2xx within 10 seconds, handle duplicates and out-of-order events, the retry schedule over three days, switched-off endpoints, redelivery and catching up from the event log.

Darwin delivers each event at least once, retries for about three days and keeps every event for 30 days. This page covers what your receiver has to do and how to recover when it was down.

## Answer quickly

* Answer with any `2xx` status within **10 seconds**. Anything else counts as a failure: a `3xx` (Darwin does not follow redirects), a `4xx`, a `5xx`, a timeout or a refused connection.
* Answer first and do slow work (CRM calls, Slack posts) afterwards in a queue. A receiver that waits on another service is the most common cause of timeouts.
* Darwin reads at most the first 64 KB of your answer and keeps the first 500 characters in the delivery log. Don't return anything secret.

## Handle duplicates and order

* **At least once.** Darwin may deliver the same event more than once, for example when your server handled it but the answer was lost. `webhook-id` (the event `id`) is the same on every retry and redelivery. Record the ids you've processed and skip repeats.
* **No ordering.** Events can arrive out of order, especially after retries. A `meeting.rescheduled` can arrive before its `meeting.booked`. Use `created_at`, or the object's `updated_at`, to decide which is newer, or read the current object from the API.

## Retries

If a delivery fails, Darwin tries again after:

| Retry | Wait after the previous attempt |
| - | - |
| 1 | 1 minute |
| 2 | 5 minutes |
| 3 | 30 minutes |
| 4 | 2 hours |
| 5 | 6 hours |
| 6 | 12 hours |
| 7 | 24 hours |
| 8 | 24 hours |

That is nine attempts over about three days. After the last one the delivery is marked **Failed**. You can still send it again by hand for 30 days.

### Endpoints that keep failing are switched off

If an endpoint has failures and not one successful delivery for **three days**, and is still failing, Darwin switches it off and shows why under its address in **Integrations → API**: *Deliveries have failed for three days without one success. Fix the receiver, then switch the endpoint back on.* An endpoint that answers `410 Gone` is switched off at once: that is how a receiver (Zapier, for one) says the subscription is over. Its badge turns from **Failing** to **Off**, and `GET /webhook_endpoints/{id}` shows `"status": "disabled"` with a `disabled_reason`.

While an endpoint is off, Darwin does not queue new events for it. To recover:

1. Fix your receiver and check it with **Send test event**.
2. Open the endpoint's **⋯** menu and select **Switch on** (or `PATCH` it with `{"status": "enabled"}`). Deliveries that were still retrying continue.
3. Send the events you missed: use **Send again** in **Deliveries**, or read [`GET /events`](https://docs.meetdarwin.ai/api-reference/webhooks/delivery#catch-up-with-the-event-log) for the gap and redeliver them.

You can also select **Switch off** yourself, for example during maintenance. Events stay in the event log for 30 days.

## Check deliveries and send again

Open the endpoint's **⋯** menu and select **Deliveries**. Each row shows the event type, whether it was **Delivered**, is **Retrying** or **Failed**, the number of attempts, your server's last HTTP status or error, and the next try. **Send again** puts that delivery back in the queue; it goes out within a few seconds.

The endpoint row also summarises this week: how many were delivered, failed and are retrying.

With the API:

```bash theme={null}
# Failed deliveries for one endpoint
curl "https://api.meetdarwin.ai/v1/webhook_endpoints/we_7h3k9m2p4q8r1s5t/deliveries?status=failed" \
  -H "Authorization: Bearer $DARWIN_API_KEY"

# Send one event again to every enabled endpoint subscribed to its type...
curl -X POST https://api.meetdarwin.ai/v1/events/evt_2b8f0c1d6e4a9937/redeliver \
  -H "Authorization: Bearer $DARWIN_API_KEY"

# ...or to one endpoint
curl -X POST https://api.meetdarwin.ai/v1/events/evt_2b8f0c1d6e4a9937/redeliver \
  -H "Authorization: Bearer $DARWIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"endpoint": "we_7h3k9m2p4q8r1s5t"}'
```

The redeliver response says how many deliveries were `queued`. Only enabled endpoints subscribed to the event's type receive it.

## Catch up with the event log

Every event from the last 30 days is in `GET /events` (scope `events:read`), newest first. It is the pull twin of webhooks: use it after downtime, or instead of webhooks if you would rather poll.

```bash theme={null}
curl "https://api.meetdarwin.ai/v1/events?type=lead.captured,meeting.booked&created_since=2026-10-10T00:00:00Z&limit=100" \
  -H "Authorization: Bearer $DARWIN_API_KEY"
```

Each item is the same event body a webhook sends.

## Troubleshooting

> **Every delivery fails with a signature error on my side**
>
> Check that you verify the raw body, not parsed and re-serialised JSON, and that you base64-decode the secret after removing `whsec_`. Frameworks that parse JSON automatically need a raw-body route, like `express.raw` in [Verify signatures](https://docs.meetdarwin.ai/api-reference/webhooks/verify.md).

> **Redirects are not followed**
>
> Your URL answered with a `3xx`. Use the final address, including `https://` and the exact path, often with or without a trailing slash.

> **No answer within 10 seconds**
>
> Answer `200` before doing the work. Check that your server is reachable from the public internet and not behind a login or firewall.

> **I don't get events for my test chats**
>
> Preview chats in Darwin never send events. Use **Send test event**, or have someone use the chat on your live website.

[Send handoffs to Slack →](https://docs.meetdarwin.ai/guides/slack-handoffs.md) · [Sync leads to a CRM →](https://docs.meetdarwin.ai/guides/crm-sync.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.