Skip to main content
A currency switcher lets guests browse prices in a currency they know, even when the property sells in another one. The Best Price API returns prices in the property’s currency and does not convert them, so the conversion layer belongs to your interface. This page shows how to build it.

Prerequisites

Before building the conversion layer, make sure you have:
  • A working Best Price call. If not, follow the Quick start first.
  • A hotel ID and a group ID for the property you display.
  • A public source of daily exchange rates. The European Central Bank reference rates are free, published every working day, and cover the main currencies.

How it works

The API returns every offer in the currency the property sells in. filter.currency selects, it does not convert: when a property sells in several currencies, the filter picks which one you receive. Requesting a currency the property does not sell in returns an empty response, not converted prices.
A guest browsing in EUR on a GBP-only property sees an empty calendar if you pass the guest’s currency to the API. Keep the API currency and the display currency as two separate settings.
The pattern is one call in the property’s currency, a daily exchange rate feed on the side, and a conversion at display time. The converted amount is indicative: the booking and the payment always happen in the property’s currency.

Build the conversion layer

The examples below assume the OAuth signing setup from the Quick start.
1

Request prices in the property's currency

Set filter.currency to the currency the property sells in. If you do not know it yet, omit the filter on the first call, at a small performance cost: the service then uses the property’s most used currency, and every response entry carries its currency.
2

Fetch the daily exchange rates

Load the reference rates once a day from your source and cache them. The examples below parse the ECB daily feed into a map of units per euro, with EUR as the pivot.
3

Convert at display time

Convert each price from the currency carried by the response entry to the currency the guest picked, then round for display. Always convert from the exact amount the API returned, and keep that amount untouched for the booking hand-off.
4

Let the guest switch currency

A currency switch is a re-render, not a new API call. The response you already hold is in the property’s currency, so apply the new target currency to the same data. Reserve new calls for changes that affect the offer itself: dates, party, or filters.At the point where the guest commits, show the price in the property’s currency as well, since that is the amount they will pay. A short mention such as “You will be charged in GBP” avoids surprises in the booking funnel.

Tips

  • Keep two currency settings. The API currency belongs to the property, the display currency belongs to the guest. Sending the guest’s currency in filter.currency returns an empty response whenever the property does not sell in it, and the guest sees an empty calendar.
  • Refresh the rates once a day. Align the refresh with your source’s publication time (the ECB publishes around 16:00 CET on working days; weekends keep Friday’s rates). Cache the map so a source outage never blanks your prices.
  • Say the amount is approximate. The ≈ sign or a footnote is enough. Daily reference rates differ slightly from the rate the guest’s bank applies, and the payment is taken in the property’s currency.
  • Mind multi-currency properties. When a property sells in more than one currency, filter.currency picks which one you receive. Pick one and keep it stable, so your cache and your conversions stay consistent.

Dynamic price calendar

The browse experience this conversion layer usually plugs into.

Best practices

Caching, performance, and resilience patterns.