Frankfurter · Rate Limits

Frankfurter Rate Limits

Frankfurter publishes no hard rate-limit numbers. The hosted api.frankfurter.dev endpoint enforces only soft, undocumented fair-use throttling to protect the shared instance from abuse — there are no monthly or daily caps, no per-key quotas (no keys exist), and no documented per-second / per-minute ceilings. The documentation states: "There are no quotas. Requests are rate-limited to prevent abuse, but there are no monthly or daily caps." For high-volume use, the project recommends caching, self-hosting via the lineofflight/frankfurter Docker image, or consuming the upstream data sources directly. A self-hosted deployment has no application-level limits — only what the operator's infrastructure enforces.

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

It captures 2 rate-limit definitions, measuring varies.

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

Tagged areas include Rate Limiting, Currency Exchange, Open Source, Free, and Self-Hosted.

2 Limits Throttle: 429
Rate LimitingCurrency ExchangeOpen SourceFreeSelf-Hosted

Limits

Public hosted endpoint — fair-use throttling IP
varies
soft / undocumented
The provider does not publish concrete per-second, per-minute, or per-hour numbers. The hosted instance applies abuse-prevention throttling at an unspecified threshold. There are no monthly or daily caps. No API key exists, so the limit cannot be scoped to a key.
Self-hosted instance account
varies
operator-defined (no application-level limit)
The Frankfurter codebase itself does not impose rate limits. A self-hosted deployment is bounded only by the operator's chosen infrastructure (reverse proxy, CDN, or application-layer middleware).

Policies

No authentication, no keys
Frankfurter requires no account and issues no API keys, so rate limits cannot be scoped per-customer. Anyone consuming the hosted endpoint at a sustained high rate should either cache aggressively, run their own instance, or fall back to the upstream central-bank feeds.
Cache aggressively
Rate data updates at most once per day per provider. Clients should cache responses for the rest of the day (and use HTTP cache headers returned by the API) rather than re-polling.
Self-host for high volume
The maintainers' explicit recommendation for high-volume consumers is to run a private instance via the public Docker image. This removes the shared-instance fair-use ceiling entirely.
Fall back to upstream
The dataset itself comes from public central-bank feeds (ECB, FED, BOC, TCMB, BOJ, BCB, BOT, BAM, and others). Bulk consumers can pull directly from those sources at no cost.
Backoff on 429
Clients receiving HTTP 429 should back off exponentially. No Retry-After header is documented, so a conservative exponential schedule (1s, 2s, 4s, 8s ...) is appropriate.

Sources

Work with this as data

Every rate limit here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for rate limits

4 MCP tools reach this
  • find_rate_limitsBrowse and filter every rate limit in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools

Call it yourself

curl for this page
This rate limit 
curl "https://apis.io/api/v1/rate-limits/frankfurter-rate-limits"
All rate limits 
curl "https://apis.io/api/v1/rate-limits?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no email required.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have.