Exchange rate API problems developers bring to Reddit
Five Reddit threads from 2018 to 2025 tell the same story at different stages of a project: first someone wants free data, then they need history, and eventually the dependency or its limits become the real problem.
The provider names change; the failure modes do not. One 2024 post starts after a repository-backed currency feed disappeared. A 2021 post asks for unlimited free requests. Threads from 2018 and 2023 need historical data, not a latest-rate widget. Those are separate engineering requirements, and choosing one API by its free-tier headline will not resolve them.
Five threads, five years of the same constraints
These posts are useful as dated problem reports, not as a current provider ranking. Reddit comments age quickly, but each original question exposes a requirement that still belongs in an API evaluation.
- 2018: Looking for a free exchange-rate API asks for a complete historical range. That is a bulk-ingestion job, not a latest-rate request repeated hundreds of times.
- 2021: Any free currency exchange-rate API with no request limits? asks for unlimited hosted usage. The missing input is expected traffic: a daily job and a per-page request have completely different costs.
- 2023: Forex data API is about historical research. A backtest needs one consistent series with the observation time and source retained alongside it.
- 2024: GitHub just nuked the currency exchange rates API begins after a repository-backed feed disappeared. A no-key URL removed setup work, but it did not remove dependency risk.
- 2025: Which currency-rate APIs do you use? asks about reliability and the data behind a keyless service. That is the right question after basic endpoint coverage is established.
Three decisions before choosing a provider
Before launch, run one failure drill: block the upstream hostname or force a timeout. The application should return the last successful value with a visible stale flag, preserve its original observation time, and alert after repeated failures. If it instead spins forever or returns zero, the fallback is not ready.
How exchangerate.dev fits these use cases
exchangerate.dev is designed for software that needs a documented REST response rather than a consumer conversion page. The first latest-rate request can be made without a key and is capped per IP. A free key provides 10,000 calls per month at 12 requests per minute; paid plans raise the limits. Check the current pricing before designing a production budget.
465 pairs are covered with daily history back to 1999-01-04. Actively traded currencies update about every 60 seconds during the trading week; reference data is daily. Each response exposes source, market_session, timestamp, and notice, so an application can distinguish a live aggregate from a daily reference or a value carried across a weekend.
For a production integration, send a bearer token in the Authorization header, cache the response at the cadence your product needs, and retain the source and timestamp alongside any stored value. See the API reference for request and response details.
What I would ship for each job
- A personal widget: one cached anonymous request, a visible “updated at” time, and a last-good value for brief outages.
- A SaaS dashboard: a server-side key, one scheduled upstream refresh, a timeout, and no direct provider call from the browser.
- A historical chart: a one-time range import plus incremental updates. Do not refetch the whole history on every page view.
- A backtest: one versioned dataset with source, observation time, missing-day policy, and transformations recorded.
- A payment or trade: the executable quote from the institution that will settle it, not a public indicative feed.