Rate Limits

This page describes the API rate limits, how to stay within them, and the recommended patterns for handling throttling gracefully in production integrations.

---

The limit

Requests are counted across your account. When the limit is exceeded, the API returns an HTTP 429 Too Many Requests response and additional requests are rejected until the window resets, so a well-behaved client should pace and batch its calls rather than relying on retries to push work through.

---

Staying within the limit

Batch requests when possible

The most effective way to reduce call volume is to request more per call. Wherever an endpoint accepts multiple identifiers (companies, series, periods) in a single request, prefer one batched call over many small ones.

• Fetch multiple series or fundamentals in a single request instead of looping one identifier at a time.
• Request a full range of periods at once rather than issuing one call per period.
• Consolidate lookups that you would otherwise fan out across many requests.

A single batched call that returns 50 results counts as one request against your budget; the equivalent 50 individual calls consume nearly half your per-minute allowance.

Cache aggressively

Many requests are avoidable entirely. See the Caching Strategy page for what to cache and for how long — caching company and series structure removes a large share of repetitive lookups before they ever hit the rate limit.

Pace your throughput

Spread requests evenly across the minute rather than firing them in a burst. A steady rate of roughly two requests per second stays comfortably under the ceiling, whereas a tight loop can exhaust the budget in seconds and stall the rest of the job.

---

Handling throttling

Even a well-paced client should be prepared to be throttled. Build the following into any production integration:

1. Detect throttling. Treat an HTTP 429 Too Many Requests response as an expected, recoverable condition — not a fatal error.
2. Back off exponentially. On rejection, wait before retrying and increase the wait on each successive failure (for example, 1s, 2s, 4s, 8s), capping at a sensible maximum.
3. Add jitter. Randomize the backoff slightly so that multiple workers do not retry in lockstep and re-trigger the limit simultaneously.
4. Respect any retry guidance. If the API indicates how long to wait before retrying, honor that value rather than guessing.
5. Cap retries. After a bounded number of attempts, surface the failure to your job's error handling rather than retrying indefinitely.

---

Recommended client checklist

• Requests are batched wherever the endpoint supports it.
• Cacheable data is served from cache, not re-fetched (see Caching Strategy).
• Outbound request rate is paced below the per-minute ceiling.
• Throttling is handled with exponential backoff and jitter.
• Retries are bounded and failures are logged.
• Concurrency across workers is coordinated so the shared limit is respected.