Skip to main content
A destination explorer lets visitors browse every hotel in your portfolio with a “from” price per property. The Best Price Hotels (Arrivals) endpoint returns per-hotel pricing across your date window in a single call.

Prerequisites

Before building a destination explorer, make sure you have:
  • A working Best Price call. If not, follow the Quick start first.
  • A group ID covering the hotels you want to display.
  • A target date window (typically 30 to 90 days).

How it works

The Hotels (Arrivals) endpoint returns one entry per hotel and requested strategy, with the best price found over your date window and the arrival date it applies to. With a single call and a single strategy in behaviours (LowestLengthOfStay when you send none), you get one “from” price per hotel in the group, with no aggregation on your side. A hotel with no bookable offer in the window comes back with status: NotAvailable. Keep only the entries whose status is Available or OnRequest; a hotel without one has nothing to display.

Build the explorer

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

Call Best Price Hotels (Arrivals) once

Send one request to /BestPrice/Hotels/Arrivals with your date range, group ID, and party. The response is an array with one entry per hotel.
2

Index the bookable entries by hotel

With a single strategy in behaviours, each hotel appears once, with its best totalPrice over the window and the arrivalDate it applies to. Keep the entries whose status is Available or OnRequest, and key them by hotelId to look up each hotel’s “from” price and currency.
3

Render the property cards

Display each hotel with its “from” price, photo, location, and a CTA. For hotels with no bookable entry in the response, show a soft fallback rather than a hard “Sold out”, since availability changes throughout the day.

Tips

  • Cache aggressively. One call per (date range, party, group) combination. Easy cache key, big payoff for landing pages that get heavy browse traffic.
  • Use a tight date window. 30 days is usually enough for an explorer page. A 90-day window costs more per call without changing the “from” price most of the time.
  • Consider behaviours: ["EarliestAvailability"]. The default LowestLengthOfStay favours the shortest stay that clears the restrictions, and CheapestStay favours the lowest price. Switch to EarliestAvailability if your UI promises “earliest dates first”: useful for last-minute or “next weekend” widgets. Keep a single value in behaviours: list several only to replace separate calls you would otherwise make, since each extra strategy slows the call. The single behaviour property is deprecated.
  • Scope by sub-region with filter.hotels. If your group is large and your visitor is browsing a specific destination, filter the response to those hotels only with filter.hotels.default: "Excluded" and exceptions: [hotelId, ...]. Same allow-list pattern as the rooms filter.

Reference

Full schema for the Hotels (Arrivals) endpoint.

Best practices

Caching, performance, and resilience patterns.