Skip to main content
A nightly rate refresh pulls daily availability and prices into a partner-side database on a schedule, so downstream search and booking interfaces can serve their own visitors without round-tripping to D-EDGE on every query. One Daily Rates call per hotel per refresh covers the full window.

Prerequisites

Before building the refresh job, make sure you have:
  • A working Daily Rates call. If not, follow the Quick start first.
  • A hotel ID and a group ID for each property you sync.
  • A target window (typically 90 days for a single daily refresh; longer when you split the cadence, see Tips).
  • A storage layer keyed by (hotelId, roomId, rateId, date).

How it works

The Per day endpoint returns availability, prices, and restrictions for every day in your window, grouped by rate plan, hotel, and entity. Each entity is one room and rate combination, with daily fields encoded as { value, start, end } segments, where end is exclusive (consecutive segments share their boundary date). A single call covers the whole window. For a refresh job, the response shape works in your favour: segments compress consecutive days where the value does not change, so most entities collapse to a few rows even over long windows. Expand each segment to one row per day before writing to storage, or store the segments as-is if your downstream queries are range-aware.

Build the refresh

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

Fetch the window for one hotel

Send one request to /DailyRates/PerDay per hotel, with the date window you sync and a layout listing the properties you store. Start minimal: extra properties cost time on every refresh, so add new ones only when downstream features actually need them.
2

Expand temporal segments into daily rows

Walk every entity in the response, then expand each { value, start, end } segment into one record per day. Group by (hotelId, roomId, rateId, date) so your storage stays keyed at the day level.
3

Upsert into your storage

Write the expanded rows into your database, keyed by (hotelId, roomId, rateId, date). Treat each refresh as the new source of truth: rows that were present last cycle but absent this cycle should either be deleted or marked as inactive, depending on your downstream semantics.Wrap each hotel’s upsert in a transaction so a partial write does not leave a torn state if the refresh crashes mid-hotel.
4

Schedule the refresh

Run the refresh on a cadence that matches your downstream’s freshness requirement. Nightly during off-peak hours is the common baseline; the Tips below cover when to split the cadence into near-term and far-term cycles. Stagger hotels across the window with a random offset rather than firing every property at the same minute.Surface a manual trigger in your back office so revenue managers can force an out-of-cycle sync after a pricing rule change, instead of waiting for the next scheduled run.

Tips

  • Keep the previous snapshot on failure. If a refresh fails for one hotel, do not wipe its previous data: serve stale rather than empty. Alert if the same hotel fails several cycles in a row.
  • Watch for rate plan churn. A rate plan that disappears between refreshes means either a real configuration change or a transient filter mismatch. Deleting old rows immediately can mask the difference. Mark them inactive first and clean up after a grace period.
  • Right-size the window and the cadence. Long windows are slow to pull, and rates 6 to 12 months out barely move between cycles. Pulling the full horizon every night wastes traffic. 90 days, refreshed daily, is a comfortable starting point. To cover further out, split the refresh into a frequent near-term cycle (next 90 days, several times a day) and a slower far-term one (the rest, daily or weekly is usually enough).

Reference

Full schema for the Per day endpoint.

Best practices

Caching, performance, and resilience patterns.