> ## 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 > Session lifecycle and funnel integrity The Booking Engine API drives a stateful, multi-step funnel. These patterns keep that funnel fast, accurate, and resilient, from the first search to a confirmed booking. ## Session lifecycle ### Reuse one session across the funnel Open a session once, then carry its `sessionId` through search, basket, quote, and confirmation. Do not open a new session per call. Refine the existing session with the `PATCH` endpoints (context, filters, display, and sort order) as the guest narrows their choice. ### Match the session duration to the journey A session has a limited lifetime. Set a duration that fits your funnel with the `X-AVP-SessionDuration` header when you create the session: long enough for a guest to browse and check out without losing their basket, short enough to release stale state. ### Recover from an expired session When a call returns `400` with `Code: InvalidSessionId`, treat the session as gone. Create a fresh one, replay the guest's context, and rebuild the basket. Build this recovery path in from the start rather than assuming sessions last forever. ## Funnel integrity ### Follow the funnel order Read availability before building the basket, and quote the basket before confirming. Skipping a step can surface stale prices or let a guest reach checkout on an offer that is no longer available. ### Re-quote right before confirmation Prices and availability shift while a guest fills in their details, through inventory changes, currency, or tax updates. Call **Get a quote** again immediately before you accept the quote, and surface any change before taking payment. This is the single most effective way to avoid the price mismatches that drive booking disputes. ### Read the sales terms from the API Fetch the sales terms through **Get sales terms** rather than hardcoding them. A property can override the default terms in its booking engine configuration, so the value returned by the API is the only reliable one. ### Hand off payment to D-EDGE Payment is hosted and handled by D-EDGE, so you never touch card details. Accepting the quote returns a `redirectionUrl`: send the guest there to pay, then bring them back to a confirmation. With the **Hotel Domain** feature enabled, that return can land on the hotel's own website. There, your page reads the booking through [Get a booking confirmation](/booking-engine-api/build/reference/booking/get-booking-confirmation.md), and the return URL can act as a webhook to trigger your own post-booking steps. ## Performance ### Request only what you display The description and search endpoints accept display headers (`X-AVP-Properties`, `X-AVP-DescriptionType`, and `X-AVP-PictureTemplates`), and the hotel and room searches accept pagination (`pageNumber`, `pageSize`). Ask only for the fields, picture templates, and page sizes your interface shows. Smaller responses land faster on the guest's screen. ### Cache descriptions, not availability Descriptions of rates, rooms, and hotels change rarely, so cache them. Availability, quotes, and promotions change constantly: never cache them, and always read them live before showing a price or taking a booking. ## Resilience ### Retry transient errors with care Retry transient failures (network blips, timeouts, and occasional `5xx`) on `GET` calls with exponential backoff. State-changing calls are not idempotent (see [Requests](/booking-engine-api/build/guidelines/requests.md#idempotency)): before retrying a booking step, reconcile the basket with **Retrieve the basket** so you do not add a room or confirm a booking twice. ### Plan for slow or unreachable calls Decide upfront how long your interface waits for a response and what it shows past that point. Make the choice deliberately rather than letting the network decide. ### Log the error message and code When a call fails, capture the `Message` and `Code` from the response body in your logs. They let the partnership team pinpoint the failure when you report it. ### Tell us before a major launch If you are rolling out a campaign likely to multiply your normal 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.