How to compare free exchange-rate APIs in 2026

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 on weekends, 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.

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 runs on weekdays has different needs from a travel app that quotes prices on Saturday afternoon.

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.

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 50,000 calls a month and 30 requests a minute.

Dimension 2: weekend freshness

This is the dimension most developers do not think about until something breaks. FX spot markets are open through the weekend. The ECB reference fix, published around 16:00 CET each business day, does not update on Saturday or Sunday. Any API sourced only from that fix will return Friday's closing rate all weekend.

For a dashboard only used Monday through Friday, that is fine. For a consumer-facing app, an e-commerce site, or anything a user opens on a Sunday, you need to know whether the rate you are showing moved since Friday.

exchangerate.dev has a live source that continues through Saturday and Sunday. When a pair comes from that source, market_session will read weekend rather than open, and the rate has moved since the Friday close.

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 of live (aggregated spot), ecb_daily (ECB reference fix), or fred_daily (Federal Reserve daily series).
• market_session: open, weekend, or a named session; tells you the state of the FX trading day.
• data_updated_at: when the underlying rate was last written, separate from timestamp (when the response was built).
• is_forward_filled: on history and range responses, true means 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 four tools: list_currencies, get_rate, convert, and get_range. 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 weekday rates, 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 weekend coverage, 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.