Does Trello's REST API enforce a hidden concurrent connection limit per API token that triggers HTTP 429 responses without exposing rate‑limit headers?

Question

When integrating with Trello’s REST API, developers rely on the documented rate‑limit headers (X‑RateLimit‑Limit, X‑RateLimit‑Remaining) to throttle calls and avoid HTTP 429 errors. However, many endpoints omit these headers, and intermittent 429 responses have been observed even when the reported remaining quota appears sufficient. This suggests that Trello may apply an internal, undocumented concurrent‑connection pool limit per API token that is not reflected in the public headers.
The goal is to determine whether such a hidden pool threshold exists, under what request patterns it is triggered, and whether it varies by account type or endpoint.

Does Trello enforce a hidden concurrent‑connection limit per token that causes 429 responses without updating rate‑limit headers?
Which request patterns (burst size, concurrency level, endpoint mix) reliably reveal this limit?
Does the limit differ between free, Business Class, and Enterprise accounts?

Tasadduq Burney · Answer

AnswerBased on Trello’s public documentation and observed behavior, there is no evidence of a hidden per‑token concurrent‑connection pool that triggers HTTP 429 without updating the standard rate‑limit headers. The 429 responses you see are most likely the result of the documented 300‑requests‑per‑10‑second limit (or an intermediary injecting its own throttling).Confirmed factsTrello’s API docs state a limit of 300 requests per 10 seconds per API token, returning HTTP 429 with a Retry‑After header when exceeded.The documentation does not mention any limit on simultaneous HTTP connections or concurrent requests per token.Likely explanationIf a client bursts requests faster than the 300/10 s window (e.g., using aggressive connection pooling or many parallel threads), the server treats the excess as abusive and returns 429 with the usual headers.In some cases, proxies, load balancers, or corporate firewalls can generate their own 429 responses and strip or omit Trello’s rate‑limit headers, giving the appearance of a hidden limit.Misconfigured client libraries that automatically retry on 5xx without back‑off can unintentionally increase the request rate, triggering the documented limit and producing 429 responses that may appear header‑less if the library discards them.Verification stepsCapture the full HTTP response headers (including X‑RateLimit‑*, Retry‑After, and any custom headers) for a series of requests made at varying concurrency levels (e.g., 1, 5, 10, 20 parallel calls).If a 429 appears, check whether any rate‑limit related headers are present. Presence confirms the documented limit; absence suggests an intermediary or client‑side issue.Repeat the test from a network environment with no proxy (e.g., a cloud VM) to isolate whether the headers are stripped downstream.Missing diagnostic detailTo determine whether the observed 429 responses are truly header‑less or merely missing due to client handling, please confirm: Do the 429 responses you receive contain any Retry‑After or X‑RateLimit‑* headers? This detail changes the recommendation because if headers are present, the issue is the documented rate limit; if they are absent even after a direct‑to‑Trello test, further investigation into intermediaries is needed.

Does Trello's REST API enforce a hidden concurrent connection limit per API token that triggers HTTP 429 responses without exposing rate‑limit headers?

1 answer

Answer

Confirmed facts

Likely explanation

Verification steps

Missing diagnostic detail

Your perspective belongs here.

1 question comment