Why fawazahmed0 exchange-api Is Not a Standard Rate Source: Undisclosed Data, Missing Days and a 7-Day Cache

fawazahmed0/exchange-api, published on npm as @fawazahmed0/currency-api and served from jsDelivr and currency-api.pages.dev, is one of the most used free currency data sources on the web. It has more than 2,700 GitHub stars, and jsDelivr counts about 947 million requests for the package in a month. It is public domain (CC0), needs no key and has no rate limits. For a hobby project or a prototype it is a gift.

It is also a set of static JSON files rebuilt once a day by one person's GitHub Actions workflow. This article looks at what that means when the numbers end up in a product, an invoice or a ledger.

Sources. Every statement about exchange-api below comes from its own README, workflow file, migration notes and GitHub issues, or from its live files, read on 10 November 2026. Issue reports are users' reports; they are quoted as such.

What makes a rate a standard reference

When an accountant, an auditor, a tax authority or a contract talks about "the exchange rate", they mean a rate with five properties. These are the same ideas that benchmark rules such as the IOSCO Principles for Financial Benchmarks and the EU Benchmarks Regulation are built around: governance, a transparent methodology and accountability.

1. A named publisher. You can say whose rate it is: the European Central Bank, the Federal Reserve, HMRC.
2. A stated method and time. You know how the figure is produced and what moment it refers to.
3. A stable record. The figure for a past date exists, can be looked up again, and does not silently change.
4. Fitness stated by the publisher. The publisher says what the rate may be used for.
5. Someone accountable. There is an institution or a contract behind it, not just a URL.

Test 1: a named publisher. The source is a secret

The README, the migration guide and the licence do not say where the rates come from. The workflow reads its source addresses from repository secrets. When a user asked, the maintainer answered in issue #36:

"Previously, I use to scrape date from google and bing, but there were some stability issues. So I ended up using a stable paid API(I cannot tell the name). And I have kept the url hidden, because the url has my api keys in it."

In March 2026 another user opened issue #147, titled "auditing question - where do the rates come from?". The reply was a pointer back to issue #36. So the answer to an auditor's first question, "whose rate is this?", is that nobody outside the project knows. The response itself does not help: it contains a date and a map of numbers, with no source field, no timestamp and no indication of whether the figure is a mid, bid or ask rate.

Test 2: a stated method and time

The workflow is scheduled for 00:00 UTC. In practice the maintainer says "Github actions can run any time after UTC 00:00", and the npm publish times on the four days before this article were between 05:32 and 06:53 UTC. What moment the rates themselves refer to is not stated anywhere.

The file mixes more than 340 codes for fiat currencies, cryptocurrencies and metals in one flat list of lowercase keys. That has caused collisions: issues #119 and #135 report the Mongolian tugrik, mnt, being overwritten by a crypto token with the same ticker.

Test 3: a stable record

• History starts in March 2024. The maintainer states "Historical data is from 2024-03-06". Everything before that was lost in a forced migration: "GitHub has locked all the forks of currency-api and even I have not taken backup of currency-api due to large size... its just best to assume the data is gone." (issue #60)
• Days are missing. The file for 10 December 2025 does not exist on either host. The maintainer's explanation in issue #144: "Github actions was failing on 2025-12-10... There is not much I could do to get the 2025-12-10 data back".
• Errors in past files stay. In issue #133 about a wrong Bitcoin Cash rate, the maintainer wrote "there is not much I could do for wrong rates in old currency data."
• The address has already changed once. In early 2024 GitHub asked for the original currency-api repository to be removed because of its size. The project moved to npm and Cloudflare, the URL format changed, and the pair endpoint was removed. The old jsDelivr address returns 404 today.

Test 4: fitness stated by the publisher

The README makes four claims: "Free & Blazing Fast response", "No Rate limits", "200+ Currencies, Including Common Cryptocurrencies & Metals" and "Daily Updated". It makes no claim about accuracy or about what the rates are suitable for, and it carries this warning: "Please include Fallback mechanism in your code, for example if cdn.jsdelivr.net link fails, fetch from currency-api.pages.dev".

On accuracy, the maintainer's position in the issues is consistent and candid: "This issue is from upstream api. There is not much I could do, other than report the issue when it arises." (issue #123). Reported examples include:

Test 5: someone accountable

The repository has two contributors: the maintainer, with 116 commits, and one other person with one. It is a personal account. There is no company, no support address and no service level; the support channel is the issue tracker, which had 44 open issues on the day of writing. The licence is CC0, which disclaims warranties. This is normal for a volunteer project, and it is exactly why it should not sit unprotected in a production path.

The delivery problem: @latest on jsDelivr

The address in most tutorials uses the @latest alias. jsDelivr's own documentation says of that alias: "Omit the version completely or use 'latest' to load the latest one (not recommended for production usage)", and that version aliases are "cached on our CDN for 7 days". The response header on the @latest file on 10 November 2026 was cache-control: public, max-age=604800, s-maxage=43200: twelve hours at the CDN edge and seven days in a browser.

So a web page that fetches the @latest URL directly can keep showing a rate that is days old, with nothing in the response to reveal it except the date field. jsDelivr's terms also say it does not guarantee that the CDN "will always be available or uninterrupted".

Scorecard

Where you should not use it

• Checkout, payments and payouts, where a wrong or stale rate costs money.
• Invoices, tax returns and customs, where the law names a rate and its publisher.
• Accounting and audit, where the source has to be cited and the figure reproduced.
• Anything needing history before March 2024 or a guarantee that a past day exists.

If it is already in your code, the migration guide has drop-in replacement and fallback code.

What a standard source looks like

The standard source is the institution your rule or policy names, with its own date. A few examples of what "stated method and time" means in practice:

• European Central Bank: euro reference rates from a concertation between central banks at about 14:10 CET, published around 16:00 CET each working day.
• Federal Reserve H.10: noon buying rates in New York, certified by the Federal Reserve Bank of New York for customs purposes.
• HMRC: monthly rates published on the penultimate Thursday of each month for the following month, for customs and VAT.
• Central Bank of the UAE: mid rates at 6pm UAE time, Monday to Friday, published for VAT obligations.

You can take these from each institution's website, or from an API that passes the table through unchanged with the publisher's date. AllRatesToday serves the official tables of 123 central banks and 6 tax authorities that way:

curl "https://allratestoday.com/api/open/central-bank/ecb" # "bank": "ecb", "rate_date": "2026-11-09", "cadence": "daily", # "rates": [ { "base": "USD", "quote": "EUR", "type": "reference", "value": ... }, ... ] 

One caution applies to every vendor, ours included: a live mid-market rate is not an official rate, whoever serves it. It is the right number for showing a price. For anything a rule, an auditor or a contract will check, use the published table.

FAQ

Where does fawazahmed0 exchange-api get its exchange rates?

The repository does not say. Its workflow reads the source addresses from secrets, and the maintainer wrote in a GitHub issue that the project uses a paid API whose name cannot be disclosed.

Is fawazahmed0 currency-api reliable enough for production?

It is a free daily file maintained by one person, with no service level. Its README asks users to code a fallback, some days have never been published, and the maintainer says errors in past files cannot be corrected. Use it in production only behind a fallback, a staleness check and your own stored copy.

Why does the currency-api @latest URL return old rates?

jsDelivr caches version aliases such as @latest. Its documentation says they are cached for up to seven days and that latest is not recommended for production use. Request a dated URL instead.

How far back does fawazahmed0 exchange-api history go?

To March 2024. The maintainer states that historical data starts on 2024-03-06, and that the data from the earlier repository was lost when GitHub required its removal.

Can I use it for accounting or tax?

No rate in it can be attributed to a named publisher, so it cannot be cited as the rate a rule or an auditor asks for. Use the table published by the central bank or tax authority your rule names.

Originally published on AllRatesToday. Official central bank and tax authority tables as JSON, CSV, XML and Excel: allratestoday.com/central-bank-rates-api/.