Best practices

Apply these tips to keep your Daily Rates calls fast, accurate, and resilient.

​

When to use Daily Rates

Daily Rates is built for systems that store rates internally, run on a schedule, and need every day of a window in one call. It shines for use cases like nightly rate refreshes or revenue manager dashboards. Two signals tell you Daily Rates is the wrong fit:

• You only need a single arrival date: the Best Price API is the right tool for “from” prices and pricing surfaces.
• You need a booking-ready quote for a specific stay: the Quotation API returns the full pricing detail for the offer the visitor has chosen.

Daily Rates earns its weight when you need every day in the window.

​

Caching

Cache responses where you can. Each cached call lands faster on your downstream system and removes one round trip from your pipeline. Daily Rates data changes with inventory and pricing rules, so pick a TTL that fits your use case:

• Sync pipelines: cache between scheduled refreshes. The TTL is your refresh interval.
• Back-office calendars: cache for several minutes; revenue managers browse many dates at a glance.
• Investigation tools: refresh on demand, accuracy is the value.

When you cache, key on the full request body, not only the date range. A different layout or filter is a different result.

​

Performance

​

Trim your layout

The layout field controls what the API computes. Every property you list adds work on the D-EDGE side. Request only the properties you actually consume. A pipeline that only stores availability does not need pricing or restrictions in its layout.

​

Specify currencies explicitly

Always provide a currencies filter in your request. Letting the API infer one adds a small overhead.

​

Filter narrowly

Scope each query as narrowly as possible: limit ratePlans to the rates you care about, restrict rooms if you only sync a subset, and leave out costly properties such as AlternativeAvailableGuests unless your downstream really needs them. Keep Occupancies in every layout: it is what returns entities for hotels that price by occupancy. The more precise your filters, the faster the response.

​

Cap the date range

Daily Rates is designed for windows, but very long windows are slow and rarely useful: rates and availability evolve, so a snapshot 365 days out drifts before your next sync. Pick the smallest window your use case needs and refresh more often if you need a longer horizon.

​

Spread out your traffic over time

Smooth traffic shapes behave more predictably. Stagger scheduled syncs across hotels with a random offset rather than firing every property at the same minute. If you batch-refresh many hotels nightly, walk through them in groups instead of opening hundreds of parallel connections.

​

Accuracy

​

Read temporal segments correctly

Most fields in the response are returned as a list of { value, start, end } segments. A single segment covers the full window when nothing changes in that field. Multiple segments mark the days where the value changes, and end is exclusive: it is the first day the value no longer covers, so consecutive segments share their boundary date. Always iterate through every segment when reconstructing the day-by-day picture, do not assume a single segment, and stop each expansion before end.

​

Re-sync after pricing rule changes

If a hotel updates its rate plans, restrictions, or promotional rules, cached data goes stale immediately, even within your TTL. Provide a manual or webhook-driven refresh path so revenue managers can force an out-of-cycle sync rather than waiting for the next scheduled job.

​

Resilience

​

Retry on transient errors

Transient errors like network blips, timeouts, or occasional 5xx should be retried with exponential backoff. Avoid retrying on 400, 401, or 403. Those need code or credential fixes before they resolve.

​

Plan for partial sync failures

A nightly sync that touches many hotels will eventually fail on one of them. Design your pipeline so that a single hotel failure does not roll back the whole batch: log the failure, keep the previous data for that hotel, and retry on the next cycle. Alert if the same hotel fails several cycles in a row.

​

Tell us before a major launch

If you are onboarding a large new portfolio or running a one-off backfill that will 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 a traceId value, capture it in your logs. It lets the partnership team correlate your error reports with D-EDGE’s internal traces.