Webhook delivery
How Workwae retries failed deliveries, and how to inspect the delivery log, replay events and send test events.
Workwae retries a failed webhook delivery for up to 3 days and disables an endpoint that keeps failing. Use the delivery log to see what happened, replays to resend events, and test events to check a receiver.
Retries and auto-disable
An attempt fails when your endpoint does not answer 2xx within 10 seconds: an error status, a 3xx, a timeout or a refused connection.
| Situation | What Workwae does |
|---|---|
| Failed attempt | Retries after 5 seconds, then doubles the delay each time, up to one hour between attempts, with 20 percent jitter. |
429, or 503 with Retry-After | Treats it as a request to slow down, not a failure. Retries after Retry-After (seconds or an HTTP date, clamped to 5 seconds to one hour), or without the header after 30 seconds, doubling each time the same delivery is throttled again, up to an hour. |
| Workwae cannot reach the internet or its DNS | The outage is Workwae's: retries after 30 seconds. |
| A delivery to the endpoint succeeds again | Other deliveries waiting for a retry are sent right away, at the usual concurrency. Deliveries waiting on a Retry-After you sent keep waiting. |
| The next attempt would fall more than 3 days after the delivery was queued | The delivery is given up and marked failed. |
| 72 hours of failures without a single success | The endpoint is disabled: isEnabled becomes false and disabledReason says why. |
- Throttled attempts and Workwae-side outages do not count as attempts or toward the 72 hours; the 3-day limit still applies. A throttled delivery does not hold back other deliveries to your endpoint.
- Outage attempts still appear in the delivery log.
failingSinceandlastSuccessAton the endpoint show its health before it is disabled.
Recover a disabled endpoint
A disabled endpoint receives no new events, and its queued deliveries wait. Deliveries still queued 3 days after they were created are given up and marked failed. Failed deliveries are deleted after 30 days.
PATCH /v1/webhooks/{endpointId} and { "isEnabled": true }, or in the console.Delivery log
Every attempt is logged with its HTTP status, latency, error and the first kilobyte of your response. The log keeps the last 500 attempts per endpoint, for up to 7 days. The endpoint's console page shows new attempts (a retry, a delivery, the final failure) without a reload.
curl "https://api.workwae.com/v1/webhooks/$ENDPOINT_ID/attempts?result=failed&eventType=message.created" \
-H "Authorization: Bearer $WORKWAE_API_KEY"| Parameter | Filters by |
|---|---|
eventType, eventId, accountId | The event. |
result | succeeded or failed. |
since, until | Attempt time range. |
limit | Page size, up to 500 (default 50). |
cursor | The previous page's nextCursor, to continue with older attempts. |
Results are newest first. Each attempt says whether it came from a replay (isReplay) or a test (isTest).
Replay events
A replay queues events again for one endpoint, with the same id and body as the first delivery and a fresh signature. All replay requests answer 202; the attempts show up in the delivery log.
| Replay | Request | Filters applied |
|---|---|---|
| One event | POST /v1/webhooks/{endpointId}/events/{eventId}/replay | None. |
Time range [since, until) | POST /v1/webhooks/{endpointId}/replay | The endpoint's current filters. |
| Failed deliveries (retries ran out, or the endpoint was disabled) | POST /v1/webhooks/{endpointId}/replay-failed, optionally with since/until on event creation | Not applicable. |
curl -X POST "https://api.workwae.com/v1/webhooks/$ENDPOINT_ID/replay" \
-H "Authorization: Bearer $WORKWAE_API_KEY" \
-H "content-type: application/json" \
-d '{ "since": "2026-05-04T00:00:00Z", "until": "2026-05-05T00:00:00Z" }'GET /v1/webhooks/{endpointId}/failed-deliveries/countreturns how many events a replay of failed deliveries would queue. The console's Replay failed shows it before you confirm.- A replay of failed deliveries replaces them: calling it again does not send the same events twice.
- Events already queued for the endpoint are not queued twice; the response counts them in
alreadyQueued.
| Error | Cause |
|---|---|
400 replay_range_too_large | A range or failed-deliveries replay covers more than 1000 events. Split it. |
404 event_not_found | The event id is unknown or past the tenant's eventRetentionDays. |
409 endpoint_disabled | Enable the endpoint first. |
Replays reuse the event id
A replayed event carries an id you may already have processed. Deduplicating on webhook-id keeps a replay safe to run.
Test events
Send an event of any type to one endpoint, whatever its filters, to build and check a receiver before real traffic exists. The request answers 202 once the delivery is queued. The console's endpoint page has a Send test event action for the same thing.
curl -X POST "https://api.workwae.com/v1/webhooks/$ENDPOINT_ID/test" \
-H "Authorization: Bearer $WORKWAE_API_KEY" \
-H "content-type: application/json" \
-d '{ "eventType": "message.created" }'- Without
eventType, the test is awebhook.testevent. - The body carries the type's sample data from the event catalog, unless you pass
data, which must match that type's data (400 otherwise). - It is signed like any other delivery, and its body has
"isTest": true,webhook.testincluded. - Test events never appear in the change feed.
Webhook tester
The console's Webhook tester (admins and owners) gives you a URL on the API that records every request sent to it. Watch deliveries arrive without a receiver of your own.
The URL is the credential
Anyone with the inbox URL can send to it. Treat it as a secret, and delete the inbox to retire it.
| Limit | Value |
|---|---|
| Requests kept per inbox | Last 200, up to 2 MB, for 24 hours after the latest. |
| Body kept per request | First 16 KB. |
| Body size | Over 256 KB is refused with 413. |
| Request rate | Over 60000 requests a minute is refused with 429. |
| Storage per organization | 10 MB across inboxes; past it, requests are refused with 507 until you clear one. |
| Inboxes per organization | 10. Deleting one deletes its requests and its endpoint. |