Skip to main content
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: After the final retry fails, the delivery is dead-lettered: Qint stops retrying that event to that endpoint. The delivery (with its error) stays visible in the dashboard log.
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:
  1. Verify the signature.
  2. Record X-Qint-Event-Id (dedupe).
  3. Return 200.
  4. 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: Use Send test event after any change to your receiver — it’s the fastest way to confirm the full path (TLS, routing, signature check, 2xx) still works.
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.