> ## 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. # Requests > Message conventions and endpoint standards Four of the five interfaces are requests **D-EDGE makes to your endpoints**. This page sets the conventions those messages follow, and the standards your endpoints must meet to receive them. ## Content type Everything is XML over HTTPS. * What D-EDGE sends: the GET requests (Get hotel, Get bookings) carry `Accept: application/xml, text/xml` and no body, so no `Content-Type`; the POST requests (Planning updates, Confirm bookings) carry `Content-Type: application/xml; charset=utf-8`. * Accept requests whether they declare `application/xml`, `text/xml`, or no content type: parse the XML body regardless of the header. * Every request carries `Accept-Encoding: gzip, deflate`: you may compress your responses, which helps on Get bookings when a window holds many bookings. * On the POST interfaces, the XML is posted as the raw request body, not as a form field. * Your responses must declare `Content-Type: application/xml` and contain XML only. An HTML error page or a plain-text message breaks the exchange. > [!WARNING] > > Messages D-EDGE sends can start with a **byte order mark (BOM)**. Make sure your XML parser tolerates it: a parser that does not expect the BOM fails on the very first character of the message. The `` root of the updates D-EDGE sends also carries two namespace declarations, `xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"` and `xmlns:xsd="http://www.w3.org/2001/XMLSchema"`. They carry nothing for you: the elements themselves have no namespace. The examples on this portal leave them out; your parser must accept them. ## Formats | Data | Format | Example | | - | - | - | | Date | `YYYY-MM-DD` | `2027-03-15` | | Date and time | `YYYY-MM-DDTHH:MM:SS`, UTC | `2027-03-15T10:03:25` | | Time of day | `HH:mmZ` | `15:00Z` | | Amounts | Decimal, positive. Booking amounts carry 2 decimal places; planning update prices have no fixed number of decimals | `142.50` | | Booleans | `true` or `false` | `true` | | Country codes | ISO 3166-1, 2 letters, upper case | `FR` | | Currency codes | ISO 4217, 3 letters | `EUR` | Date ranges (`from`/`to` attributes) are **inclusive on both ends**: an update from `2027-03-01` to `2027-03-03` covers three days. ## Identifiers are yours Every hotel, room, and rate identifier in every message is the code **your platform declared** in [Get hotel](/channel-manager-api/build/reference/get-hotel.md). D-EDGE stores the mapping and translates internally; your system never sees a D-EDGE identifier, except the D-EDGE booking reference returned by [Confirm bookings](/channel-manager-api/build/reference/confirm-bookings.md). Identifiers are limited to 50 characters (20 for booking identifiers). When the configuration changes on your platform (a room or rate is added, renamed, or removed), tell the hotel, and the hotel asks D-EDGE to redo the mapping. D-EDGE does not re-read your configuration automatically. ## Updates are deltas Planning updates carry only what changed. Two rules follow: * A message may contain availability only, prices only, restrictions only, or any mix. Treat every price and restriction value as independently optional. Only the identifiers, the date ranges, the `quantity` of each availability range, and the `isClosed` flag of each occupancy are always present. * **An absent attribute means "do not touch this value"**, never "reset it". Update exactly what the message contains for the hotel, room, rate, occupancy, and days it names, and nothing else. The `updateType` your platform declares per room and rate in Get hotel also shapes what D-EDGE sends: a combination declared `Inv` only ever receives inventory, for example. ## Volume and timing Your endpoints must hold up to real production traffic: * **Answer in less than 5 seconds.** If applying an update takes longer, accept it, answer, and process asynchronously. The exception is Get bookings: a window can hold many bookings, so D-EDGE waits up to 30 seconds for that response. * **Expect large messages.** When a hotel is connected, or its configuration changes, D-EDGE sends an initialisation stream covering the hotel's full planning: hotels manage a sliding window of up to **2 years**, generally split into one message per month, sometimes more. * **Expect updates at any time.** Whenever a price, an availability, or a restriction changes in D-EDGE, an update leaves within minutes, 15 at most. * D-EDGE pulls your bookings every few minutes, every 5 by default, and can query several hotels in parallel. ## Your endpoint standards The checklist your four endpoints must meet: * HTTPS with a valid, trusted certificate, TLS 1.2 or higher. * XML responses only, always `200 OK`, errors inside the message envelope; `5xx` only when your service is genuinely down. See [Responses](/channel-manager-api/build/guidelines/responses.md). * Basic Auth (GET interfaces) or the `` element (POST interfaces) validated on every call. See [Authentication](/channel-manager-api/build/guidelines/authentication.md). * Able to absorb the initialisation volume and answer within 5 seconds (30 seconds for Get bookings). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.