Sign inSign up free
Omnichannel inbox Visual job flows Characters Any model + fallbacks CRM actions & booking Knowledge bases Approvals & autonomy Test & Debug A/B testing Analytics Website chat widget Quote desk Custom tools MCP server Rate limits & queue AI appointment setter All features Pricing FAQSign up freeSign in
Rate limits & queue

Built to stay up when your volume, and your providers, get busy

ReplySetter paces every provider call per inbox under the documented limit, backs off precisely when throttled, and runs jobs on a Postgres queue that scales across worker replicas. When something does fail, the Queue page tells you what, why and lets you retry.

Try it free How it works
Jobs flow from a Postgres queue to worker replicas; each inbox's API calls are paced under its limit, and a throttled inbox backs off and resumesQueuesync_accountGHL · Bright Smilerun_agentMaya · SMSsync_accountGmail · sales@run_agentDana · Emailsend_replyapproved · LeoFOR UPDATE SKIP LOCKEDsafe across every replicaworkerreplica 1workerreplica 2workerreplica 3GHL · Bright Smilepaced at 80 / 10 sprovider limitGmail · sales@paced at 70 units / sprovider limitOutlook · support@paced at 10 / s · 4 at onceprovider limit429 · Retry-After 8 sbacking offresumed · no attempt used
80/10 sGoHighLevel pacing (limit 100)
64 smaximum backoff step
Nworker replicas sharing one queue
0attempts wasted on rate limits
Deep dive

A closer look at Rate limits & queue

01 · Pacing

Under every provider's limit, per inbox

GoHighLevel is paced at 80 requests per 10 seconds and spreads the rest of its daily quota when under 10% remains. Gmail is paced at 70 quota units per second, Outlook at 10 requests per second with four at a time. State is shared by the API and every worker.

  • GoHighLevel: 80 / 10 s, daily quota spreading
  • Gmail: 70 units / s against 6,000 / min
  • Outlook: 10 / s, four concurrent
  • Shared pacing state across all processes
Each provider's documented rate limit next to the pace ReplySetter keeps under itGoHighLevellimit: 100 req / 10 s per location80 / 10 sGmaillimit: 6,000 units / min per user70 units / sOutlook (Graph)limit: 10,000 req / 10 min, 4 concurrent10 / s, 4 at onceInstantlylimit: 20 list calls / min per workspace1 list call per syncGHL daily quota spreadingUnder 10% of 200,000 left? The rest of the day's calls are spread out evenly
02 · Backoff

Throttled? Wait exactly as long as needed

A 429, a Gmail rateLimitExceeded or a 503 with Retry-After blocks that inbox until Retry-After, GoHighLevel's rate-limit window or an exponential backoff up to 64 seconds. Short waits retry in place; long waits defer the job without using an attempt.

  • Honours Retry-After and X-RateLimit headers
  • Exponential backoff up to 64 s
  • Deferred jobs keep their attempts
  • Failing inboxes retried after 1, 2, 4 … 60 minutes
After a throttle the inbox waits for Retry-After or backs off exponentially from 1 to 64 seconds, then resumesHTTP/1.1 429 Too Many RequestsRetry-After: 8 · X-RateLimit-Remaining: 0NO RETRY-AFTER? EXPONENTIAL BACKOFF1s2s4s8s16s32s64sshort waits retried in placelong waits deferred, attempt keptInboxes with failing credentials retry after 1, 2, 4 … 60 minutes; new credentials reset it.
03 · Queue

A Queue page that explains itself

See each inbox's sync health, API calls, throttles and GoHighLevel quota headers, plus failed, retrying, waiting and running jobs. Identical failures are grouped, so a single expired token shows up as one problem, not five hundred.

  • Sync health per inbox
  • API calls, throttles and quota headers
  • Grouped identical failures
  • Retry or clear in one click
The Queue page shows inbox sync health and groups 512 identical failures into one row that can be retried in one clickQueueSYNC HEALTHGHL · Bright Smilehealthy · 2,140 calls todayGmail · sales@throttled 1× · resumedOutlook · support@token expiredFAILED JOBS · GROUPEDsync_account · 401 invalid_grantOutlook · support@ · last 3 hours512 identicalrun_agent · model timeout3 retryingRetryre-queued after reconnecting the inbox
Under the hood

The details

Postgres queue

FOR UPDATE SKIP LOCKED jobs, safe across replicas.

Worker concurrency

Parallel jobs per worker, with syncs capped at half.

Horizontal scale

Add worker replicas; they share the queue safely.

Encryption

OAuth tokens and API keys encrypted with AES-256-GCM.

Migrations

Plain SQL migrations run automatically on start.

Self-hostable

Runs with Docker Compose: web, api, worker and Postgres.

Use cases

Who it's for

High-volume agencies

Hundreds of GHL sub-accounts without tripping rate limits.

Campaign spikes

Cold-email reply surges queued and answered in order.

On-call

One grouped error, one click to retry once it's fixed.

FAQ

Rate limits & queue: common questions

What happens when a provider rate-limits us?

That inbox pauses for exactly the window the provider asks for; other inboxes carry on.

Do rate limits burn retry attempts?

No. Long waits defer the job without using an attempt.

How do I scale up?

Increase worker concurrency or add worker replicas; they share the queue safely.

Is my data encrypted?

OAuth tokens and API keys are encrypted at rest with AES-256-GCM.

Keep exploring

Works hand in hand with

Channels

Omnichannel inbox

Gmail, Outlook, SMS, WhatsApp, Instagram, cold-email tools and web chat, answered by one agent.

Explore Build

Any model + fallbacks

Anthropic, OpenAI or 350+ OpenRouter models, with five cross-provider backups and cost tracking.

Explore Developers

MCP server

Drive the whole app from Claude Code, Cursor or any MCP client with a personal API token.

Explore
Get started

Put it to work on your own inbox

Connect an inbox, describe the job, test it in a sandbox and go live with exactly the autonomy you're comfortable with.

Sign up free See pricing