Connector Rate Limits

StackJack paces the traffic it sends to each vendor's API, so a burst of AI activity is spread out instead of arriving at your PSA, RMM, or documentation platform all at once. This page explains how that pacing works, what StackJack's ceilings are, and what throttling looks like when it happens.

Pacing reduces the chance of hitting a vendor limit. It is not a guarantee. StackJack cannot control what else uses the same vendor account, how the vendor counts requests, or how the vendor reacts, so a call can still be rejected, throttled, or time out.

Two different things: allowances vs. rate limits

Don't confuse these — they solve different problems:

Keep these apart, because only the second one is what this page describes:

• StackJack imposes no per-minute or burst limit on your MCP endpoint. Your monthly plan allowance is StackJack's only volume enforcement point.
• The connector ceilings on this page are outbound pacing, applied per workspace per connector, so StackJack's own traffic to a vendor stays modest.
• The vendor's own limit is separate and outside StackJack's control. It may count differently (per source IP, per organization, per day) and it applies to every integration using that account, not only to StackJack.
• Concurrency and timeouts are not rate limits at all. How many calls a connector runs at once, and how long a single call may take before it is abandoned, are separate bounds. A slow vendor can produce a timeout at a request rate far below any ceiling here.

How the pacing works

Each connector has a per-workspace sliding-window ceiling. When your AI generates requests faster than that ceiling:

1. The request is delayed. StackJack calculates how long the window needs to clear and waits that long before sending. Your AI usually sees a slower tool call rather than an error. The delay is a best-effort smoothing step, not an exact quota: it is computed once, and the call is then sent.
2. If the call is abandoned while it is waiting, it does not complete. A cancelled request, a client that disconnects, or an outer timeout that expires during the wait ends the call with an error.
3. If StackJack's shared cache is unavailable, pacing is skipped rather than blocking your work. Calls go straight to the vendor unpaced for as long as that lasts, so a vendor-side 429 becomes more likely.
4. If the vendor still returns HTTP 429 ("Too Many Requests"), StackJack backs off before its next request on that connector for your workspace, honoring the vendor's Retry-After header where one is sent.
5. If a 429 reaches the tool call, your AI receives a structured error with errorType: "rate_limited" and retryable: true, and guidance to wait and try again.

Pacing delays do not consume your monthly allowance. Only completed, successful calls count against it.

Retries are not automatic for writes. StackJack automatically re-sends only requests that are safe to replay — reads. A create, update, or delete that fails is surfaced to your AI rather than re-sent, because re-sending it could apply the change twice. If your AI needs to retry a write, it should check whether the first attempt landed first. See Retrying a failed or timed-out write.

Ceilings per connector

Read the scope of this table before you use it. It covers the connectors customers ask about most. It is not the complete list: StackJack paces far more connectors than appear here, and a connector missing from this table is paced too. Every connector's own guide under How connectors work is the place to look for a connector that is not listed.

Units and scope for every row:

• StackJack ceiling is a rolling window, per workspace, per connector, applied to StackJack's outbound requests to that vendor. 300 / 5 min means 300 requests in any rolling five-minute window, not 300 per calendar period.
• Everyone in your workspace shares one ceiling per connector. A busy automation and a person's chat session draw on the same budget.
• Vendor-published limit is listed only where StackJack has checked it against the vendor's current public documentation. A dash means the vendor publishes no figure, or StackJack has not verified one. The StackJack ceiling applies either way.
• Vendor-published figures are dated observations. Vendors change them without telling integrators, so treat the vendor column as a pointer to the vendor's documentation rather than as a current guarantee.

What throttling looks like in practice

• Mild bursts: usually 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. Most still succeed. Some can time out, because the total time a single tool call is allowed to take is bounded and a long pacing delay eats into it.
• Vendor-side 429s: a vendor can throttle StackJack anyway — shared-IP effects, a vendor-side daily cap, a per-endpoint limit, or another integration consuming the same vendor account's quota. The AI then sees rate_limited, which is retryable, and the error's guidance tells it to pause and retry.

If you see persistent rate_limited errors at low request volume, work through these in order:

1. Check whether another integration uses the same vendor API key or account. Vendor limits are usually per account or per source IP, not per integration.
2. Check whether the vendor applies a daily or per-endpoint cap that this page's per-minute ceiling does not track.
3. Check whether your own workload is concentrated on one heavily limited endpoint rather than spread across the connector.
4. Ask the vendor what limits apply to your account, and contact StackJack support with the error and its correlation ID.

Do not assume the cause is another integration. It is one common cause, not the only one.

Reduce the pressure rather than retrying harder. Narrow reads with filters and date ranges instead of pulling whole tables, honor the wait the error asks for instead of retrying immediately, and confirm whether a write actually landed before sending it again — see Retrying a failed or timed-out write.

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.