> ## 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 > Pick the right endpoint, then cache what it returns Apply these tips to keep your Best Price calls fast, accurate, and resilient. ## 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](/best-price-api/resources/use-cases/dynamic-price-calendar.md). * **Rates**: best price per rate plan, for one hotel. For example, rate plan comparisons or [member rate showcases](/best-price-api/resources/use-cases/member-rate-showcase.md). * **Rooms**: best price per room type, for one hotel. For example, [room cards on a listing](/best-price-api/resources/use-cases/best-rate-per-room-type.md) or a room-type comparison view. * **Hotels (Arrivals)**: best price per hotel over a date range, across multiple hotels. For example, [destination explorers](/best-price-api/resources/use-cases/hotels-destination-explorer.md) 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. Mismatching the endpoint to the use case usually means making N calls when one would do, or aggregating client-side what the API would have aggregated for you. ## 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 in `behaviours`. 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](/best-price-api/build/reference/calendar.md) for available values. ## 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 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](/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.