FRED · Rate Limits

Fred Rate Limits

FRED enforces a single, published per-key rate limit: 120 requests per minute. The limit applies equally to the FRED API and the GeoFRED Maps API (the same api_key is used by both). There are no separate live / sandbox modes, no concurrency caps, and no per-IP throttle published. Consumers that exceed the limit receive a temporary rejection; FRED recommends staying well inside the cap by batching requests, caching responses, and backing off on errors. Heavy users (warehouse syncs, mirror builds) are encouraged to download the bulk data files published on the FRED website rather than scraping the API.

Fred Rate Limits is the machine-readable rate-limit profile for FRED on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests_per_minute, concurrent_requests, and varies.

The profile also includes 5 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Rate Limiting, Finance, Government, and Economic Data.

3 Limits Throttle: 429
Rate LimitingFinanceGovernmentEconomic Data

Limits

Requests per minute per API key key
requests_per_minute · minute
120
Published cap that applies to every endpoint of the FRED API and the GeoFRED Maps API. There is no separately documented per-second burst ceiling — pace requests evenly across the minute and you will not be throttled.
Concurrent requests per API key key
concurrent_requests
not published — keep concurrency modest (5–10) to stay within the per-minute cap
FRED does not document a hard concurrency ceiling. With a 120 req/min cap, ~10 concurrent requests with average sub-second latency keeps you compliant.
Bulk download alternative account
varies
use the bulk data files at https://fred.stlouisfed.org/categories/32263
When you need more than a few thousand series, fetch the bulk data downloads (CSV / zipped) instead of paginating through the API. The bulk files are not rate-limited.

Policies

Single shared key across APIs
The same 32-character api_key authenticates both the FRED API and the GeoFRED Maps API. Limits apply to the combined call volume.
Cache responses
Series metadata changes rarely. Cache series, release, source, and tag responses aggressively. Observation data updates on the release schedule — cache until the next scheduled release date.
Exponential backoff on throttling
On HTTP 429 (or 503 for transient failures) wait, jitter, and retry. Don't retry tight loops — that's how a working integration becomes a blocked one.
Prefer bulk downloads for warehouse syncs
Mirror builds, data warehouse loads, and academic dataset construction should pull the bulk CSV files rather than the API. The bulk files cover all series and are designed for high-volume retrieval.
ALFRED vs FRED
Real-time / vintage queries (realtime_start, realtime_end, vintage_dates) count against the same per-minute cap. Vintage queries can be expensive server-side — batch them and cache results.

Sources