Retries & Failures
Redelivery policy, receiver-side idempotency, and manual retry of failed events.
If your endpoint does not respond 2xx within 10 seconds, or responds with a 5xx (or 408/429),
Wajub considers the delivery failed and retries automatically, up to 5 attempts total.
Redelivery policy
| Attempt | Delay after previous failure |
|---|---|
| 1 | immediate |
| 2 | 30 seconds |
| 3 | 1 minute |
| 4 | 5 minutes |
| 5 | 10 minutes |
After the 5th attempt still fails, the delivery is marked failed — it is not retried further, and the endpoint itself is not automatically disabled.
4xx responses are not retried
A 4xx response other than 408 (timeout) or 429 (rate-limited) is treated as a permanent
rejection: the delivery is marked failed immediately, with no further retries. Only 5xx,
network errors, 408, and 429 trigger the backoff schedule above.
Make your receiver idempotent
Since the same event may be delivered multiple times, deduplicate on event.id.
app.post('/webhooks/wajub', async (req, res) => {
const event = wajub.webhooks.constructEvent(req.body, sig, secret);
res.sendStatus(200); // acknowledge first
if (await seen(event.id)) return; // already processed → ignore
await markSeen(event.id);
await process(event);
});200 = 'received', not 'processed'
Respond 200 upon receipt and process in the background. If processing can fail,
handle it via your own job queue — do not rely on Wajub retries to replay
your business logic.
Retry failed deliveries
Each attempt is viewable in Konsole → Webhooks: you can see the response code, returned body, and latency, and can retry — resending the exact original payload with a freshly-signed header — once your endpoint is fixed. Also available: Retry bulk, to resend up to 100 failed deliveries in one action.
/webhooks/wajub50010021msattempt 1/webhooks/wajub500240msattempt 2/webhooks/wajub200142msattempt 3