DEV Community: viraj geeth

ChatGPT currency converter with official exchange rates: the AllRatesToday app

viraj geeth — Mon, 02 Nov 2026 18:12:37 +0000

Ask ChatGPT "what is 500 GBP in euros?" and you usually get a number from memory, somewhere near the truth, with no date and no source. As a currency converter that is fine for curiosity. It is useless for an invoice, a customs form, a tax return or anything an auditor will read later, because those need the exchange rate a named institution published on a named day.

As of today the AllRatesToday app is live in the ChatGPT app directory:

AllRatesToday on ChatGPT

Once it is added, ChatGPT works as a currency converter backed by official exchange rates: it calls our tools instead of guessing, and every answer carries the institution and the publication date.

Why ChatGPT exchange rates are often wrong

A language model has no exchange rate feed of its own. Without a tool, "the exchange rate today" is whatever figure was common in its training data, which can be months old, and the model rarely says so. Even when it searches the web, it picks up a market quote from a random page at a random time, which is not the rate a tax office or customs authority asks for. The app fixes both problems: the number comes from the publisher's table, and the answer states the date it belongs to.

How to use ChatGPT as a currency converter with official rates

Open the AllRatesToday app page in ChatGPT and add it. There is no sign-up and nothing to configure.
Ask in plain words: "convert 2,000 USD to INR at the official rate", or "ECB exchange rate today for GBP".
Read the date and the institution in the answer. If you need a different publisher, name it: "use the Bank of England rate instead".

What you can ask

You ask	What comes back
"Convert 500 GBP to EUR using the official daily rate."	The ECB reference rate for the pair, its publication date, and the converted amount.
"What is the latest ECB reference rate for USD?"	The figure from the ECB's own table, dated.
"Reserve Bank of India reference rate for USD today."	The RBI table's USD/INR print and its date.
"HMRC exchange rate for invoicing in JPY this month."	The current HMRC monthly rate for JPY.
"Which central banks do you cover, and when did the Bank of Thailand last publish?"	The list of 123 central banks and 4 tax authorities with each one's latest publication date.
"Give me one reproducible EUR/USD rate for 31 October for my month-end report."	The 16:00 London daily reference rate, with its disclaimer.

Pairs the ECB does not publish fall back to the central bank that issues one of the two currencies, and the answer says which. A pair that a bank does not print directly is cross-computed inside that bank's own table and flagged as derived, so nothing is presented as a published figure when it is not.

What it deliberately does not do

No live market quotes. The app serves official daily publications. They can lag the market by a day, and the answer always says which day. If you need a one-minute mid-market rate, that is the API, not the ChatGPT app.
No payments, no transfers, no execution. It is a lookup tool.
No user data. The app has no login and keeps no profile. It receives the currency codes and bank code ChatGPT sends for the question and nothing else. The privacy policy spells this out.
No upsell inside the chat. The tools do not ask for an API key, and they do not accept one. Every tool in the app is the keyless public surface.

Where the numbers come from

The same pipeline that feeds the central bank rates API: each institution's own publication, collected on its own schedule, stored in the direction the publisher quotes it, with a cross-source plausibility check before anything is served. The list of institutions and their source pages is on the data sources page. The 16:00 London reference rate is described on its own page; it is a reproducible daily snapshot, not a registered benchmark, and the app repeats that caveat when it uses it.

For developers: the same tools outside ChatGPT

The app is a thin wrapper over our hosted MCP server. The keyless profile ChatGPT uses is at https://allratestoday.com/api/mcp/public and exposes five tools: an official daily exchange rate, the supported currencies, the covered institutions, any institution's latest table, and the daily reference rate. The full endpoint at https://allratestoday.com/api/mcp adds live mid-market rates, dated tables and history with a free API key, and works in Claude, Cursor, VS Code, Codex and any other Streamable HTTP MCP client. Setup for each is on the MCP page, and the REST equivalents are in the docs.

If you build an agent that files numbers somewhere, the habit the app enforces is the one worth copying: never return a rate without the institution and the date it belongs to.

AllRatesToday is on GitHub and X. The original post is on allratestoday.com.

15.8 million official exchange rates from 123 central banks and 4 tax authorities, now on Hugging Face

viraj geeth — Fri, 30 Oct 2026 12:59:57 +0000

If you have ever needed "the ECB rate on the invoice date" for a tax return, a customs form, a transfer-pricing file or an audit, you know the problem. The number exists. It is public. And it is scattered across a hundred central-bank websites, each with its own PDF, XML feed, Excel download or HTML table, each with its own idea of which way round a rate should be quoted.

We spent most of this year collecting those tables into one pipeline. As of this week the full history is a public dataset on Hugging Face:

https://huggingface.co/datasets/AllRatesToday/central-bank-exchange-rates


Rows	15,848,587
Institutions	123 central banks + 4 tax authorities
Earliest date	1914 (Swiss National Bank)
Currencies	215 base, 202 quote
Refresh	daily, from the GitHub source repo
License	CC BY-NC 4.0 (non-commercial, attribution)
Size	515 MB CSV, auto-converted to Parquet

Why "official" rates and not market rates

Most exchange-rate datasets are market data: a mid-market snapshot from some aggregator at some time of day. That is the right thing for a price display. It is the wrong thing for anything a regulator will look at.

Tax offices, customs agencies and accounting standards usually name a publisher. HMRC publishes monthly rates for UK VAT and customs. The ECB reference rate is the default for euro-area statutory reporting. The Reserve Bank of India reference rate is the benchmark for statutory rupee conversions. The Reserve Bank of Australia, Bank of Canada, Banco Central do Brasil and dozens of others publish a daily fixing that is the rate for that jurisdiction, regardless of what the interbank market did five minutes later.

Those numbers are not derivable from market data. They have to be collected from the source, on the source's schedule, in the source's convention. That is what this dataset is.

What is in it

One CSV per institution under rates/, five columns, identical everywhere:

Column	Type	Meaning
`date`	string	ISO 8601 publication date. Weekends and the publisher's holidays are simply absent.
`base`	string	The currency being priced (ISO 4217).
`quote`	string	The currency it is priced in.
`type`	string	The publisher's own label: `reference`, `middle`, `buy`, `sell`, `spot`, `indicative`, `monthly`, `monthly_average`, `quarterly`, `close`, and a few more.
`value`	float	How many `quote` one `base` buys.

A few rows from rates/ecb.csv:

date,base,quote,type,value
2025-01-02,EUR,AUD,reference,1.6618
2025-01-02,EUR,BGN,reference,1.9558
2025-01-02,EUR,BRL,reference,6.42

Alongside the history there is latest/<code>.json with each institution's most recent table, and sources.json with the institution's name, country, home currency, kind (central bank or tax authority) and the URL of the page we collect from.

Coverage by depth, to give you a sense of what "back to 1914" actually means:

Institution	Code	First year in dataset
Swiss National Bank	`snb`	1914
Bank of Korea	`bok`	1964
Bank of Israel	`boi`	1975
Hong Kong Monetary Authority	`hkma`	1981
Bank of Japan	`boj`	1998
European Central Bank	`ecb`	1999
Reserve Bank of India	`rbi`	2003
People's Bank of China	`pboc`	2006

Most institutions only publish a few years of history on their own sites. Where a bank offered more, we took all of it.

Loading it

Since 2 November 2026 the Hugging Face dataset is gated. You need a Hugging Face login and a free AllRatesToday account: on the dataset page click Get access and paste your AllRatesToday API key into the form. A valid key is approved within about 5 minutes; an invalid one is rejected. In code, run huggingface-cli login once or set HF_TOKEN, and every snippet below works unchanged. The GitHub repository and the keyless API need no account; the Kaggle copy stays open and we ask you to register there too.

With the datasets library, the whole thing as one table:

from datasets import load_dataset

ds = load_dataset("AllRatesToday/central-bank-exchange-rates", "rates")

With pandas, one institution at a time. This is usually what you want, because 15.8 million rows is a lot of memory for a question about one bank:

import pandas as pd

ecb = pd.read_csv(
    "hf://datasets/AllRatesToday/central-bank-exchange-rates/rates/ecb.csv",
    parse_dates=["date"],
)
usd = ecb[(ecb.base == "EUR") & (ecb.quote == "USD")].set_index("date")["value"]
print(usd.resample("YE").mean().tail())

With Polars, lazily, if you want to scan several banks without loading all of them:

import polars as pl

df = (
    pl.scan_csv("hf://datasets/AllRatesToday/central-bank-exchange-rates/rates/*.csv")
      .filter((pl.col("base") == "USD") & (pl.col("quote") == "INR"))
      .collect()
)

With DuckDB, straight off the Hub, no download step:

INSTALL httpfs; LOAD httpfs;

SELECT date, value
FROM 'hf://datasets/AllRatesToday/central-bank-exchange-rates/rates/rbi.csv'
WHERE base = 'USD' AND quote = 'INR' AND type = 'reference'
ORDER BY date DESC
LIMIT 5;

Three things you can do with it that you could not do before

Compare what different central banks say the same pair is worth. The ECB publishes EUR→USD. The Fed publishes USD→EUR. The Bank of Canada publishes both against CAD. On any given day these disagree by a few basis points because they fix at different times. That spread is itself interesting, and until now you had to scrape three sites to see it.

Reconstruct a filing exactly. Pick the publisher your jurisdiction names, filter to type == "reference" (or whatever that publisher calls its headline rate), take the row for the invoice date. If the date is missing, the publisher did not publish that day, and your local rule will say whether to use the previous or next business day.

Train on a century of official fixings. The SNB series runs from 1914. The Bank of Korea from 1964. If you are building anything that needs long, clean, non-market FX series, this is a larger and more consistent corpus than we could find anywhere else in the open.

Conventions and caveats

We made a few decisions that you should know about before relying on the data.

Direction follows the publisher. If the ECB says 1 EUR = 1.0850 USD, that is the row: EUR,USD,reference,1.0850. We do not flip rates, and we do not compute crosses. If a bank does not publish GBP against JPY, there is no GBP/JPY row for that bank.
type is the publisher's label, normalised only in spelling. A buy rate from one bank and a buy rate from another are not guaranteed to mean the same thing. Read the source page linked in sources.json if it matters.
Gaps are real. A missing date means the institution did not publish, or published something our collector could not parse and our validation rejected. We would rather have a hole than a wrong number.
Every row went through a cross-source plausibility check before it was committed. Values that disagree with the rest of the world by more than a threshold are quarantined and reviewed by hand. That caught a handful of unit errors during the backfill, which is why we trust the rest.
Verify before you file. The figures are public information republished under CC BY-NC 4.0. For anything legal or tax-related, the original publisher's page is the authority, and it is linked from sources.json for every institution.

How it stays current

The dataset is a mirror of a GitHub repository, AllRates-Today/central-bank-exchange-rates, which is itself fed by the collection pipeline behind AllRatesToday. A scheduled Action runs four times a day, pulls each institution's latest table from a keyless open endpoint, commits only when something changed, and then pushes the consolidated per-institution CSVs to Hugging Face. So the Hub copy is never more than a few hours behind the source sites.

If you want the same data as small JSON files on a CDN instead of a 500 MB dataset, the GitHub repo serves data/latest.json and per-bank latest.json over jsDelivr with no key. If you want it as an API with a query language, the same rates are behind https://allratestoday.com/api/open/central-bank/<code>, also keyless.

License

CC BY-NC 4.0. Non-commercial use (research, teaching, personal projects, journalism) with visible credit to AllRatesToday linking to https://allratestoday.com. Commercial use needs a licence: https://allratestoday.com/pricing#official.

If you build something with it, open an issue on the GitHub repo or leave a note in the dataset's Community tab. Missing an institution you need? The repo README lists how new sources get added, and we are actively expanding coverage.

An OpenClaw Skill for Exchange Rates: Stop Your Agent Guessing the USD/EUR Rate

viraj geeth — Thu, 29 Oct 2026 20:38:33 +0000

Ask an agent built on OpenClaw what 2,400 dollars is in euros and, without a tool, it answers from training data. The number looks right and is months old. We published a skill on ClawHub that fixes that with one install:

openclaw skills install allratestoday

What an OpenClaw skill is

OpenClaw is an open-source agent framework that runs on your own machine and acts through tools such as web_fetch and the shell. A skill is a SKILL.md file: a description that tells the agent when to load it, and a body with the procedure to follow. Skills live on the ClawHub registry, are scanned for safety, and install per agent or globally. There is no server to run, which is the main difference from an MCP server.

Rule zero: never state a rate from memory

The first line of the skill body is the rule everything else depends on. A remembered rate is stale by definition, and in a checkout, an invoice line or a customs declaration that is a financial bug. The skill tells the agent to fetch the rate and quote the date that came back with it. If the fetch fails, the agent says the rate is unknown rather than filling in a plausible constant.

Two kinds of rate, one decision

Most currency mistakes in agent output come from using a market rate where a rule names a publisher. The skill makes the agent decide first:

The request	What the agent fetches	Key
Convert an amount, show a price in another currency	`/api/open/latest/{BASE}`, the ECB daily table re-based to any currency	none
Invoice, VAT, customs, audit, "the ECB rate", "the HMRC rate"	`/api/open/central-bank/{code}`, the named institution's own table	none, non-commercial
Live mid-market, 160+ currencies	`/api/v1/rates`	free key
A past date or a history series	paid-plan endpoints	paid key

The ECB table and an institution's table routinely differ by a percent or more. An auditor will ask which publisher a figure came from, so the agent names it: "ECB reference table, 2026-10-29" or "SAMA official reference rate, 2026-10-29".

Reading a central bank table without getting the direction wrong

This is where agents fail quietly. Institutions publish in both directions. SAMA and the Bank of Korea quote home currency per foreign unit; the Reserve Bank of New Zealand and the Bank of England quote foreign units per home unit. The API returns every row as 1 base = value quote with both codes spelled out, and the skill tells the agent to read those fields rather than assume.

Many banks publish several rows for one pair: buy, sell, middle, reference. The skill sets the preference order (reference, then middle, then official, buy/sell mean last) and explains the stale flag, so a table the bank has not refreshed is reported with its real date.

The skill ships a reference file with all 127 institution codes and worked response examples, so the agent does not spend a fetch looking codes up.

Why keyless first

The skill works with nothing configured. The ECB table for any base and the latest table of every institution are open endpoints; the only requirement is a visible attribution link where rates are shown to others. A free key, read from ALLRATESTODAY_API_KEY, adds live mid-market rates. History and dated tables are on paid plans, and the skill tells the agent to say so on a 403 instead of improvising.

Try it

openclaw skills install allratestoday
Ask: "Convert 2,400 USD to EUR and tell me which table you used."
Ask: "What is HMRC's rate for AED this month?" and check that the answer carries the publication date.

MIT licensed. Source: AllRates-Today/openclaw-skill. Page and FAQ: allratestoday.com/openclaw.

Rates by AllRatesToday. Follow @Allratestoday.

moneyify: A cashify-compatible currency converter with built-in live rates

viraj geeth — Tue, 27 Oct 2026 15:01:44 +0000

If you've ever used cashify, you know the appeal: a tiny synchronous API for converting money, with expression parsing ("10 USD to EUR") and optional big.js precision.

The catch is that cashify stops there — you bring your own rates. In a real app, that means writing yet another fetch job, caching layer, and rate-refresh scheduler.

moneyify is a drop-in replacement that keeps the cashify API exactly the same, then adds one superpower: Moneyify.live() auto-fetches rates from the AllRatesToday API so you never need to maintain a rate table yourself.

What you get

💡 Drop-in cashify replacement — same sync convert, same expression parsing, same big.js support
🌍 Auto-fetch 160+ currencies at mid-market rates, no retail spread
📦 Zero runtime dependencies
🧮 Optional big.js integration for arbitrary-precision math
💬 Parses expressions: "10 USD to EUR", "€10 EUR in GBP", "1,250.5 usd in gbp"
🟦 Written in TypeScript, ships ESM + CJS + .d.ts

Install

npm install moneyify

1. Bring your own rates (identical to cashify)

import { Moneyify } from "moneyify";

const rates = { EUR: 1.00, GBP: 0.85, USD: 1.08 };
const m = new Moneyify({ base: "EUR", rates });

m.convert(10, { from: "EUR", to: "GBP" }); // 8.5
m.convert("10 EUR to GBP");                // 8.5
m.convert("€10 EUR in USD");               // 10.8

If you're already a cashify user, that's exactly the code you're used to — migrating is a rename.

2. Auto-fetch from AllRatesToday (the moneyify moat)

import { Moneyify } from "moneyify";

// Rates are fetched and cached on construction.
const m = await Moneyify.live({
  base: "USD",
  apiKey: process.env.ALLRATESTODAY_API_KEY,
});

m.convert(100, { from: "USD", to: "INR" });  // e.g. 8320.5
m.convert("50 USD to EUR");                   // e.g. 46.17

One call, fresh rates, no manual table maintenance. Get a free API key at allratestoday.com/register — no credit card required.

3. Functional style (also cashify-compatible)

import { convert } from "moneyify";

convert(10, {
  from: "EUR",
  to: "GBP",
  base: "EUR",
  rates: { GBP: 0.85, EUR: 1.0 },
}); // 8.5

4. Parse expressions without converting

Useful for building chat bots, Slack commands, or any UI where users type free-form money strings:

import { parse } from "moneyify";

parse("10 EUR to GBP");      // { amount: 10, from: "EUR", to: "GBP" }
parse("€10 EUR");            // { amount: 10, from: "EUR" }
parse("1,250.5 usd in gbp"); // { amount: 1250.5, from: "USD", to: "GBP" }

Supported separators: to, in, as (case-insensitive). Supported symbols: $, €, £, ¥, ₹, ₽, ₺, ₩, ₪, R$, A$, C$, HK$, NZ$, S$.

5. Precision math with big.js

Float drift becomes painful when you're adding up thousands of line items. Plug in big.js and precision is preserved:

import Big from "big.js";
import { Moneyify } from "moneyify";

const m = new Moneyify({
  base: "USD",
  rates: { EUR: 0.923456789 },
  BigJs: Big,
});

m.convert(100, { from: "USD", to: "EUR" }); // 92.3456789 (no float drift)

Why moneyify instead of cashify?

Short answer: when you don't want to own the rate-fetching problem.

cashify — great library, but assumes you already have rates
moneyify — same API, plus a live() constructor that handles rates for you

If your app is already fetching rates from somewhere, stay on cashify. If you want one package that does conversion and rate fetching, moneyify is the simpler surface.

Next steps

npm: moneyify
Free API key: allratestoday.com/register
Docs: allratestoday.com

Tried it out? Let me know what you built — expressions parser gotchas especially welcome.

Written by the team behind AllRatesToday — a free, keyless
exchange rate API with real-time mid-market rates for 160+ currencies and
official central-bank rates from 120+ sources. Browse the API docs or
grab a free key to start building.

Open source: official SDKs for JavaScript, Python, PHP and Rust,
plus an MCP server (@allratestoday/mcp-server) for AI agents.

Follow along: LinkedIn ·
X / Twitter · GitHub

live-currency-rates: One fluent API, three FX providers (no API key required to start)

viraj geeth — Mon, 26 Oct 2026 21:47:42 +0000

Picking an FX data provider is one of those decisions you don't want to couple your code to. ECB data is free but only ~30 currencies. fawazahmed0/currency-api is free and covers crypto, but it's CDN-based. AllRatesToday gives you real-time mid-market rates but needs a key. Each has different endpoints, shapes, and auth.

live-currency-rates is a tiny wrapper that hides all of that behind a fluent API. Write your code once; swap providers with one line when requirements change.

The API you actually write

import { Convert } from 'live-currency-rates';

const result = await Convert(100).from('USD').to('EUR');
console.log(result.amount); // 92.45

That's it. No setup needed to start — defaults to the free Frankfurter provider (ECB data, no key, no signup).

Install

npm install live-currency-rates

Zero dependencies. TypeScript types included.

Three providers, one interface

Provider	Key?	Currencies	Source	Notes
`frankfurter`	no	~30	European Central Bank	Default. Daily updates.
`fawaz`	no	200+	fawazahmed0/currency-api	Includes crypto. CDN-hosted.
`allrates`	yes	160+	AllRatesToday	Real-time mid-market rates.

Pick one with setup():

import { setup, Convert } from 'live-currency-rates';

// Free, no key — 200+ currencies including crypto
setup({ provider: 'fawaz' });

// AllRatesToday — real-time mid-market rates, free key at allratestoday.com/register
setup({ apiKey: 'art_live_...' });

Your existing Convert(...) calls don't change. That's the point.

Core API

`Convert(amount).from(...).to(...)`

const result = await Convert(250).from('GBP').to('JPY');
console.log(`250 GBP = ${result.amount} JPY`);
console.log(`Rate: ${result.rate}`);

Returns { amount, rate, from, to, originalAmount }.

`Rate('XXX').to('YYY')`

import { Rate } from 'live-currency-rates';

const { rate } = await Rate('USD').to('EUR');
console.log(`1 USD = ${rate} EUR`);

`Rates('XXX', ['YYY', 'ZZZ'])`

One round-trip, multiple pairs:

import { Rates } from 'live-currency-rates';

const rates = await Rates('USD', ['EUR', 'GBP', 'JPY']);
// { EUR: 0.92, GBP: 0.78, JPY: 149.5 }

Omit the target list to get every available rate for that base.

Why a wrapper?

Three reasons it earns its keep:

Start free, upgrade later. Ship the MVP with Frankfurter. When you hit a currency Frankfurter doesn't cover, flip to fawaz or allrates without touching call sites.
Test without hitting production. Point tests at Frankfurter; point prod at AllRatesToday. Same code.
Provider lock-in is costly. Every provider has different endpoint shapes. A fluent wrapper means a future provider migration is one file change, not a rewrite.

When you outgrow the wrapper

The wrapper optimizes for "I don't care which provider yet." If you've settled on a provider and need its full feature set, drop to the native client:

AllRatesToday only? Use @allratestoday/sdk — full API: historicals, time-series, preset periods.
Just want a one-liner + CLI? Use fx-rates.
Need cashify-compatible sync conversion? Use moneyify.

Next steps

npm: live-currency-rates
Free API key (AllRatesToday provider): allratestoday.com/register

Which provider did you land on, and why? Comments open.

Open source: official SDKs for JavaScript, Python, PHP and Rust,
plus an MCP server (@allratestoday/mcp-server) for AI agents.

Follow along: LinkedIn ·
X / Twitter · GitHub

fx-rates: Real-Time Currency Exchange Rates in Node.js (and from the Terminal)

viraj geeth — Mon, 26 Oct 2026 21:44:41 +0000

If you've ever wired a currency converter into a Node.js app, you know the pattern: pick an API, write an HTTP client, handle auth, parse JSON, cache results, build a CLI on top of it. It's a tiny domain that somehow turns into a mini-project.

fx-rates is a small, focused package that collapses that work into one line — both as a library and a CLI — backed by real-time mid-market rates from the AllRatesToday API.

Why fx-rates?

⚡ Real-time rates, not daily snapshots — updated every 60 seconds
🌍 160+ currencies including majors, emerging-market pairs, and precious metals (XAU, XAG)
📦 Zero runtime dependencies — uses native fetch, so no bloated http client
🖥️ Library AND CLI in one package
🔒 Mid-market rates — no retail markup, no hidden spread

Install

npm install fx-rates

Grab a free API key at allratestoday.com/register — no credit card required — and export it:

export ALLRATESTODAY_API_KEY="art_live_..."

Library usage

Get a rate

import { rate } from "fx-rates";

const r = await rate("USD", "INR");
console.log(r);
// {
//   date: "2026-04-20",
//   base: "USD",
//   target: "INR",
//   rate: 83.2145
// }

Convert an amount

import { convert } from "fx-rates";

const out = await convert(100, "USD", "EUR");
console.log(out);
// {
//   from: { currency: "USD", amount: 100 },
//   to:   { currency: "EUR", amount: 92.34 },
//   rate: 0.9234,
//   date: "2026-04-20"
// }

Pass the API key explicitly

Prefer not to rely on environment variables? Pass it in directly:

const r = await rate("USD", "EUR", { apiKey: "art_live_..." });

CLI usage

The same package ships a CLI. After installing (globally or via npx) you can run:

npx fx-rates USD EUR
# 1 USD = 0.9234 EUR  (2026-04-20)

npx fx-rates convert 100 USD EUR
# 100 USD = 92.34 EUR  (rate: 0.9234, date: 2026-04-20)

Handy for scripts, shell pipelines, and one-off conversions in the terminal.

When fx-rates is the right pick

You're building a Node.js service and don't want to take on a heavy HTTP client or a DI-heavy SDK
You need a tiny CLI for devops / scripting — budget alerts, invoice scripts, cron jobs that normalize amounts across currencies
You want mid-market rates (not retail FX) for accurate analytics, reporting, and financial apps

What fx-rates isn't

It's intentionally not a full SDK. There are no historical time-series endpoints, no conversion batches, no ORM-style client. If you need those, use @allratestoday/sdk — the full-featured official client. fx-rates is the "just the basics" option.

Next steps

npm: fx-rates
Get a free API key: allratestoday.com/register
Docs: allratestoday.com

If you ship anything cool with it, I'd love to see it — drop a link in the comments.

Open source: official SDKs for JavaScript, Python, PHP and Rust,
plus an MCP server (@allratestoday/mcp-server) for AI agents.

Follow along: LinkedIn ·
X / Twitter · GitHub

How to Handle Base Currency Conversion in Your App

viraj geeth — Mon, 26 Oct 2026 21:41:40 +0000

"How do I convert from EUR to GBP if my API only supports USD as the base currency?" This question appears in nearly every exchange rate API support forum. It is one of the most common developer pain points — and it is entirely avoidable with the right API or the right code.

The Base Currency Problem

Most exchange rate APIs return rates relative to a base (source) currency. When you call GET /rates?base=USD, you get:

{
  "base": "USD",
  "rates": {
    "EUR": 0.9234,
    "GBP": 0.7891,
    "JPY": 151.42
  }
}

This tells you how much 1 USD buys in each currency. But what if your users are in Europe and you need EUR to GBP?

The catch: Many free API plans lock the base currency to USD. Changing the base to EUR, GBP, or any other currency requires a paid upgrade.

API	Free Base Currency	Any Base Currency
AllRatesToday	Any currency	All plans
Open Exchange Rates	USD only	Developer plan ($12/mo)
Fixer.io	EUR only	Basic plan ($10/mo)
CurrencyAPI	USD only	Pro plan

The Easy Way: Use an API That Supports Any Base

With AllRatesToday, just change the source parameter:

# EUR as base
curl "https://allratestoday.com/api/v1/rates?source=EUR&target=GBP" \
  -H "Authorization: Bearer YOUR_API_KEY"

# INR as base
curl "https://allratestoday.com/api/v1/rates?source=INR&target=AUD" \
  -H "Authorization: Bearer YOUR_API_KEY"

This works on all plans, including the free tier.

The Manual Way: Cross-Rate Calculation

If you are stuck with a USD-locked API, you can calculate cross-rates yourself:

Cross-rate formula: A/B = USD_rate_B / USD_rate_A

Example: EUR to GBP

Given USD-based rates:

USD/EUR = 0.9234
USD/GBP = 0.7891

Cross-rate: EUR/GBP = 0.7891 / 0.9234 = 0.8546

So 1 EUR = 0.8546 GBP.

JavaScript Implementation

function crossRate(usdRates, from, to) {
  if (from === 'USD') return usdRates[to];
  if (to === 'USD') return 1 / usdRates[from];
  return usdRates[to] / usdRates[from];
}

const usdRates = {
  EUR: 0.9234,
  GBP: 0.7891,
  JPY: 151.42,
  INR: 83.45,
  AUD: 1.5312
};

console.log('EUR to GBP:', crossRate(usdRates, 'EUR', 'GBP'));  // 0.8546
console.log('GBP to JPY:', crossRate(usdRates, 'GBP', 'JPY'));  // 191.89
console.log('INR to AUD:', crossRate(usdRates, 'INR', 'AUD'));   // 0.01835

Python Implementation

def cross_rate(usd_rates: dict, source: str, target: str) -> float:
    """Calculate cross-rate from USD-based rates."""
    if source == "USD":
        return usd_rates[target]
    if target == "USD":
        return 1 / usd_rates[source]
    return usd_rates[target] / usd_rates[source]


usd_rates = {
    "EUR": 0.9234,
    "GBP": 0.7891,
    "JPY": 151.42,
    "INR": 83.45,
    "AUD": 1.5312,
}

print(f"EUR to GBP: {cross_rate(usd_rates, 'EUR', 'GBP'):.4f}")  # 0.8546
print(f"GBP to JPY: {cross_rate(usd_rates, 'GBP', 'JPY'):.2f}")  # 191.89

The Rounding Problem

// Wrong: floating-point precision issues
const amount = 1999.99;
const rate = 0.9234;
const result = amount * rate;  // 1846.7907659999998

// Right: round to the target currency's decimal places
function convertAmount(amount, rate, decimals = 2) {
  return Number((amount * rate).toFixed(decimals));
}

console.log(convertAmount(1999.99, 0.9234));      // 1846.79
console.log(convertAmount(1999.99, 151.42, 0));    // 302840 (JPY has 0 decimals)

Currency decimal places: Most currencies use 2 decimal places, but JPY, KRW, VND use 0. BHD, KWD, OMR use 3. Always round correctly for the target currency.

Using the AllRatesToday SDK

The SDK handles base currency and conversion in a single call:

import AllRatesToday from '@allratestoday/sdk';

const client = new AllRatesToday('YOUR_API_KEY');

// Direct conversion — any base currency, any target
const result = await client.convert('EUR', 'GBP', 5000);
console.log(`5,000 EUR = ${result.result} GBP`);

// Get rate for any pair directly
const rate = await client.getRate('INR', 'AUD');
console.log(`1 INR = ${rate} AUD`);

Summary

The base currency is the reference point for all rates in an API response.
Many free API plans lock you to USD — forcing manual cross-rate math.
Cross-rate formula: A/B = USD_rate_B / USD_rate_A
Always round to the correct decimal places for the target currency.
The easiest solution: use an API that supports any base currency on all plans.

AllRatesToday supports all 160+ currencies as the source — even on the free tier. No cross-rate workarounds needed.

Get your free API key | Documentation | GitHub

Brought to you by AllRatesToday — real-time and historical
exchange rates for 160+ currencies, plus official central-bank rates, built for developers.
Read the docs and register for free to get started.

All our tooling is open source — SDKs and MCP servers on GitHub.

How to Cache Exchange Rates and Avoid Rate Limit Errors

viraj geeth — Mon, 26 Oct 2026 21:38:37 +0000

You integrated an exchange rate API, deployed to production, and then hit HTTP 429: Rate limit exceeded. This is the most common operational issue developers face with exchange rate APIs — and it is entirely preventable with proper caching.

Why You Need to Cache Exchange Rates

Exchange rates don't change every millisecond. Even "real-time" APIs like AllRatesToday update every 60 seconds. Fetching the same rate on every page load is wasteful and will quickly exhaust your quota.

Consider a simple e-commerce site with 10,000 daily visitors:

Without caching: 10,000 API calls/day = 300,000/month. You'll need a Large plan.
With 5-minute cache: 288 API calls/day = 8,640/month. A Small plan covers it.
With 1-hour cache: 24 API calls/day = 720/month. A Small plan covers it with room to spare, and the free tier is enough to test with.

The math: If your API updates every 60 seconds, caching for 5 minutes means you are at most 4 minutes behind — which is perfectly acceptable for price displays and most applications.

Choosing Your Cache Duration (TTL)

Use Case	Recommended TTL	Why
Trading / Forex	No cache or 1–5s	Every second counts
Payment checkout	30–60 seconds	Rate should be current at time of charge
E-commerce price display	1–5 minutes	Visitors tolerate slight delays
Dashboard / analytics	5–15 minutes	Refresh rates match dashboard refresh
Invoicing / billing	1–24 hours	Rate is locked at invoice generation
Accounting reports	24 hours	End-of-day rates are standard

Strategy 1: Simple In-Memory Cache (JavaScript)

No dependencies needed:

import AllRatesToday from '@allratestoday/sdk';

const client = new AllRatesToday('YOUR_API_KEY');
const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function getRate(source, target) {
  const key = `${source}_${target}`;
  const cached = cache.get(key);

  if (cached && Date.now() - cached.timestamp < CACHE_TTL) {
    return cached.rate;
  }

  const rate = await client.getRate(source, target);
  cache.set(key, { rate, timestamp: Date.now() });
  return rate;
}

// Only hits the API once per 5 minutes per currency pair
const rate1 = await getRate('USD', 'EUR');  // API call
const rate2 = await getRate('USD', 'EUR');  // Served from cache

Strategy 2: Simple In-Memory Cache (Python)

import time
from allratestoday import AllRatesToday

client = AllRatesToday("YOUR_API_KEY")
_cache = {}
CACHE_TTL = 300  # 5 minutes

def get_rate(source: str, target: str) -> float:
    key = f"{source}_{target}"
    cached = _cache.get(key)

    if cached and time.time() - cached["timestamp"] < CACHE_TTL:
        return cached["rate"]

    rate = client.get_rate(source, target)
    _cache[key] = {"rate": rate, "timestamp": time.time()}
    return rate

Strategy 3: Stale-While-Revalidate

The best strategy for production. Serve cached (possibly stale) data immediately, refresh in the background. Users never wait for an API call.

import AllRatesToday from '@allratestoday/sdk';

const client = new AllRatesToday('YOUR_API_KEY');
const cache = new Map();
const FRESH_TTL = 60 * 1000;       // Fresh for 1 minute
const STALE_TTL = 10 * 60 * 1000;  // Serve stale up to 10 minutes
const refreshing = new Set();

async function getRate(source, target) {
  const key = `${source}_${target}`;
  const cached = cache.get(key);
  const now = Date.now();

  if (cached) {
    const age = now - cached.timestamp;

    if (age < FRESH_TTL) {
      return cached.rate; // Fresh
    }

    if (age < STALE_TTL) {
      // Stale but usable — refresh in background
      if (!refreshing.has(key)) {
        refreshing.add(key);
        client.getRate(source, target)
          .then(rate => cache.set(key, { rate, timestamp: Date.now() }))
          .finally(() => refreshing.delete(key));
      }
      return cached.rate;
    }
  }

  // No cache or expired
  const rate = await client.getRate(source, target);
  cache.set(key, { rate, timestamp: now });
  return rate;
}

Why this works: Exchange rates don't jump dramatically in 10 minutes. Serving a 5-minute-old rate instantly is better than making your user wait 200ms for a rate that's 0.01% more accurate.

Strategy 4: Redis Cache (High-Traffic Apps)

For multi-instance applications, use Redis to share a cache:

import AllRatesToday from '@allratestoday/sdk';
import Redis from 'ioredis';

const client = new AllRatesToday('YOUR_API_KEY');
const redis = new Redis(process.env.REDIS_URL);
const CACHE_TTL = 300; // 5 minutes

async function getRate(source, target) {
  const key = `exchange_rate:${source}:${target}`;

  const cached = await redis.get(key);
  if (cached) return parseFloat(cached);

  const rate = await client.getRate(source, target);
  await redis.setex(key, CACHE_TTL, rate.toString());
  return rate;
}

Strategy 5: Batch Prefetch

If you know which currencies you need, fetch them all on a schedule:

import AllRatesToday from '@allratestoday/sdk';

const client = new AllRatesToday('YOUR_API_KEY');
let ratesCache = {};

const CURRENCIES = ['EUR', 'GBP', 'JPY', 'CAD', 'AUD', 'CHF', 'INR'];

async function refreshAllRates() {
  try {
    const allRates = await client.getRates('USD');
    const rates = {};
    for (const currency of CURRENCIES) {
      rates[`USD_${currency}`] = allRates[currency];
    }
    rates.lastUpdated = Date.now();
    ratesCache = rates;
  } catch (err) {
    console.error('Refresh failed, keeping stale cache:', err.message);
  }
}

refreshAllRates();
setInterval(refreshAllRates, 5 * 60 * 1000);

// Synchronous access — no await needed
function getRate(source, target) {
  return ratesCache[`${source}_${target}`];
}

Request math: 1 API call per 5 minutes = 288 calls/day = 8,640/month. Serves unlimited concurrent users.

Common Mistakes to Avoid

Fetching on every request: The #1 cause of rate limit errors. Always cache.
Client-side API calls: Never expose your API key in frontend JavaScript. Fetch server-side and proxy.
Cache per user: Exchange rates are the same for everyone. Use a global cache.
Ignoring cache stampede: When cache expires, 100 concurrent requests all hit the API. Use stale-while-revalidate or a lock.

Security: Never call the exchange rate API directly from the browser. Your API key will be visible in the network tab. Always proxy through your backend.

Summary

Strategy	Best For	Complexity
Simple TTL cache	Small apps, single server	Low
Stale-while-revalidate	User-facing apps needing instant response	Medium
Redis cache	Multi-instance / high-traffic	Medium
Batch prefetch	Known currency set, predictable traffic	Low

AllRatesToday — 60-second updates, 160+ currencies, official SDKs. Start with the free tier, then pick a plan sized to your cache TTL.

Get your free API key | Documentation | GitHub

Written by the team behind AllRatesToday — an exchange rate API
with real-time mid-market rates for 160+ currencies and the official published tables of
116 central banks and tax authorities. The official-rate endpoint needs no key. Browse the
API docs or grab a free key
to start building.

Open source: official SDKs for JavaScript, Python, PHP, Go and Rust,
plus MCP servers (@allratestoday/mcp-server, @allratestoday/central-bank-mcp) and a hosted
MCP endpoint at https://allratestoday.com/api/mcp for AI agents.

Booking Xero Invoices at the Official Central Bank Rate (Xero Won't Let You Replace Its Feed, Here's the Workaround)

viraj geeth — Tue, 20 Oct 2026 13:58:45 +0000

Every few weeks someone asks how to make Xero use the Bank of England, ECB or RBI rate instead of the rate it downloads. The short answer: you cannot replace Xero's organisation-level feed. It comes from XE.com once multicurrency is enabled and there is no endpoint to change it.

What Xero does allow, in the UI and in the Accounting API, is a rate on each transaction. Invoices, bills, credit notes, bank transactions and manual journals all carry a CurrencyRate. A compliant workflow sets that field at creation time from the official table for the document date. The full guide is on AllRatesToday: Xero integration.

The rate Xero expects

CurrencyRate is document-currency units per 1 unit of the organisation base currency. For a GBP organisation raising a EUR invoice you need EUR per GBP. Ask the API for exactly that pair and let it handle inversion or crossing:

GET https://allratestoday.com/api/v1/central-bank/boe/latest?source=GBP&target=EUR
Authorization: Bearer art_live_your_key

{
  "bank": "boe",
  "rate_date": "2026-10-08",
  "source": "GBP",
  "target": "EUR",
  "rate": 1.18,
  "derived": false,
  "method": "published"
}

When the invoice is not dated today, use the dated endpoint /api/v1/central-bank/{bank}/{YYYY-MM-DD}. If the bank did not publish that day you get the prior table and published_on_requested_date: false, which is the rate in force and the one to apply.

Create the invoice with the official rate

Python with the xero-python SDK, after the usual OAuth 2.0 connection:

import requests
from xero_python.accounting import AccountingApi, Invoice, LineItem

BANK = "boe"                      # the publisher your rule names
BASE = "GBP"                      # Xero organisation base currency

def official_rate(target, on_date):
    url = f"https://allratestoday.com/api/v1/central-bank/{BANK}/{on_date}"
    r = requests.get(url, params={"source": BASE, "target": target},
                     headers={"Authorization": "Bearer art_live_your_key"}, timeout=10)
    r.raise_for_status()
    body = r.json()
    return body["rate"], body["rate_date"], body["derived"]

rate, rate_date, derived = official_rate("EUR", "2026-10-09")

invoice = Invoice(
    type="ACCREC",
    contact={"ContactID": contact_id},
    date="2026-10-09",
    due_date="2026-11-08",
    currency_code="EUR",
    currency_rate=rate,                          # EUR per 1 GBP, from the Bank of England table
    reference=f"BoE {rate_date}{' (derived)' if derived else ''}",
    line_items=[LineItem(description="Consulting", quantity=1, unit_amount=1000, account_code="200")],
)
AccountingApi(api_client).create_invoices(xero_tenant_id, invoices={"Invoices": [invoice]})

Writing the bank and rate_date into the reference, or a tracking category, keeps the source of the rate on the document for the auditor. The same field exists on BankTransactions, CreditNotes and ManualJournals.

Month-end revaluation

Xero's unrealised gains report uses its own closing rate. If your statutory close must use the central bank's month-end table, pull it once with /api/v1/central-bank/{bank}/{last-business-day} and post the revaluation as a manual journal at those rates. ?format=xlsx on the same endpoint gives the table as a spreadsheet if the close is done in Excel.

Notes

One API call per pair per date. A monthly batch of 200 invoices across five currencies is at most 5 calls a day if you cache per date.
Xero rounds CurrencyRate to six decimal places; official tables are published to four or five, so nothing is lost.
UK VAT uses HMRC's monthly table, which is a separate source on the same API.

The RBI Reference Rate in Python and Google Sheets, From One URL (No API Key)

viraj geeth — Mon, 19 Oct 2026 19:20:10 +0000

If you work with a finance team in India, someone copies the RBI reference rate into a spreadsheet every afternoon: USD/INR for export invoices, EUR and GBP for vendor payments, the month-end rate for book closing. This post replaces that with one URL.

Who publishes it

Since 10 July 2018 the reference rate has been computed and announced by Financial Benchmarks India Ltd (FBIL), once per Mumbai business day at about 13:30 IST. The RBI lists the same figures in its Reference Rate Archive, so the "RBI rate" and the "FBIL rate" are the same numbers. There is no rate on weekends or Mumbai bank holidays.

The URL

https://allratestoday.com/api/open/central-bank/rbi?format=csv

rate_date,base,quote,rate_type,value
2026-10-14,AED,INR,reference,25.8734
2026-10-14,EUR,INR,reference,106.5264
2026-10-14,GBP,INR,reference,126.0969
2026-10-14,IDR,INR,reference,0.00530858
2026-10-14,JPY,INR,reference,0.6003
2026-10-14,USD,INR,reference,95.0317

Six currencies against the rupee, with the publication date on every row. No key, no sign-up; it is free with a visible link back to the source. (JPY is per 1 yen. The RBI prints it per 100.)

Python

One pair as JSON, standard library only:

import json, urllib.request

url = "https://allratestoday.com/api/open/central-bank/rbi?source=USD&target=INR"
data = json.load(urllib.request.urlopen(url))
print(data["rate_date"], data["rate"])   # 2026-10-14 95.0317

The whole table with pandas:

import pandas as pd

df = pd.read_csv("https://allratestoday.com/api/open/central-bank/rbi?format=csv",
                 encoding="utf-8-sig")   # strips the BOM Excel needs
print(df[["rate_date", "base", "value"]])

Google Sheets

=VLOOKUP("USD", QUERY(IMPORTDATA("https://allratestoday.com/api/open/central-bank/rbi?format=csv"), "select Col2, Col5"), 2, FALSE)

Swap "USD" for "EUR", "GBP", "JPY", "AED" or "IDR". Keep the date next to it so every figure says which day's rate it is:

=INDEX(IMPORTDATA("https://allratestoday.com/api/open/central-bank/rbi?format=csv"), 2, 1)

Excel works too through Data → Get Data → From Web with the same URL; the full guide has the steps.

Past dates

The open URL always returns the latest table. For an invoice date, a month-end, or a series back to 2003 there are dated endpoints that need a free key. They are listed on the RBI exchange rate API page, and a holiday date returns the previous business day's rate labelled with its real publication date.

Pushing Official Central Bank Exchange Rates into QuickBooks Online (One POST per Currency per Day)

viraj geeth — Mon, 19 Oct 2026 19:20:09 +0000

Once multicurrency is on, QuickBooks Online downloads market rates automatically. It also lets you enter your own rate per currency per day, and that override is a first-class API object: ExchangeRate in the Accounting API, keyed by source currency and AsOfDate. Transactions dated that day pick the override up unless a rate was set on the transaction itself.

That means the whole "book at the central bank's rate" integration is one POST per currency per day. The full guide is on AllRatesToday: QuickBooks Online integration.

The rate QuickBooks expects

Rate is home-currency units per 1 unit of SourceCurrencyCode. For a USD company and EUR that is USD per EUR. Rather than working out whether the bank publishes that direction, ask the API for the pair directly. It inverts or crosses when needed and tells you:

GET https://allratestoday.com/api/v1/central-bank/ecb/latest?source=EUR&target=USD
Authorization: Bearer art_live_your_key

{ "bank": "ecb", "rate_date": "2026-10-09", "source": "EUR", "target": "USD",
  "rate": 1.1206, "derived": false, "method": "published" }

The daily sync

import requests

REALM = "1234567890"
QBO = f"https://quickbooks.api.intuit.com/v3/company/{REALM}"
QBO_H = {"Authorization": f"Bearer {qbo_access_token}", "Accept": "application/json"}
ART_H = {"Authorization": "Bearer art_live_your_key"}
BANK, HOME = "ecb", "USD"

# 1. currencies enabled in the company
q = requests.get(f"{QBO}/query", headers=QBO_H,
                 params={"query": "SELECT * FROM CompanyCurrency", "minorversion": 75}).json()
codes = [c["Code"] for c in q["QueryResponse"].get("CompanyCurrency", [])]

# 2. one official rate per currency, home units per 1 foreign unit
for code in codes:
    r = requests.get(f"https://allratestoday.com/api/v1/central-bank/{BANK}/latest",
                     params={"source": code, "target": HOME}, headers=ART_H, timeout=10)
    if r.status_code == 404:          # bank does not cover this currency
        continue
    body = r.json()
    payload = {"SourceCurrencyCode": code, "AsOfDate": body["rate_date"], "Rate": body["rate"]}
    requests.post(f"{QBO}/exchangerate", headers=QBO_H, params={"minorversion": 75}, json=payload).raise_for_status()
    print(code, body["rate_date"], body["rate"], "derived" if body["derived"] else "published")

Run it after the bank's publication time each business day. Re-posting the same currency and date updates the rate in place, so a rerun is safe, and a bank that amends its table (it happens) is handled by simply running again.

Three things to know

Pairs are always foreign to home in QuickBooks. There is no cross-pair table to maintain.
US companies often need the US Treasury quarterly table rather than a daily central-bank rate. Same loop, different bank code, quarterly schedule.
Per-transaction override is still available. If only some documents need the official rate, set ExchangeRate on the invoice or bill body instead of the company table. Same meaning: home units per 1 unit of document currency.

Try it without a key

https://allratestoday.com/api/open/central-bank/ecb returns the latest ECB table keyless, so you can see what the bank covers before you sign up. The keyed endpoint adds the pair resolution and dated history.

Loading Official Central Bank Exchange Rates into Odoo (res.currency.rate, the Right Direction)

viraj geeth — Fri, 16 Oct 2026 13:38:06 +0000

Odoo's Automatic Currency Rates setting (module currency_rate_live) pulls from a fixed list of providers: the ECB, the Swiss FTA, the Bank of Canada, Banxico and a few more. If the central bank your statutory accounts must follow is on that list, use it and stop reading.

If it is not, or you run subsidiaries under several central banks and want one feed, you write the rows yourself. The good news is that res.currency.rate is one of the most stable models in Odoo and the loader is short. The full version with notes is in the Odoo guide.

The rate Odoo stores

res.currency.rate.rate is units of the foreign currency per 1 unit of the company currency. For a EUR company and USD that is USD per EUR, which is the ECB's own direction, so nothing to invert.

For an INR company following the Reserve Bank of India, which publishes INR per USD, you need the inverse. Do not divide in your own code. Ask the API for the pair in Odoo's direction and let it invert, flagging what it did:

GET https://allratestoday.com/api/v1/central-bank/rbi/latest?source=INR&target=USD

{ "bank": "rbi", "rate_date": "2026-10-09", "source": "INR", "target": "USD",
  "rate": 0.01035, "derived": true, "method": "inverse" }

derived: true with method: "inverse" is the line you want in your audit file. When the bank publishes the pair directly you get derived: false, method: "published".

The loader

import xmlrpc.client, requests

URL, DB, USER, PWD = "https://erp.example.com", "prod", "bot@example.com", "api-key"
BANK = "ecb"
ART = {"Authorization": "Bearer art_live_your_key"}

common = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/common")
uid = common.authenticate(DB, USER, PWD, {})
models = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/object")
call = lambda model, method, *args, **kw: models.execute_kw(DB, uid, PWD, model, method, list(args), kw)

company = call("res.company", "read", [1], fields=["currency_id"])[0]
home = call("res.currency", "read", [company["currency_id"][0]], fields=["name"])[0]["name"]
active = {c["name"]: c["id"] for c in call("res.currency", "search_read", [["active", "=", True]], fields=["name"])}

for code, currency_id in active.items():
    if code == home:
        continue
    r = requests.get(f"https://allratestoday.com/api/v1/central-bank/{BANK}/latest",
                     params={"source": home, "target": code}, headers=ART, timeout=10)
    if r.status_code == 404:
        continue                                   # bank does not publish this currency
    body = r.json()
    vals = {"currency_id": currency_id, "name": body["rate_date"], "rate": body["rate"], "company_id": 1}
    existing = call("res.currency.rate", "search",
                    [["currency_id", "=", currency_id], ["name", "=", body["rate_date"]], ["company_id", "=", 1]])
    if existing:
        call("res.currency.rate", "write", existing, vals)
    else:
        call("res.currency.rate", "create", vals)
    print(code, body["rate_date"], body["rate"], body["method"])

Three details that bite people:

name is the effective date, not the run date. Always use the bank's rate_date. If you run the loader on a Monday for a bank that publishes on business days, you get Friday's table dated Friday, which is correct.
Multi-company: run the loop per company with that company's home currency, and per bank code if the subsidiaries sit under different central banks.
Month-end sources such as HMRC's monthly table or a monthly-average publisher load the same way on a monthly cron.

Run it inside Odoo

Put the loop in a small custom module and register an ir.cron that runs daily after the bank's publication time. Inside Odoo the same logic uses self.env['res.currency.rate'] and requests, with the API key in an ir.config_parameter rather than in the code. An inverse_company_rate field also exists from Odoo 14; writing either field is fine, but be consistent so reruns update rather than fight.

Try it without a key

https://allratestoday.com/api/open/central-bank/ecb returns the latest ECB table keyless, so you can prototype the loader before signing up.