How Queuey Works — Async Queue with Retries, DLQ & Replay | Queuey

How Queuey works: webhooks and events land in Queuey first. Queuey answers 202 once the event is stored in Postgres, then delivers it to your API at the pace you set — a rate limit per destination — and honours Retry-After.

When a delivery fails, what happens next depends on the answer: a 429 waits as long as Retry-After says, then the queue resumes on its own; a 502, 503 or 504 opens the circuit breaker and holds events while one probe at a time checks the receiver; a timeout holds the queue until you confirm once that the endpoint is idempotent, since the request may already have been processed; a 401 or 403 stops retries and marks the destination as requiring action; a 400 or 422 goes to the dead-letter queue, ready to replay once the cause is fixed.

Around it: HMAC verification at ingress (with a Stripe template), HMAC-signed deliveries, OAuth2 client credentials toward your API, FIFO or best-effort ordering (optionally per key), deduplication on the producer's Idempotency-Key header for 24 hours, single and bulk replay, evidence for every attempt and an audit trail.