How to compare free exchange-rate APIs in 2026
Picking a free FX data source is not just about the price. Six dimensions matter: quota, intraday freshness, freshness metadata, history depth, a conversion endpoint, and agent support. Here is how to think through each one.
Most free exchange-rate APIs look similar on the surface: JSON, a bearer token, maybe 100 currencies. The differences that actually matter for a real project show up between the daily fix and the next one, in error messages when you hit a limit, and in the fields your code has to trust at 3 a.m. Choose by dimensions, not by brand ranking.
source and market_session in every response tell your code what it is actually looking at, without guessing from the clock./v1/{date}/{base}./v1/convert endpoint and an MCP server at /v1/mcp mean less glue code for common tasks.Why dimensions beat rankings
A ranked list of APIs tells you which one the author preferred on the day they wrote it. A dimension-by-dimension breakdown tells you which one fits your project. A dashboard that only consumes once-daily reference data has different needs from a travel app that quotes prices through the day.
The six dimensions below cover the questions that come up in almost every FX integration. Work through them in order and most projects will have a clear answer before they finish.
Dimension 1: free monthly quota and rate limit
Quota determines whether you can prototype and run a small production workload for free, or whether you hit a wall inside a week. Rate limit determines whether you can burst calls in a batch job without writing retry logic from day one.
The ECB publishes its reference rates at no cost and with no quota. The trade-off is that it is a raw XML feed, not a developer API, and it updates once per business day. The open-source Frankfurter project wraps ECB data in a JSON API with no key and no enforced quota, though it inherits the once-daily update cadence.
A third keyless category is worth knowing apart from either of those: community-maintained, CDN-hosted static-JSON projects such as fawazahmed0/exchange-api. There is no server answering your request at all — just versioned JSON files served from jsDelivr or Cloudflare Pages, updated daily, covering 200+ currencies (including common cryptocurrencies) under a CC0 public-domain license, with no key and no enforced rate limit. The trade-off is architectural: no source or freshness metadata, no conversion endpoint, no live intraday updates, and no single party accountable if a mirror goes down — the project's own docs recommend wiring a fallback between its two CDN hosts for exactly that reason.
For a keyless starting point, exchangerate.dev accepts anonymous calls capped per IP address. A free key, available at /signup with no card, raises that to 10,000 calls a month and 12 requests a minute.
Dimension 2: intraday freshness
This is the dimension most developers do not think about until something breaks. The ECB reference fix is published around 16:00 CET each business day — after that, the market keeps moving but the fix does not update until the next business day. Any API sourced only from that fix will return the prior day's rate for the rest of the afternoon, overnight, and through the weekend.
For a pipeline that only ever consumes once-daily closing rates, that is fine. For a consumer-facing app, an e-commerce site, or any code that expects "latest" to mean the current market, you need to know whether the rate reflects intraday movement or a fix from up to 24 hours ago.
exchangerate.dev has a live source that updates approximately every 60 seconds through the trading week. When a pair comes from that source, market_session tells you the current session state (open, weekend, etc.) and data_updated_at confirms exactly when the rate last moved.
Dimension 3: freshness metadata
A rate is a number. Knowing whether that number is from a spot aggregation three minutes ago or a reference fix from yesterday morning changes what you can responsibly do with it.
Most APIs return a timestamp. That tells you when the response was built, not when the underlying data last moved. exchangerate.dev returns two fields that together answer the real question:
source: one oflive(aggregated spot),ecb_daily(ECB reference fix), orfred_daily(Federal Reserve daily series).market_session:open,weekend, orinterbank_closed; tells you the state of the interbank trading week.data_updated_at: when the underlying rate was last written, separate fromtimestamp(when the response was built).is_forward_filled: on history and range responses,truemeans no rate was published that day and the prior value was carried forward.
A caching layer that checks data_updated_at instead of timestamp avoids serving stale data to users while also avoiding unnecessary upstream calls.
Dimension 4: history depth
Daily history determines whether you can backfill a dataset, build a chart of the past year, or run a regression over a decade of rates. Some free APIs cap history at 90 days. Others gate deeper history behind a paid tier.
exchangerate.dev exposes daily history back to 1999 on the free tier. A single dated path, /v1/2024-01-15/USD, returns the rate for that day. A /v1/range endpoint with start_date and end_date params returns a full series in one call. The ECB EXR series and FRED data underlie those historical records, so coverage matches what those institutions have published.
Dimension 5: a built-in conversion endpoint
Many APIs return a table of rates and leave the multiplication to you. That is fine for a single pair, but a batch conversion job or a checkout flow converting a cart total needs a conversion primitive, not a math helper.
GET /v1/convert/USD/EUR/100 returns rate, converted, and derived in one call. A POST /v1/convert endpoint handles batch conversions in a single request. Triangulated crosses, pairs not quoted directly against each other, are handled server-side.
Dimension 6: agent and MCP support
LLM agents and AI assistants need structured tool definitions to call an API reliably. A raw REST API requires you to write that glue yourself; an MCP server ships the tool definitions with the API.
exchangerate.dev runs a Model Context Protocol server at https://api.exchangerate.dev/v1/mcp (server name exchangerate-dev). It exposes five tools: list_currencies, get_rate, convert, get_range, and search_docs (FAQ search). Tools share the same monthly quota and per-minute limit as the REST API, so there is no separate billing to track.
Six dimensions side by side
Picking the right fit
If your project only needs a once-daily closing rate, does not need freshness metadata, and does not mind fetching the raw ECB XML feed, Frankfurter covers a lot of ground for free. It is a well-maintained open-source project and a reasonable starting point.
If you need intraday freshness (rates that move through the day, not just at the ECB fix), want source and market_session in the response, need history past what is easily available from the ECB feed, or are building an LLM agent that calls FX tools, exchangerate.dev is designed for those cases. The free tier does not require a card and the MCP server is included.
The right API is the one whose limitations match your use case, not the one with the longest feature list.