Built for the work modern apps depend on.
Six common patterns SimpleQ replaces — with API calls you can copy today.
AI job processing
LLM calls are slow, fail intermittently, and hit token-per-minute rate limits at the worst moments. Doing them inline blocks user requests, kills timeouts, and silently drops work when a worker restarts.
Publish AI jobs to a queue with rate limiting. SimpleQ delivers each job to your webhook, handles 429/503/529 backpressure without burning retries, and gives you per-job logs with payloads, attempts, and latency. Use the built-in Anthropic queue template for preconfigured settings.
1# Publish an AI job — SimpleQ delivers it to your webhook2curl -X POST https://api.simpleq.io/v1/queues/ai-jobs/jobs \3 -H "Authorization: Bearer sq_live_abc123..." \4 -H "Content-Type: application/json" \5 -d '{6 "payload": {7 "model": "gpt-4o-mini",8 "messages": [{ "role": "user", "content": "Summarize this" }],9 "userId": "u_123"10 },11 "idempotencyKey": "summary_req_456"12 }'Webhook delivery
When you call a customer's webhook, it might be down, slow, or rate-limited. Without retries with backoff and a dead-letter queue, you lose events — and trust.
Create a queue pointed at your customer's webhook URL. Publish events as jobs with idempotency keys. SimpleQ handles delivery, retries with exponential backoff, HMAC signing, and dead-letter queuing. Replay failed deliveries from the dashboard.
1# Create a queue for customer webhook delivery2curl -X POST https://api.simpleq.io/v1/queues \3 -H "Authorization: Bearer sq_live_abc123..." \4 -d '{5 "name": "customer-webhooks",6 "webhookUrl": "https://customer.com/webhook",7 "maxAttempts": 8,8 "backoffType": "exponential",9 "backoffDelay": 2,10 "dlqEnabled": true11 }'12 13# Publish an event14curl -X POST https://api.simpleq.io/v1/queues/customer-webhooks/jobs \15 -H "Authorization: Bearer sq_live_abc123..." \16 -d '{17 "payload": { "event": "order.completed", "orderId": "ord_789" },18 "idempotencyKey": "evt_order_completed_789"19 }'Bulk API sync
Syncing thousands of records to Stripe, Salesforce, or a CRM means hammering rate limits, watching jobs die halfway, and writing custom resume logic every time.
Create a queue with rate limiting. Fan out each record as a job. SimpleQ paces delivery to your webhook (which calls the downstream API), retries failures, and tracks every attempt — no custom checkpointing required.
1# Create a rate-limited queue for Stripe sync2curl -X POST https://api.simpleq.io/v1/queues \3 -H "Authorization: Bearer sq_live_abc123..." \4 -d '{5 "name": "billing-sync",6 "webhookUrl": "https://your-app.com/stripe-sync-handler",7 "maxAttempts": 5,8 "rateLimitMax": 50,9 "rateLimitWindow": 60,10 "dlqEnabled": true11 }'12 13# Fan out — publish one job per customer14for id in customer_001 customer_002 customer_003; do15 curl -X POST https://api.simpleq.io/v1/queues/billing-sync/jobs \16 -H "Authorization: Bearer sq_live_abc123..." \17 -d "{\"payload\": {\"customerId\": \"$id\"}}"18doneDelayed jobs
You need to process a job later — send a follow-up email in 24 hours, retry a payment in 30 minutes, or trigger a reminder next week. Without delay support, you're stuck with cron hacks or external schedulers.
Publish a job with a delay in seconds. SimpleQ holds it in pending until the delay expires, then delivers it to your webhook. Full retry and DLQ support still applies.
1# Send a follow-up email in 24 hours2curl -X POST https://api.simpleq.io/v1/queues/reminders/jobs \3 -H "Authorization: Bearer sq_live_abc123..." \4 -H "Content-Type: application/json" \5 -d '{6 "payload": {7 "userId": "u_123",8 "action": "send-followup-email"9 },10 "delay": 8640011 }'12 13# Job stays "pending" for 24h, then SimpleQ POSTs to your webhookSMS and email workflows
Outbound messaging is easy to spam, easy to duplicate, and easy to land in spam folders when you ignore provider rate limits.
Create a rate-limited queue for outbound messages. Use idempotency keys to prevent duplicate sends across retries and worker restarts. Your webhook calls the provider (Twilio, SendGrid, etc.) — SimpleQ ensures it only fires once per key.
1# Create a rate-limited outbound queue2curl -X POST https://api.simpleq.io/v1/queues \3 -H "Authorization: Bearer sq_live_abc123..." \4 -d '{5 "name": "outbound-sms",6 "webhookUrl": "https://your-app.com/send-sms",7 "rateLimitMax": 10,8 "rateLimitWindow": 1,9 "maxAttempts": 3,10 "dlqEnabled": true11 }'12 13# Publish with idempotency key to prevent duplicate sends14curl -X POST https://api.simpleq.io/v1/queues/outbound-sms/jobs \15 -H "Authorization: Bearer sq_live_abc123..." \16 -d '{17 "payload": { "to": "+1555123456", "body": "Your order shipped!" },18 "idempotencyKey": "sms_u123_campaign_456"19 }'Ack-mode processing
For long-running work — video processing, large data imports, multi-step AI pipelines — a webhook 200 only means "received", not "done". Without explicit acknowledgment, you can't tell if work actually completed.
Use ack mode. Your webhook returns 200 to confirm receipt, then your app calls /ack when done, /nack to fail fast, or /defer to signal backpressure without burning a retry. If the ack doesn't arrive within the timeout, SimpleQ retries or sends to the DLQ.
1# Create an ack-mode queue2curl -X POST https://api.simpleq.io/v1/queues \3 -H "Authorization: Bearer sq_live_abc123..." \4 -d '{5 "name": "video-processing",6 "webhookUrl": "https://your-app.com/process-video",7 "mode": "ack",8 "ackTimeout": 300,9 "ackTimeoutAction": "retry",10 "maxAttempts": 311 }'12 13# Publish a job → webhook fires → returns 200 → status: "awaiting_ack"14# After processing completes, your app calls:15curl -X POST https://api.simpleq.io/v1/jobs/job_abc123/ack \16 -H "Authorization: Bearer sq_live_abc123..."17# → status: "completed"Ready to ship reliable async work?
Sign up free and have your first job running in under five minutes.