How do you get live currency exchange rates via API?

'Live exchange rates' is a phrase that hides a decision. Central-bank reference rates are published once per business day; interbank quotes move by the second and cost real money. Most products that say 'live' actually want the first kind - a stable, citable, non-commercial number for converting a displayed price - and get into trouble when they treat it as the second.

The ECB's rates are the reference standard for that job, and they come with two properties that break naive code. They are published around 16:00 CET on TARGET business days, which means there is no Saturday rate, no Sunday rate and no holiday rate. And they are quoted against the euro, so every non-EUR base is a cross-rate computed from two EUR quotes.

The third trap is coverage. The ECB publishes 29 currencies. Not 150, not crypto, and - since 2022 - not the Russian rouble. A pipeline that assumes any three-letter code will resolve will produce silently incomplete responses rather than errors.

When you ask for a date the ECB did not publish, you get the previous publication and both dates in the response. We requested historical for 2026-08-23, a Sunday, and got back date '2026-08-21' - the Friday - with requested_date '2026-08-23' preserved alongside it. Nothing failed and nothing was invented. Key your time series on date if you want distinct rows, on requested_date if you want one row per calendar day, but know which one you picked. fluctuation snaps the same way: start 2026-08-01 came back with start_date 2026-08-03.

An unsupported currency does not raise an error, and this is the single most important thing to check in your integration. We asked latest for symbols 'RUB,EUR,BTC' and got ok:true with rates containing exactly one entry - EUR - and unavailable ['RUB','BTC']. record_count read 1. If you only assert on ok you will ship a converter that silently drops two thirds of its currencies. Assert on unavailable being empty, or on the key you actually need being present in rates.

The 29 currencies the ECB publishes are AUD, BRL, CAD, CHF, CNY, CZK, DKK, GBP, HKD, HUF, IDR, ILS, INR, ISK, JPY, KRW, MXN, MYR, NOK, NZD, PHP, PLN, RON, SEK, SGD, THB, TRY, USD and ZAR, plus EUR as the quote currency. base accepts any of them and the cross-rate is computed for you: base USD returns EUR 0.856971, JPY 159.071043, TRY 48.117319 and so on. The currencies action returns the live set - 30 entries including EUR, each with its full name ('TRY': 'Turkish Lira') and a note about retired codes - so you never have to hard-code ours.

Precision differs between endpoints, deliberately. latest rounds to six decimal places (EUR 0.856971); convert returns the un-rounded rate it used (0.85697146) plus the result, so a converted amount and a rate you multiply yourself agree to the cent. If you are reconciling numbers between two of your own systems, use convert on both sides rather than one of each.

Latency splits sharply by endpoint because only some of them need a fresh fetch. In our runs latest took 1.1 to 2.4 seconds, while historical, convert and fluctuation answered in 19, 53 and 20 milliseconds. Historical data does not change, so it does not need re-fetching.

fluctuation is the endpoint people build by hand and should not. Give it a start and an end and it returns per-currency start_rate, end_rate, change and change_pct in one call: over 2026-08-03 to 2026-08-26 the euro moved -1.1484 percent against the dollar, the yen +1.5263 and the lira +1.2219. Every response also carries an attribution string naming the ECB and noting the rates are for information rather than settlement - that line is part of using the data properly, not decoration.