A delivery succeeds when your endpoint answers any 2xx within the request timeout. Everything else — non-2xx status, connection failure, timeout — schedules a retry.
The retry schedule
Failed deliveries are retried with increasing backoff after the initial attempt:
| Attempt | Delay after previous failure |
|---|
| 1st retry | 30 seconds |
| 2nd retry | 2 minutes |
| 3rd retry | 10 minutes |
| 4th retry | 30 minutes |
| 5th retry | 2 hours |
A dead-lettered event is not re-sent automatically. If an endpoint was down
long enough to dead-letter events, reconcile by fetching current state —
GET /api/v1/intents/{id} (or list intents
filtered by status) — rather than waiting for webhooks that won’t come. Answer fast, work later
Retries make slow handlers expensive: a handler that takes longer than the delivery timeout gets retried even though it “worked”, and your processing runs twice. The robust pattern:
- Verify the signature.
- Record
X-Qint-Event-Id (dedupe).
- Return
200.
- Process the event from a queue/worker.
Because retries redeliver the same event with the same X-Qint-Event-Id, idempotent processing plus event-id dedupe makes the whole pipeline safe under every failure mode.
The delivery log
Each endpoint’s page in the dashboard (Developers → Webhooks) shows its recent deliveries — the last 50 — with:
| Column | Meaning |
|---|
| Event type | payment.status or ping. |
| Attempts | How many delivery attempts have been made. |
| Delivered at | Set once your endpoint answered 2xx. |
| Dead-lettered | Whether Qint gave up on this delivery. |
| Last error | The most recent failure (HTTP status or connection error). |
| Next attempt | When the next retry is scheduled, if any. |
Ordering is not guaranteed — an old retry can arrive after a newer event.
Never assume the latest webhook you received reflects the latest state;
reconcile order-sensitive logic via the API.
