> ## 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 > From catalogue to confirmed order The Gift Shop API drives a stateful purchase journey. These patterns keep that journey fast, accurate, and resilient, from the first product search to a paid order. ## Session lifecycle ### Reuse one session across the journey Open a session once, then carry its `sessionId` through the catalogue, the cart, and the confirmation. Do not open a new session per call: the cart lives in the session, and a new session starts from an empty cart. ### Recover from an expired session When a call returns `404` for a session you created earlier, treat the session as gone. Create a fresh one and rebuild the cart from the selection you keep on your side. Build this recovery path in from the start rather than assuming sessions last forever. One exception: on **Get the gift shop configuration**, a `404` can also mean no configuration exists for the session's owner. If a fresh session hits the same `404` on that call, check the owner identifiers rather than recreating sessions in a loop. ### A paid session locks its cart The session carries a `status`: `Pending` while the guest shops, `Paid` once the payment is confirmed. After payment the cart no longer accepts changes: adding, updating, or removing items stops working. Read **Get session partial data** when you need to know which side of that line a session is on, and start a new session for a new purchase. ### Set the culture at creation Pass the guest's `culture` when you create the session: product names, descriptions, and the localised country list all follow it. To switch language mid-journey, update the session rather than recreating it, so the cart survives the change. ## Catalogue ### Cache what rarely changes The configuration, categories, and localisation lists are stable for a given shop. Cache them on your side and refresh them periodically rather than on every page view. Do not cache the cart: read it from the API whenever you display it. ### Respect the price type A product's price is either `Fixed` or a `Range`. For a range, let the guest choose an amount between `minAmount` and `maxAmount` and send it when adding the item to the cart. For a fixed price, send the product's own amount unchanged: the `amount` field is required in both cases, and the API rejects a missing or different amount with a `400`. ### Respect the quantity limits Each product carries a `min` and `max` quantity. Validate the guest's input against them before calling **Add a cart item**, and surface the limits in the interface rather than letting the call fail. ### Tell the guest where a voucher is used Every product carries a `usage` field. `Direct` is a value voucher, spent on the hotel's or group's online D-EDGE booking engine; its price always appears on the voucher document. `Indirect` is a service redeemed with the shop owner, at the hotel or within the group, which marks the voucher as used when the guest presents the code; its price can be hidden with `hidePrice`. Read the field and adapt your product page and confirmation message, so a spa voucher is never presented as spendable online, and a price-hiding option is never shown on a product that always prints its value. ## Cart and gift options ### Capture the gift intent Each cart item can go to the shopper or to a beneficiary (`sendTo`). When the guest offers the voucher to someone else, collect the beneficiary's name and email, and the optional personal message (`comment`) and sender name (`sentFrom`): they travel with the voucher. ### Use the cart as the source of truth Amounts, taxes, and totals are computed by the API. Display the cart from the **Get the active cart** response rather than recomputing prices on your side, and re-read it right before confirmation so the guest pays what they saw. ## Confirmation and order ### Redirect promptly after confirmation **Confirm the cart** returns a `redirectUrl` to the payment page, hosted and handled by D-EDGE. Send the guest there straight away: the URL reflects the cart at confirmation time. Pass a `confirmationUrl` so the guest comes back to your site after payment. ### Treat the order as sensitive The order carries the voucher codes, the shopper's personal data, and a payment summary. A voucher code is worth money: store and display it with the same care as a credential, and never store the payment card details returned with the order. ## Resilience ### Retry transient errors with care Retry transient failures (network blips, timeouts, and occasional `5xx`) on `GET` calls with exponential backoff. **Add a cart item** is not idempotent (see [Requests](/gift-shop-api/build/guidelines/requests.md#idempotency)): before retrying it, read the cart with **Get the active cart** so you do not add the same voucher 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 problem details When a call fails, capture the `title` field and, on validation errors, the `errors` map and the `traceId` from the problem details body in your logs. The `traceId` lets the partnership team pinpoint the exact failing call when you report it; keep `detail` and `instance` too when they are present. ### 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.