Connector Rate Limits
StackJack paces the traffic it sends to each vendor's API so your PSA, RMM, or documentation platform never sees an abusive burst from your AI assistants. This page explains how that pacing works, what the per-connector ceilings are, and what throttling looks like when it happens.
Two different things: allowances vs. rate limits
Don't confuse these — they solve different problems:
| Monthly call allowance | Connector rate limit | |
|---|---|---|
| Purpose | StackJack's plan metering (the paywall) | Protecting the vendor's API quota |
| Scope | Successful calls per connector per billing cycle | Requests per minute (or 5 minutes) per connector |
| When exceeded | Tool calls return a monthly_limit_exceeded error |
Calls are paced, not refused — they just take a little longer |
StackJack itself imposes no per-minute or burst limit on your MCP endpoint — your monthly plan allowance is the enforcement point. The ceilings below exist purely so the vendor APIs behind your connectors stay healthy.
How the pacing works
Each connector has a per-workspace sliding-window ceiling. When your AI generates requests faster than the ceiling:
- The request waits its turn — it is delayed until the window has room, then sent. Your AI sees a slower tool call, not an error.
- If the vendor's own API still returns HTTP 429 ("Too Many Requests"), StackJack backs off automatically, honoring the vendor's
Retry-Afterheader where one is sent. - If the vendor's 429 surfaces all the way to a tool call, your AI receives a structured error with
errorType: "rate_limited"andretryable: true, with guidance to wait a moment and try again. Sustainedrate_limitederrors are unusual because the ceilings below sit at or under the vendors' own limits.
Rate-limit pacing never consumes your monthly allowance — only completed, successful calls count.
Ceilings per connector
All ceilings are per workspace (tenant). Vendor-published limits are listed only where StackJack has verified them against the vendor's current public documentation; a dash means the vendor doesn't publish a figure or we haven't verified one — the StackJack ceiling applies regardless.
| Connector | StackJack ceiling | Vendor-published limit | Notes |
|---|---|---|---|
| HaloPSA | 300 / 5 min | Published, but Halo's own sources give differing figures | StackJack's ceiling sits safely inside every allowance Halo has published. |
| ConnectWise PSA (Manage) | 100 / min | — | |
| ConnectWise Automate | 60 / min | — | |
| ConnectWise Sell (CPQ) | 100 / min | None published | ConnectWise does not publish a rate limit for the Sell/CPQ API; StackJack applies a conservative ceiling. |
| Autotask | 500 / min | — | |
| NinjaOne | 100 / min | — | |
| CIPP | 100 / min | — | |
| Hudu | 300 / min | — | |
| IT Glue | 3,000 / 5 min | 3,000 / 5 min (429 beyond) | Exact match to IT Glue's published limit. |
| Datto RMM | 600 / min reads; 100 / min writes | — | Reads and writes are paced separately. |
| Syncro | 180 / min | 180 / min per source IP | Matches Syncro's published ceiling; because Syncro counts per source IP, occasional 429s are still possible and are auto-retried with backoff. |
| Kaseya Quote Manager | 60 / min | 60 / min, plus 20,000 / day | StackJack paces the per-minute limit only; KQM's daily cap is not tracked client-side, so an extremely heavy day can surface as rate_limited errors. |
| Telivy | 60 / min | — | |
| Addigy | 600 / min | 1,000 / 10 s, with a 24-hour lockout if exceeded | The deliberately conservative ceiling makes Addigy's lockout unreachable. |
| Huntress | 50 / min | — | |
| Pax8 | 1,000 / min | 1,000 successful calls / min (429 until the window resets) | Equal to Pax8's published limit. |
| Liongard | 2,000 / 5 min | 100 / min on the metrics-evaluation endpoint | The 2,000 / 5 min figure is StackJack's own ceiling, not a Liongard-published number. Liongard's published throttle applies only to metric evaluation; StackJack honors Retry-After and rate-reset headers on 429s there. |
| N-able N-central | 300 / min | — | |
| Action1 | 60 / min | — | |
| Cisco Meraki | 600 / min | 10 requests/sec per organization (≈ 600 / min), plus a shared 100 requests/sec per source IP | StackJack's per-workspace ceiling equals Meraki's per-organization limit; StackJack honors Retry-After on 429s. |
| Cisco Umbrella | 60 / min | Varies widely by API family (no single figure) | Umbrella publishes different limits per API family — from roughly 14 / min on some to 3,000 / min on others — so StackJack applies one conservative ceiling and backs off on 429s. |
| ESET PROTECT | 300 / min | — | ESET publishes no numeric quota; StackJack paces conservatively and honors 429 backoff. |
What throttling looks like in practice
- Mild bursts: nothing visible. A few calls take a second or two longer while they wait for window room.
- Heavy sustained load (for example, an automation walking thousands of records): tool calls slow down noticeably but keep succeeding. This is the system working as designed.
- Vendor-side 429s: if a vendor throttles StackJack anyway (shared-IP effects, a vendor-side daily cap, or another integration consuming the same vendor account's quota), the AI sees
rate_limited, which is retryable. The error's guidance tells the AI to pause and retry.
If a connector returns persistent rate_limited errors at low request volume, something other than StackJack is consuming that vendor account's quota — check for other integrations using the same API key, or contact the vendor about your account's limits.
Requesting more headroom
The ceilings above are global product settings, not per-workspace dials. If your workload genuinely needs more throughput on a connector, contact StackJack support — and note that for connectors where StackJack already matches the vendor's published limit (IT Glue, Syncro, Pax8), the vendor's limit is the hard ceiling.