> ## 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. # Get bookings > D-EDGE pulls new, modified, and cancelled bookings > [!NOTE] > > D-EDGE sends HTTP `GET` requests to the URL you provide, authenticated with [Basic Auth](/channel-manager-api/build/guidelines/authentication.md). The hosting model is described in [the introduction](/channel-manager-api/get-started/introduction.md#an-api-that-runs-on-your-endpoints). Get bookings is the pull half of the booking flow. D-EDGE calls your endpoint every few minutes (every 5 by default, down to 1 when needed), and your platform returns the bookings **created, modified, or cancelled** in the requested time window. It works together with [Push bookings](/channel-manager-api/build/reference/push-bookings.md), and both are required: the pull guarantees that nothing is lost, the push makes integration immediate. D-EDGE deduplicates, so a booking arriving through both channels is integrated once. Successive pulls overlap on purpose: by default each one asks for the last two hours, so the same booking comes back on several pulls and a repeat is not a new event. Bookings are integrated asynchronously and treated as confirmed; the [Confirm bookings](/channel-manager-api/build/reference/confirm-bookings.md) message closes the loop once each one is in. ## The request we send Two variants exist. Your endpoint must implement the first; the second applies only when you provide master credentials: * **Per hotel**: the request carries a `hotelId`. This variant is mandatory in all cases, and D-EDGE may query several hotels in parallel. * **All connected hotels**: no `hotelId`, only possible when you provide [master credentials](/channel-manager-api/build/guidelines/authentication.md). The time window is set either by `from` and `to`, or by `duration`. **Both mechanisms are mandatory** on your side; a given request uses one or the other, never both. **hotelId** `string` The hotel identifier or code on your platform, maximum 50 characters. Present on the per-hotel variant, absent on the all-hotels variant. **from** `datetime` Start of the window, UTC, `YYYY-MM-DDTHH:MM:SS`. Used together with `to`, exclusive with `duration`. **to** `datetime` End of the window, UTC, same format. Used together with `from`, exclusive with `duration`. **duration** `integer` Number of past hours to look back from the request time. Exclusive with `from` and `to`. When no window parameter is present, behave as if `duration=1`. When a parameter is malformed (a `duration` that is not an integer, a `from` or `to` that does not match the format), return a `` with code `203` (`InternalError`). Name the faulty parameter in the comment. The two examples show one variant each: a one-hour window on one hotel, and the last hour on all hotels, which only master credentials allow. ```http Per hotel theme={null} GET /getBookings?from=2027-04-20T20:00:00&to=2027-04-20T21:00:00&hotelId=1234 HTTP/1.1 Authorization: Basic dGVzdGhvdGVsOnRlc3RwYXNzd29yZA== Accept: application/xml, text/xml Host: yourdomain.com ``` ```http All hotels theme={null} GET /getBookings?duration=1 HTTP/1.1 Authorization: Basic dGVzdGhvdGVsOnRlc3RwYXNzd29yZA== Accept: application/xml, text/xml Host: yourdomain.com ``` ## What belongs in a window A booking belongs to the window of its **latest action**: return it with the `action` matching what happened last, dated with that action's time. Take two bookings on 19 June: B1 created at 08:00, B2 created at 10:00 and cancelled at 10:30. | Window requested | You return | | - | - | | 08:00 to 09:00 | B1 with `action="Create"` | | 09:30 to 09:40 | Nothing | | 09:50 to 10:10 | Nothing: B2's status changed at 10:30, after this window | | 10:20 to 11:00 | B2 with `action="Cancel"` | ## The response we expect Return `200 OK` with a `` followed by the bookings, grouped in one `` element per hotel. A quiet window returns the bare success. D-EDGE waits up to 30 seconds for this response, longer than the 5 seconds of the other interfaces, because a busy window can hold many bookings. On an error, return the [failure envelope](/channel-manager-api/build/guidelines/responses.md). **message** `element` *required* The root element. **child elements** **success** `element` *required* Present on every successful response, even with no bookings. **bookings** `element · 0..n` The bookings of one hotel, identified by its `hotelId` attribute (your hotel code, maximum 50 characters). One element per hotel; absent when there is nothing to return. **child elements** **booking** `element · 1..n` *required* One booking, with the structure documented on the [Booking message](/channel-manager-api/build/reference/booking-message.md) page. ```xml Bookings theme={null} ``` ```xml No bookings theme={null} ``` ```xml Failure theme={null} ``` ```xml Invalid parameter theme={null} ``` On a cancellation, only the booking attributes and an empty `` are required: `rooms`, names, and contact details can be omitted. On a modification, resend the full booking under the same `id` with `action="Modify"`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.