Pick the right endpoint
Different Best Price endpoints are tuned for different shapes of question. Picking the right one upfront keeps your code simple and your call volume low.- Calendar: best price for each arrival date in a range, for one hotel. For example, date pickers or price calendars.
- Rates: best price per rate plan, for one hotel. For example, rate plan comparisons or member rate showcases.
- Rooms: best price per room type, for one hotel. For example, room cards on a listing or a room-type comparison view.
- Hotels (Arrivals): best price per hotel over a date range, across multiple hotels. For example, destination explorers or chain landing pages.
- Hotels (Stays): best price across multiple hotels for a specific stay (arrival date plus night count). For example, last-minute deal widgets or “this weekend” chain searches.
Caching
Cache responses where you can. Each cached call lands faster on your user’s screen and removes one round trip from the critical path. Best Price data changes with inventory and pricing rules, so pick a TTL that fits your use case:- Calendar views: cache for several minutes; users browse many dates at a glance.
- Room listing pages: a short cache works well for catalogue browsing.
- Comparison interfaces: refresh often, accuracy is the value.
Performance
Specify a currency explicitly
Always provide a currency in your request. Letting the API infer one adds a small overhead.Limit the maximum length of stay
Cap the requested stay to what your use case actually needs. Shorter values reduce processing time.Filter narrowly
Scope each query as narrowly as possible. The more precise your filters, the faster the response.Spread out your traffic over time
Smooth traffic shapes behave more predictably. Stagger scheduled jobs with a random offset, debounce client-driven calls, and rely on caching for concurrent visitors.Accuracy
Choose the right strategy for restrictions
When restrictions apply, the API can prioritise the shortest stay, the cheapest stay, or the earliest availability. On Rates, Rooms, and Hotels (Arrivals), set the strategy inbehaviours. In most cases, send a single value. Each extra strategy adds one entry per rate, room, or hotel to the response and slows the call, for little real-life gain. List several strategies only when they replace separate calls you would otherwise make. Each entry carries the strategy it was computed for in behaviour. The single behaviour property is deprecated on these endpoints and can’t be combined with behaviours. Calendar keeps a single behaviour and offers the first two strategies. Hotels (Stays) has no strategy, since the stay is fixed by arrivalDate and nightCount. Pick the strategy that matches your guest’s intent. See the Reference for available values.
Resilience
Retry on transient errors
Transient errors like network blips, timeouts, or occasional5xx should be retried with exponential backoff. Avoid retrying on 400, 401, or 403. Those need code or credential fixes before they resolve.
Plan for slow or unreachable calls
Decide upfront how long your interface is willing to wait for a Best Price response, and what it shows past that point. Some teams display the last cached price, others hide the price block entirely and let users keep browsing. Make the choice deliberately rather than letting the network decide.Tell us before a major launch
If you are rolling out a TV spot, a flash sale, or any event likely to multiply your normal call volume by ten or more, contact us a few days ahead. We will watch the launch window with you and flag anything unusual the moment it appears.Log the traceId
When an error response includes atraceId value, capture it in your logs. It lets the partnership team correlate your error reports with D-EDGE’s internal traces.