Flutterwave update to Transfers Rates API goes into effect on 8th April

If you’ve built a payment integration on top of Flutterwave’s Transfer Rates API, there’s a quiet but potentially breaking change coming your way in less than a week. On Wednesday, 8^th April, 2026, Flutterwave is updating the way the rate field expresses exchange rates in the API response — and depending on how your code uses that value, it could silently produce wrong transaction amounts if you don’t act.

Here’s a breakdown of what’s changing, why it matters, and what you should actually do about it.

The rate field is getting inverted

Right now, when you call GET /v3/transfers/rates, the rate field in the response tells you how much source currency is required to deliver one unit of the destination currency. So if you’re sending NGN to someone who receives USD, you’d get back something like 1417.80 — meaning it costs 1,417.80 NGN to produce 1 USD.

After April 8, the same field flips: it will tell you how much destination currency you receive for one unit of source currency. For that same NGN → USD pair, you’d now see 0.0007 — meaning 1 NGN gets you 0.0007 USD.

“The underlying exchange rate is the same. What’s changing is the direction it’s expressed in — the same number, seen from the other side of the transaction.”

This is a directional convention flip, not a data error or a rate change. Think of it like the difference between “it costs £1.27 to buy a dollar” vs. “a dollar buys you £0.79” — both describe the same rate, just from opposite perspectives.

What the before and after actually looks like

Notice that the two rows are essentially swapping values. That’s a useful intuition check — after the change, you’ll see the large number on the USD → NGN row and the small decimal on NGN → USD, which is the more familiar mental model for most developers.

Should you be worried?

That depends entirely on how your code uses the rate field. There are really two scenarios:

Scenario A — You’re using source.amount and destination.amount directly.

If this is you, stop reading and go back to whatever you were doing. Those fields return the pre-calculated exact amounts for your specific transaction and are completely unaffected by this change. Flutterwave isn’t touching them.

Scenario B — You’re pulling the rate value and doing your own arithmetic with it.

This is where you need to pay attention. Under the old format, you’d calculate a destination amount by dividing the source amount by the rate. Under the new format, you’d multiply instead. If your code doesn’t change, it will silently produce incorrect amounts after April 8.

If you divide by the rate field, you need to act before April 8

Update your calculation from amount / rate to amount × rate, or better yet, migrate to using source.amount and destination.amount directly. The latter is the safer long-term approach.

What the code change looks like

If you’re in Scenario B and need to patch your integration quickly, the fix is a one-line change:

Before — old format (dividing)JavaScript

// rate = 1417.80 (NGN → USD, old convention)
const destinationAmount = sourceAmount / rate;
// 100,000 / 1417.80 → ~70.54 USD ✓ (old)

After — new format (multiplying)JavaScript

// rate = 0.0007 (NGN → USD, new convention)
const destinationAmount = sourceAmount * rate;
// 100,000 × 0.0007 → ~70 USD ✓ (new)

The better fix: stop using the rate field for calculations

Flutterwave isn’t just asking you to flip a division into a multiplication — they’re actually recommending you move away from the rate field entirely for any amount calculation. And that’s good advice.

The rate field is inherently a derived, display-oriented value. It can change format, convention, or precision in future updates (as it just did). The source.amount and destination.amount fields, on the other hand, are the exact calculated values for your specific transaction — no arithmetic needed on your end, and no dependency on how the rate happens to be expressed at any given time.

Recommended — use source/destination amounts directlyJavaScript

const res = await fetch(
  'https://api.flutterwave.com/v3/transfers/rates' +
  '?amount=1000&source_currency=NGN&destination_currency=USD',
  { headers: { Authorization: `Bearer ${SECRET_KEY}` } }
);
const { data } = await res.json();
// Use these — no manual calculation needed
data.source.amount       // exact NGN to debit
data.destination.amount  // exact USD received
// Avoid depending on this for arithmetic
// data.rate  ← display only

No changes needed if you already use source.amount / destination.amount

These fields are stable, exact, and unaffected by this update. If your integration is already built around them, you’re set.

Why is Flutterwave making this change?

The new convention — destination units per source unit — is the more widely-used standard across financial data APIs and FX tooling. It’s the format you’ll recognise from most forex feeds, banking APIs, and currency widgets: “1 USD = 1,417.80 NGN” rather than “1,417.80 NGN buys 1 USD.” By aligning to this standard, Flutterwave makes the rate field more intuitive and consistent with how developers typically think about exchange rates when working across multiple providers.

Test against the sandbox before April 8

You can validate your updated logic today using the sandbox base URL: https://developersandbox-api.flutterwave.com/transfers/rates. The new rate format is already live there.

The rate field in the Transfer Rates API response is inverting on April 8. If you do custom math with it, flip your division to multiplication — or, better, migrate to using source.amount and destination.amount instead. If you already use those fields, nothing changes for you. Either way, test in sandbox before the 8th if you can.

More Information ℹ

• Flutterwave