Tumban delivers each webhook with up to three attempts. Behaviour by response:Documentation Index
Fetch the complete documentation index at: https://docs.tumban.com/llms.txt
Use this file to discover all available pages before exploring further.
| Response | Action |
|---|---|
2xx | Delivered. No further attempts. |
429 Too Many Requests | Retry. Tumban honours an integer-seconds Retry-After header (capped at 60 s). Without one, falls back to exponential backoff. |
Other 4xx | Not retried. Tumban gives up — fix your endpoint and replay manually if needed. |
5xx | Retry with exponential backoff. |
| Connection error or timeout | Retry with exponential backoff. The HTTP timeout per attempt is 30 s. |
Backoff
Exponential delays between retries:1s, 2s, capped at 30s. Tumban
sleeps before retries 2 and 3 only — there is no sleep after the
final attempt.
What gets delivered after the final retry
If all three attempts fail, the scan record is left withwebhook_delivered_at unset. The scan itself is not affected —
results remain available via
GET /api/v2/scans/{scan_id}.
Skipping delivery
If a scan is submitted with nocallback_url and the organization has
no default_callback_url set, Tumban runs
the scan to completion but sends no webhook. Read the result by
polling GET /api/v2/scans/{scan_id} instead.
Idempotency
Each delivery attempt sends the same body, including the samescan_id. Treat the scan_id as the idempotency key in your
handler — repeated deliveries for the same scan should be a no-op
once you’ve recorded the result.