Currency API for travel and booking apps

Travelers think in their home currency. A hotel at 3,200,000 IDR, a ferry at 85 EUR and a tour at 1,400 MXN only become comparable once they are converted. A currency API for travel gives booking sites, OTAs, tour operators and travel apps the exchange rates to do that conversion – for fares, budgets and on-trip spending. fxapi covers 190+ currencies with any currency as the base, so the same integration works for travelers from Oslo, Seoul or São Paulo.

Where travel products need exchange rates

• Multi-currency fares and rates. Suppliers quote in their own currency; travelers want to see the price in theirs. Many booking flows show both: “MXN 1,400 (about USD 78)”.
• Trip budget tools. Travelers set a budget in their home currency and log expenses in local currency. The app converts every entry to show what’s left.
• On-trip converters. A quick “how much is this?” calculator – often used where roaming is expensive or the connection is poor.
• Group expense splitting. Shared costs paid in several currencies need a common currency to settle up.
• Destination content. Showing the local currency, its symbol and typical decimals on destination pages.

Why coverage matters for a currency API for travel

Mainstream pairs are easy. Travel goes further: Cabo Verde, Mauritania, São Tomé, Sierra Leone, Zimbabwe, the Caribbean. fxapi includes 160 active ISO 4217 fiat currencies plus current codes such as MRU, STN, SLE, ZWG and XCG, alongside legacy codes like HRK kept for history. If your app has old trips stored in a retired currency, those still convert. Background reading: ISO 4217 currency codes and currency redenominations and code changes.

Daily rates on the Free plan are often enough for budget tools. Booking sites showing fares alongside live availability typically choose Basic (hourly) or Professional (every 60 seconds). See pricing.

Architecture: offline-ready rates for mobile apps

The key rule: the API key stays on your server. A mobile app bundle can be unpacked, and a key found there can be used by anyone.

1. Backend job. Every hour (or at your plan’s cadence), call /v1/latest once with a single base such as USD and all currencies.
2. Build a snapshot. Keep only what the app needs: code, value, plus last_updated_at. Add display metadata from /v1/currencies (symbol, decimals) once a week.
3. Publish it. Write the snapshot to object storage behind a CDN, or serve it from your API with cache headers.
4. App sync. The app downloads the snapshot when online, stores it locally (SQLite, Room, Core Data or a file) and records when it was fetched.
5. Convert locally. With a USD-based snapshot, any pair is a cross rate: amount × rate[to] / rate[from].
6. Show freshness. Display “Rates as of 8 Oct, 09:00 UTC” and warn when the snapshot is older than a threshold.

This pattern keeps one API request serving every user, so even large apps use few requests. More on cache design in caching exchange rates.

Code example: snapshot job in Ruby

Plain net/http with the key in the apikey header:

require "net/http"
require "json"
require "time"

uri = URI("https://api.fxapi.com/v1/latest")
uri.query = URI.encode_www_form(base_currency: "USD", type: "fiat")

req = Net::HTTP::Get.new(uri)
req["apikey"] = ENV.fetch("FXAPI_KEY")

res = Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| http.request(req) }
raise "fxapi error #{res.code}" unless res.is_a?(Net::HTTPSuccess)

body = JSON.parse(res.body)
snapshot = {
  base: "USD",
  updated_at: body.dig("meta", "last_updated_at"),
  generated_at: Time.now.utc.iso8601,
  rates: body["data"].transform_values { |r| r["value"] }
}

File.write("public/rates.json", JSON.generate(snapshot)) # upload to your CDN

The resulting file is small enough to ship on every app launch:

{
  "base": "USD",
  "updated_at": "2026-10-08T09:00:00Z",
  "rates": { "EUR": 0.92, "IDR": 16400, "MXN": 18.1, "CVE": 101.5 }
}

Values are illustrative. To convert 1,400 MXN to EUR on the device: 1400 × 0.92 / 18.1 ≈ 71.16 EUR. See the Ruby guide for more.

Choosing a refresh cadence

Because one snapshot serves every user, request volume depends on your refresh cadence, not on how many travelers open the app.

Pitfalls and best practices

• Label conversions as approximate. Mid-market rates differ from what a card network or exchange office charges. “About €71” is honest; “€71.16” implies a precision the traveler won’t see on their statement.
• Format by currency. Use decimal_digits and symbol_native from /v1/currencies – IDR and JPY have no minor units in everyday use, while KWD and BHD use three decimals.
• Use the expense date for past entries. When a traveler logs yesterday’s dinner, convert at the historical rate for that day so the budget doesn’t drift.
• Never bundle the key. Serve snapshots from your backend or CDN only.
• Plan for stale data. If the app has been offline for a week, convert anyway but show the snapshot date clearly.
• Map countries to currencies with data, not assumptions. The countries field avoids hard-coded lists that go out of date.

Give travelers prices they understand

Start with the Free plan’s daily rates for budget tools and offline converters, then move to hourly or 60-second updates when fares need to track the market. Look at the currency converter API for one-off conversions, or create a free API key and publish your first rate snapshot today.

Everything on this page runs on the fxapi foreign exchange rates API: one key, 190+ currencies, data back to 1999.

Frequently asked questions