Stream Results.
Reprice Faster.
Delivery Model · Streaming
Push, not Pull
Results Arrive the Moment They're Ready
Instead of polling kwery on a loop, your endpoint receives a signed POST as each batch completes. No interval guessing, no wasted requests, no waiting for an entire job to finish.
Built for high-volume monitoring where latency matters — 1,000+ products, real-time repricing, continuous market awareness.
End-to-end flow
Three Moving Parts. That's It.
From request to acknowledgment, the webhook lifecycle is intentionally small. No queues to manage on your side, no polling loops to babysit.
Submit a job
POST your request with a callback_url. kwery returns a job_id and a per-job webhook_secret you'll use to verify deliveries.
Receive batches
As results are ready, kwery pushes them to your endpoint as signed POSTs — partial batches stream in continuously, not at the end.
Acknowledge fast
Return 200 OK immediately and process asynchronously. Slow responses are treated as failures and trigger automatic retries.
Signed deliveries
Cryptographically Verifiable, Every Time
Every webhook is signed with HMAC-SHA256 using a per-job secret shared at initialization. Compare the signature to the X-Kwery-Signature header before processing — and reject anything that doesn't match.
Timestamps prevent replay attacks. Delivery IDs let you deduplicate cleanly. The headers do the heavy lifting.
See signing in the docsBuilt-in reliability
Outages Happen. You Don't Lose Data
Retries, dead-letter replay, and idempotency keys are first-class — not features you have to bolt on. A momentary blip on your side never means a lost result.
Automatic retries
Exponential backoff over an hour — Immediate, +30s, +2m, +10m, +30m — so a deploy or a brief outage never costs you data.
Dead-letter replay
After 5 failed attempts, deliveries move to a dead-letter state. Replay individual delivery IDs or an entire job on demand.
Per-delivery idempotency
Every payload carries a unique X-Kwery-Delivery-Id. Deduplicate safely without complex ordering logic on your side.
- 01Immediate
- 02+30s
- 03+2m
- 04+10m
- 05+30m
Event catalog
Subscribe to What Matters
Streaming events deliver partial and final results as jobs run. Change-detection events surface price shifts, offer count changes, and buy-box flips — but only when a scheduled re-pull finds a delta versus the previous snapshot.
Partial results from an in-flight job. Delivered as each source completes so you can render before the full job finishes.
Final batch for a job — completion signal with the last delta. Pair with batch_sequence to close out your local cache.
Price, offer count, or buy-box status shifted between snapshots. You get only what changed — no full-catalog noise.
Production checklist
Build a Receiver That's Fast, Safe, and Idempotent
Battle-tested patterns for handling kwery webhooks in production. Apply these six and you'll handle anything we throw at you.
Acknowledge instantly
Return 200 OK before any processing. Slow responses are treated as failed and retried.
Delivery
Deduplicate by delivery ID
Track X-Kwery-Delivery-Id for 7 days to handle at-least-once delivery cleanly.
Idempotency
Tolerate out-of-order
Use batch_sequence on stream events to keep your local cache consistent.
Ordering
Isolate exceptions
Reserve 4xx responses for permanent failures; queue transient errors for async retry.
Errors
Hand off to a queue
Push payloads to a background worker immediately after acknowledging.
Backpressure
Verify timestamps
Check X-Kwery-Timestamp to reject replays and confirm freshness on receipt.
Freshness
Support
Questions About Webhooks
Delivery semantics, signing, retries, and recovery. Full answers live in the knowledgebase.
Browse all FAQsWebhooks guarantee at-least-once delivery, so the same event may arrive more than once. Every event carries a signed payload and an idempotency key — deduplicate on that key before processing. Webhooks reference.
Any delivery can be replayed on demand from the dashboard or API. Combined with retries, no validated change is lost — you can backfill the window you missed without re-running jobs.
Every webhook payload is signed with HMAC-SHA256 using a shared secret bound to your endpoint. Verify the signature header before processing to confirm the payload came from kwery and was not tampered with.
Failed deliveries are retried with exponential backoff over several hours. After the final attempt, the event is held for manual replay rather than dropped.
Use whichever fits your workflow. Webhooks work best for large jobs (1,000+ products) where you want results as they complete — no polling loops, cleaner architecture. Polling is simpler for smaller jobs or when you prefer to pull on your schedule. Both use the same underlying API and pricing. Webhooks reference.
Start building with real-time data
Stop waiting for jobs to finish. Get only what changed — signed, retryable, and delivered the moment we detect it.