Skip to main content
To keep the service stable and prevent abuse, FortAPI rate-limits requests. When triggered it returns HTTP 429 (Too Many Requests). Normal usage rarely hits this — rate limiting mainly catches runaway loops, scrapers, and attack traffic.

​
Kinds of rate limiting

  • Gateway / account-level limiting: caps request frequency per source; returns 429 when exceeded. This stops any single source from saturating the whole service.
  • Upstream provider limiting: upstreams (OpenAI / Anthropic, etc.) have their own rate limits. When hit, their 429 (or Anthropic’s 529 overload) is passed through verbatim by FortAPI, with type like rate_limit_error / overloaded_error, and per-channel automatic retry where possible.
Rate limits cap frequency (requests per unit time) — separate from your quota/balance. Insufficient balance returns 403, see Errors.

​
How to avoid / handle it

  1. Retry with exponential backoff: after a 429, wait and retry with progressively doubling intervals (1s, 2s, 4s…) plus a little jitter so clients don’t all retry at the same instant.
  2. Don’t busy-poll: cap concurrency on batch jobs and add intervals inside loops.
  3. Reuse connections / batch requests: combine work into a single request where the API supports batching.
  4. Multiple keys are not a bypass: limits key off the real source, so spinning up extra keys won’t multiply your throughput and may trigger abuse controls.

​
Need higher throughput?

If your workload genuinely needs high concurrency and you’re being throttled, email support@fortapi.com with your use case and we’ll review. Your overall request ceiling is governed by your account / token quota (see Billing & quota); frequency limits are just a protective guardrail.