CONCURRENT_LIMIT

Too many in-flight requests for your tier — backoff for ~1 second and retry.

What this means

CONCURRENT_LIMIT enforces per-tier in-flight caps to keep p99 latency predictable: Free 2 / Starter 5 / Growth 20 / Scale 50 / Enterprise 100 concurrent requests. The cap is per-API-key, with a 30-second safety TTL that auto-releases slots if a request hangs. Unlike RATE_LIMITED, this is transient — slots free up within seconds.

When you'll see it

HTTP 429. Body always includes code: "CONCURRENT_LIMIT". Branch on code, never on the human-readable message — wording can change without notice; the code is the stable contract.

Example response

{
  "status": "error",
  "code": "CONCURRENT_LIMIT",
  "message": "Too many in-flight requests for tier",
  "retry_after": 1
}

How to handle

Back off and retry. The response includes `retry_after: 1` (seconds) as guidance. For automated systems, use exponential backoff with jitter — `sleep(retry_after * 1000 + random(0, 500))` works well. If you're hitting CONCURRENT_LIMIT consistently, you've outgrown your tier; upgrade for more concurrent slots, or batch your requests with a queue.

Suggested handling in a Node client:

if (data.code === 'CONCURRENT_LIMIT') {
  // Slot is full; retry after the suggested delay (typically 1s).
  await sleep((data.retry_after ?? 1) * 1000);
  return retry();
}

Related errors

See the full error index for the complete catalog with the handling switch statement covering every code at once.