> ## 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. # Test scenarios > Every scenario D-EDGE runs, interface by interface This page lists the scenarios of the certification, interface by interface, in the order D-EDGE works through them; the phase two scenarios add the calls your platform makes. Use the scenario identifiers when you report a result to your D-EDGE Connectivity Project Manager. Most scenarios run on every integration. A marker next to an identifier means the scenario needs a condition: hover it to read which one. Your [questionnaire](/channel-manager-api/get-certified/questionnaire.md) is what tells D-EDGE which conditions you meet. ## Phase one: basic behaviour D-EDGE runs these scenarios against your test environment, without Push bookings. The requests arrive exactly as in production, namespace declarations and `` element included: see [Requests](/channel-manager-api/build/guidelines/requests.md). The room and rate codes they use are the ones your Get hotel response returns. ### Checks on every response Every request of the plan carries these four checks, success or failure alike: a response that misses one fails the scenario whatever else it contains. | Check | What must be true | | - | - | | Status | `200 OK`, on a failure too. See [Always 200 OK](/channel-manager-api/build/guidelines/responses.md#always-200-ok). | | Content type | A `Content-Type: application/xml` header, and a body that parses as XML with `` as its root. | | Response time | Under **5 seconds**, or **30 seconds** on Get bookings. | | Envelope | On a failure, exactly one `` element carrying a `type` from the [error tables](/channel-manager-api/build/guidelines/responses.md#error-codes-to-return), its `message` when you send one, and at most one `` with no stack trace in it. | ### Get hotel The first scenario feeds the rest of the plan: D-EDGE reads your price model, your currency, and your room and rate codes from its response. | ID | What we send | What we expect | | - | - | - | | GH-01 | A request with valid credentials and the test hotel's `hotelCode` | The hotel configuration, checked against the [Get hotel](/channel-manager-api/build/reference/get-hotel.md) reference, on a test hotel that carries at least three room types and three rates in total, one room carrying at least two rates | | GH-02 | The same request without credentials | A `` of type `3`. D-EDGE also accepts type `203`. | | GH-03 | The same request with a wrong password | A `` of type `3` | | GH-04 | A request without `hotelCode` | A `` of type `1`, `2`, or `203` | | GH-05 | A request with an unknown `hotelCode` | A `` of type `1` or `2` | ### Planning updates The prices of each scenario arrive in the shape of your [price model](/channel-manager-api/build/guidelines/price-models.md). Every date range is relative to the day of the session. #### Updates you must accept | ID | What we send | What we expect | | - | - | - | | PU-01 | Room inventory only: one room, several contiguous ranges, no `rate` element | ``, and the quantities applied on your platform | | PU-02 | Room inventory up to the maximum horizon you declared | `` | | PU-03 | A range that starts yesterday | ``; the past day is ignored, the rest applied. See [Engineer for the traffic pattern](/channel-manager-api/build/best-practices.md#engineer-for-the-traffic-pattern). | | PU-04 (Only if you support per-rate availability) | Room inventory plus an `availability` attribute on `planning`, for one room and rate, up to the maximum horizon you declared | ``, with the rate-level availability applied | | PU-05 (Only if you support a minimum stay) | `minimumStay` only, on two rates of the same room, each over its own ranges | `` | | PU-06 (Only if you support a maximum stay) | `maximumStay` only, on two rates of the same room, each over its own ranges | `` | | PU-07 (Only if you support closed to arrival) | `noArrival` only, on two rates of the same room, each over its own ranges | `` | | PU-08 (Only if you support closed to departure) | `noDeparture` only, on two rates of the same room, each over its own ranges | `` | | PU-09 | `isClosed` only, on two rates of the same room, closed then reopened on the first and the reverse on the second | ``, and the room and rate closed then reopened on your platform | | PU-10 | Prices only, no inventory and no restriction | `` | | PU-11 | Prices and restrictions together, no inventory | `` | | PU-12 | A full update of one room and one rate: inventory, prices, and restrictions over several ranges, including a single-day range | ``, and every value applied | | PU-13 | Ranges that leave gaps between them, in the inventory and in the planning | ``; the days not covered are left untouched | | PU-14 | One room with several rates, each with its own prices and restrictions, and an availability quantity of `0` on one range | ``, and the room closed to sale on that range | | PU-15 | Several rooms with a single rate | `` | | PU-16 | Several rooms with several rates, one of the rooms carrying inventory only | `` | | PU-17 | Several rooms up to the maximum horizon you declared | `` | | PU-18 | Prices of `2.00`, `200.00`, and `340000000.50` | ``, because the hotel set them. A price check on your side belongs in an internal alert, not in the response. | | PU-19 (Only if you support meal plans) | A rate with `mealPlanType` and `mealPlan` elements: adult only, child only, then adult and child | ``, with `unitPrice` applied as the total price, meals included. See [Meal plans](/channel-manager-api/build/reference/planning-updates.md#meal-plans). | #### Updates you must refuse Each of these messages is valid XML with one wrong value. | ID | What we send | What we expect | | - | - | - | | PU-F1 | A wrong password in `` | Type `3`, `BadAuthentication` | | PU-F2 | An unknown `hotelId` | Type `1` or `2` | | PU-F3 | An unknown room `id` | Type `4`, `RoomMappingError` | | PU-F4 | An unknown room next to a valid room | Type `4`, and the valid room applied anyway. See [Your response](/channel-manager-api/build/reference/planning-updates.md#your-response). | | PU-F5 | An unknown `rateCode` | Type `5`, `RateMappingError` | | PU-F6 | An unknown rate next to a valid rate | Type `5`, and the valid rate applied anyway | ### Get bookings The content checks run on whatever your test hotel returns. Before the session, create a one-room booking, a booking with several rooms and a child, a modified booking, and a cancelled one. D-EDGE can create them instead, through a booking engine on the hotel. With no booking in the window, the request scenarios still pass on a bare ``. #### Requests | ID | What we send | What we expect | | - | - | - | | GB-01 | The per-hotel variant with `duration` | `` followed by one `` element for the hotel, with the bookings whose latest action falls in the window | | GB-02 | The per-hotel variant with `from` and `to` | Same | | GB-03 | The per-hotel variant with no window parameter | Same, behaving as `duration=1` | | GB-04 (Only if you provide master credentials) | The all-hotels variant with `duration` | `` followed by one `` element per hotel with bookings | | GB-05 (Only if you provide master credentials) | The all-hotels variant with `from` and `to` | Same | | GB-06 (Only if you provide master credentials) | The all-hotels variant with no window parameter | Same, behaving as `duration=1` | | GB-F1 | A request with a wrong password | Type `3`, `BadAuthentication` | | GB-F2 | A request with an unknown `hotelId` | Type `1` or `2` | | GB-F3 | A `duration` that is not an integer | Type `203`, naming the parameter in the comment | | GB-F4 | A `from` or `to` that does not match `YYYY-MM-DDTHH:MM:SS` | Type `203`, naming the parameter in the comment | #### Booking content These checks apply to every booking of every successful response, against the [booking message](/channel-manager-api/build/reference/booking-message.md) structure. | ID | What we check | | - | - | | GB-C1 | Each booking appears once, with an `id` unique in the response, under the `action` of its latest action and dated with that action's time in `YYYY-MM-DDTHH:MM:SS`. See [What belongs in a window](/channel-manager-api/build/reference/get-bookings.md#what-belongs-in-a-window). | | GB-C2 | `currency` matches the currency your Get hotel response declares | | GB-C3 | `totalAmount`, `paidAmount`, `dueAmount`, and `payableAmount` are present and decimal, and `totalAmount` equals the sum of every stay's `unitPrice` times `quantity`, plus every extra | | GB-C4 | `paxCount` is at least 1, `adultCount`, `childCount`, and `infantCount` are either all present or all absent, and the optional attributes take their documented values when present: `commissionType`, `sellType`, `dayUse`, `arrivalTime`, `departureTime` | | GB-C5 | The `customer` carries a first and last name, except on a cancellation; `title`, when present, is `Mr`, `Mrs`, or `Miss` | | GB-C6 | `creditCard`, when present, carries `expiryDate` in `YYYY-MM` and a documented `cardType`; `company` and `travelAgent`, when present, carry a `name` | | GB-C7 | Every room `id` and every stay `rateCode` exist in your Get hotel response | | GB-C8 | Every `stay` carries a `date` in `YYYY-MM-DD`, a `quantity` of at least 1, a `unitPrice`, and a `rateCode` | | GB-C9 | Every room carries one `guest` per person, each with an `ageRange` of `10`, `8`, or `6` | | GB-C10 (Only if you sell extras) | Every `extra` carries `unitPrice`, `extraCode`, `quantity`, `inclusive`, and `pricingType`, at the level it applies to. See [Put extras where they belong](/channel-manager-api/build/best-practices.md#put-extras-where-they-belong). | ### Confirm bookings The acknowledgements refer to bookings your endpoint returned, so these scenarios run after the Get bookings ones. | ID | What we send | What we expect | | - | - | - | | CB-01 | A `bookingConfirmation` with `status="Create"`, naming a booking you returned in `partnerBookingId` and the D-EDGE reference in `crsBookingId` | ``, and the booking marked as integrated on your side | | CB-02 (Only if you support modifications) | A `bookingConfirmation` with `status="Modify"` for a modified booking | `` | | CB-03 (Only if you support cancellations) | A `bookingConfirmation` with `status="Cancel"` for a cancelled booking | `` | ## Phase two: live certification Push bookings is in play from here. Your D-EDGE Connectivity Project Manager works on the D-EDGE test hotel linked to yours, in production conditions, and checks the result on your side. | ID | What happens | What we expect | | - | - | - | | LC-01 | D-EDGE changes availability, prices, and each restriction you declared on the D-EDGE test hotel | Each change reaches your platform within minutes and is applied, in the shape of your price model | | LC-02 (Modifications and cancellations only when you support them) | Your platform pushes the creation, then the modification, then the cancellation of a booking through [Push bookings](/channel-manager-api/build/reference/push-bookings.md), while D-EDGE also pulls them through Get bookings | A `` from D-EDGE on each push, each action integrated once, and a Confirm bookings acknowledgement with the matching `status` on your endpoint | | LC-03 | D-EDGE reads the integrated bookings | Guests, amounts, and extras exactly as your booking messages described them | ## Run them yourself The phase one scenarios ship as a collection for Postman and Insomnia. > [!NOTE] > > The collection covers the 43 scenarios that are requests D-EDGE sends to your endpoints. The other 13 run with D-EDGE during the session. The booking content checks GB-C1 to GB-C10 read what your endpoint answers, and the phase two scenarios need the D-EDGE platform on the other side. > **[D-EDGE Docs: Channel Manager API test scenarios](/overview/resources/api-collections.md#channel-manager-api-test-scenarios)** > > The downloads, the variables to fill, and the order to run the folders in, on the API collections page. ## Next steps > **[Certification steps](/channel-manager-api/get-certified/certification-steps.md)** > > The hand-over, the two test phases, and the pilot. > **[Questionnaire](/channel-manager-api/get-certified/questionnaire.md)** > > The questions D-EDGE asks before testing, and what each answer decides. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.