Free Exchange Rate APIs in 2026: Rate Limits, Staleness, and When You Should Pay

Currency conversion looks like a solved problem until it is in production. Then you discover the free endpoint you wired up in an afternoon updates once a day, rate-limits by IP, and returns a 200 with stale data instead of an error.

This is a practical comparison, written by people who resell an FX endpoint — so read the tradeoffs section knowing that.

What actually differs between FX APIs

Not the numbers. Mid-market rates from any reputable source agree to four decimal places. What differs:

Update frequency. Daily-refresh feeds are fine for invoicing and reporting. They are wrong for anything a user sees next to a checkout button in a volatile pair.

Base-currency restrictions. Several free tiers lock you to USD or EUR as base and expect you to cross-rate yourself. That is fine arithmetic and a real source of rounding bugs.

Failure behaviour. The important question is what you get at 3am when the upstream is down. A cached-but-stale 200 is more dangerous than a 503, because your code will happily bill someone at last week's rate.

Rate limiting model. Per-IP limits break the moment you deploy to serverless, where your outbound IP is shared and rotating. Key-based limits are predictable; IP-based limits are a lottery.

The honest cost math

Free tiers are genuinely the right answer at low volume. If you do 500 conversions a month, pay nothing.

The crossover is not about volume alone, it is about what a wrong rate costs you. Run this:

Calls per month × price per call = your API cost.
Probability of a stale/failed rate × average order value × orders affected = your error cost.

At 50,000 calls/month, a $0.01/call endpoint is $500 — expensive. At 3,000 calls/month it is $30, and one mispriced order avoided pays for it. Most products sit in the second bucket and over-optimise for the first. (Sub-cent per-call pricing, which FX endpoints usually carry because the upstream data is cheap, moves the crossover further in your favour — check the actual per-call rate rather than assuming a flat cent.)

Design rules that matter more than your vendor choice

Cache aggressively and deliberately. Mid-market rates for a fiat pair do not need to be fetched per request. Cache per pair with a TTL you choose based on how volatile the pair is and how much a wrong rate costs. This usually cuts call volume by 95% and makes vendor pricing almost irrelevant.

Store the rate you used, with a timestamp. Never recompute a historical conversion from a live rate. Persist rate, source, fetched_at alongside the transaction. Your future self doing a refund or an audit will need it.

Fail closed on money paths. If the rate is older than your acceptable window, do not silently use it on a checkout. Block, or fall back to the customer's original currency.

Never round mid-pipeline. Carry full precision through the computation and round exactly once, at display or settlement.

Where a paid endpoint is worth it

Three cases, concretely:

You are on serverless and hitting IP-based limits. A key-based paid endpoint removes an entire class of intermittent failure.
You need predictable error semantics. Paying gets you a vendor who returns a real status code instead of stale data.
You are already buying other API calls and consolidating onto one key, one balance, and one invoice is worth more than the per-call delta.

Our endpoint

We run an exchange-rate endpoint on a prepaid credit model — 0.3 credits per call, which is $0.003 — no subscription, no monthly minimum, credits do not expire:

curl "https://theglitchstore.com/api/secure-proxy?api=exchange-rate-api&path=/latest/USD" \
  -H "x-api-key: gstore_your_key_here"

Applying our own test to ourselves: this feed refreshes on a business-day cadence. By the rule above, that makes it right for invoicing, reporting, internal dashboards and display conversion — and wrong if you need intraday rates next to a live checkout in a volatile pair. We would rather tell you that than sell you the wrong endpoint.

Where it is also not the right choice: tick-level FX for trading, or multi-year historical series. Buy a specialist financial data vendor for those.

The general point stands regardless of who you buy from: cache by pair, store the rate you used, and fail closed on money.