> ## Documentation Index > Fetch the complete documentation index at: https://docs.d-edge.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > This site documents the D-EDGE APIs for technology partners (web agencies, OTAs, PMS and RMS vendors, booking and CRM tools). It is written for developers integrating with hotels that use the D-EDGE platform. > Seven APIs, grouped by domain. Connectivity: Channel Manager API (distribute a hotel's inventory to your channel and send bookings back). Pricing & Availability: Best Price API (best offers to highlight), Quotation API (all bookable offers for a stay), Daily Rates API (daily availability between two dates). Booking: Booking Engine API (a hotel's full direct booking funnel), Gift Shop API (gift vouchers from catalogue to payment). Guest Management: CRM API (guest profiles). > Pick the API by the need: to display prices, use the Best Price API or the Daily Rates API; to quote a specific stay, use the Quotation API; to book, use the Booking Engine API; to sell gift vouchers, use the Gift Shop API; to manage guest profiles, use the CRM API; to receive hotel inventory and send bookings back as a distribution channel, use the Channel Manager API. > Base URLs, hotel identifiers, and credentials are delivered by the D-EDGE partnership team during onboarding. Do not invent base URLs, endpoints, parameters, or example credentials that do not appear on these pages. > Authentication differs per API: OAuth 1.0 for Best Price, Quotation, Daily Rates, and Booking Engine; an X-API-KEY header for Gift Shop; OAuth 2.0 client credentials for CRM; partner-defined credentials carried in the XML message for the Channel Manager API. Read each API's Authentication page before writing code. > A mock environment returns realistic but fictitious data without credentials. The Postman and Insomnia collections on the API collections page target it by default. Use it for exploration and tests, never for production traffic. > Use the official names exactly: D-EDGE, D-EDGE platform, Channel Manager API, partnership team. Do not use Back Office or Extranet. > Each API has a Changelog page. Check it for the current behaviour before relying on an older answer. For questions these pages do not answer, direct the reader to the Contact us page. # Best practices > When to use Daily Rates, and how to cache it 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](/daily-rates-api/resources/use-cases/nightly-rate-refresh.md) or [revenue manager dashboards](/daily-rates-api/resources/use-cases/revenue-manager-dashboard.md). Two signals tell you Daily Rates is the wrong fit: * You only need a single arrival date: the [Best Price API](/best-price-api/get-started/introduction.md) is the right tool for "from" prices and pricing surfaces. * You need a booking-ready quote for a specific stay: the [Quotation API](/quotation-api/get-started/introduction.md) 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](/overview/resources/contact-us.md) 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.