> ## 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.

# Questionnaire

> The questions D-EDGE asks before testing

Before you hand over your endpoints, your D-EDGE Connectivity Project Manager sends you a questionnaire to complete. It describes how your platform stores planning data and handles bookings. This page lists them so you can prepare the answers with your product and technical teams ahead of time.

Your answers decide the [scenarios](/channel-manager-api/get-certified/test-scenarios.md) that apply to you, how D-EDGE sets up the connection, and what D-EDGE tells the hotels it connects about your platform. Answer from how your platform works today: D-EDGE tests a capability you declare, and documents one you leave out as unsupported.

## Platform and security

| Question | What your answer decides |
| - | - |
| Do you filter inbound traffic by IP address? | If so, D-EDGE sends you the addresses to allow before the tests. See [Transport security](/channel-manager-api/build/guidelines/authentication.md#transport-security). |
| Do your endpoints run on HTTPS with a valid, trusted certificate, on TLS 1.2 or higher? | Required on every endpoint you host. |
| On your POST endpoints, do you accept both `text/xml` and `application/xml` as request content type? | D-EDGE sends `application/xml; charset=utf-8` today, and your parser must not depend on the header. See [Requests](/channel-manager-api/build/guidelines/requests.md). |
| Which credential model do you provide: one login and password per hotel, or master credentials for all hotels? | Master credentials unlock the all-hotels variant of Get bookings. See [Choose a credential model](/channel-manager-api/build/guidelines/authentication.md#choose-a-credential-model). |
| Do you validate incoming XML against a schema before processing it? | Tells D-EDGE how strictly your endpoints read the messages, including the namespace declarations and the byte order mark D-EDGE messages can carry. |
| Do your booking messages carry card details? | If they do, D-EDGE routes your booking flow through its PCI environment, and you tell your D-EDGE Connectivity Project Manager before the connection is set up. See [Card data](/channel-manager-api/build/reference/booking-message.md#card-data). |
| Do you provide an administration interface to hoteliers? If so, which URL? | The D-EDGE team uses it to check what your platform received, during the tests and later in support. |
| Does a hotel need a technical activation on your side before it can receive XML? If so, how does it work? | It becomes a step of [Connect a new hotel](/overview/run-your-integration/connect-a-new-hotel.md) for your integration. |
| Once a hotel is connected to D-EDGE, is its planning locked against manual changes on your side? | Explains to hotels where they manage their planning once the connection is live. |
| Is your test hotel reachable on your production URLs too? If so, under which hotel code? | Lets D-EDGE keep a test hotel connected after the pilot. |
| Who are your technical, support, and sales contacts for this connection? | The D-EDGE team reaches them during the tests, in support, and for new hotel setups. |

## Rooms and rates

| Question | What your answer decides |
| - | - |
| How are room types and rates structured on your platform: one or several room types, one or several rates, and how are they linked? Can one room type carry several rate codes? | Shapes the [Get hotel](/channel-manager-api/build/reference/get-hotel.md) response and the mapping D-EDGE builds from it, and decides whether the multi-rate scenarios apply. |
| How do you handle meal plans: as separate rates, as a property of the rate, or otherwise? Can you store the meal price separately from the room price, per adult and per child? | Decides how D-EDGE maps meal-inclusive rates, and whether your connection carries the [meal plan detail](/channel-manager-api/build/reference/planning-updates.md#meal-plans). |
| Do you manage negotiated or contracted rates with special rules, such as prices D-EDGE must not update? | D-EDGE maps such rates with an [update type](/channel-manager-api/build/reference/get-hotel.md#update-types) other than `PRI`. |
| Do you manage rates derived from another rate, such as a discount on the flexible rate? Are they linked to D-EDGE or computed on your side? | If D-EDGE also updates a derived rate, the rate has two sources of truth: D-EDGE and your own calculation. |
| Do you manage allotment contracts directly with hotels, with a contracted number of rooms? | Contracted availability lives next to the free availability D-EDGE sends, and the two must not be confused. |
| Do you handle several currencies? Is the currency defined per hotel, or per hotel and rate? Do you connect hotels outside the euro zone? | Decides the `currency` attribute you return in Get hotel and how D-EDGE handles a mismatch. See [Currency](/channel-manager-api/build/reference/get-hotel.md#currency). |

## Availability, prices, and restrictions

| Question | What your answer decides |
| - | - |
| At which level do you store availability: per hotel and day; per room type and day; or per room type, rate, and day? | Decides whether the connection sends room-level availability only, or per-rate availability too. |
| At which level do you store prices: per room type and day; per room type, rate, and day; or per room type, rate, and occupancy? | This is your [price model](/channel-manager-api/build/guidelines/price-models.md): `PerDay`, `PerPerson`, or `PerOccupancy`. It shapes every planning update for the life of the connection. |
| How far ahead do you store availability, prices, and restrictions, in days? | The scenarios send updates up to that horizon, and D-EDGE caps the initial synchronisation accordingly. |
| Which maximum values does your platform accept for availability, prices, minimum stay, and maximum stay? | The tests send very low and very high prices, which your endpoint must accept. For every other value, the tests stay under your limits. |
| How do you treat a price of 0: ignored, a free night, or refused? | D-EDGE avoids sending a value your platform would misread. |
| Do you expect [sellable prices](/overview/resources/glossary.md#sellable-price), commission included, or net prices? VAT and local taxes included, or excluded? | Prices are sellable, commission included, by default. See [Fill the amounts for your payment model](/channel-manager-api/build/best-practices.md#fill-the-amounts-for-your-payment-model) and the price conventions below. |
| Do you manage a minimum stay and a maximum stay? If so, do they apply on arrival or through the stay, and at which level? | D-EDGE sends `minimumStay` and `maximumStay` per room, rate, and day, from 1 to 99 nights. |
| Do you manage closed to arrival and closed to departure? At which level? | If not, D-EDGE tells hotels the restriction is not available on your platform, and a [workaround](/channel-manager-api/build/best-practices.md#restrictions-you-do-not-support) exists for closed to arrival. |
| At which level do you manage open and closed to sale: room type, rate, room and rate, or occupancy? | Every integration must handle `isClosed`; the tests send it to all. Occupancy-level closing matters under `PerPerson` and `PerOccupancy`. |

## Bookings

| Question | What your answer decides |
| - | - |
| Do you return complete customer data (names, email, address, phone) and the guest details of each room, with one guest per person? | Decides which `customer` and `guest` checks apply. D-EDGE counts the guests of a room by `ageRange`. See [Booking message](/channel-manager-api/build/reference/booking-message.md). |
| Can one booking hold several room types? Several rooms of the same type? Several rates? | Decides the multi-room and multi-rate booking scenarios. |
| Do you allow booking modifications? Which ones: dates, rooms, guests, rates? | Decides the modification scenarios, and whether hotels can expect modifications from your platform. |
| Do you allow booking cancellations? | Decides the cancellation scenarios. |
| How do you manage cancellation policies, and do they differ per hotel or per rate? | Policies stay on your platform; a booking carries the one that applied as a `distributor` comment. |
| Which guarantee types do you apply: card guarantee, partial prepayment, full prepayment, virtual card? Can the guarantee differ per rate? | Decides how you fill the [four booking amounts](/channel-manager-api/build/best-practices.md#fill-the-amounts-for-your-payment-model). |
| In which cases do you return card details: under which guarantee types, and always or only sometimes? | D-EDGE reviews these cases before it enables the PCI routing, and hotels need to know when to expect a card. |
| Do you return sellable or net prices in bookings, VAT and local taxes included or excluded? Does it depend on the guarantee? | See the price conventions below. |
| Do you sell anything other than rooms, such as extras or add-ons? How does a hotel configure them on your side? | Decides the extras scenarios, and where each extra belongs in the booking message. See [Put extras where they belong](/channel-manager-api/build/best-practices.md#put-extras-where-they-belong). |
| Do you allow late bookings, after midnight hotel time, for the current night? | D-EDGE integrates them; the hotel needs to know they can arrive. |
| Is there any case where your platform accepts a booking on a closed room or rate? | Not recommended. If so, describe the feature behind it. |
| Is your booking identifier unique and never reused for another booking? | The `id` is the key of the whole booking lifecycle. |
| Which `distributor` comments do you return, and under which names? | The hotel reads them as free text. |
| Do you send an email to the hotel when a booking is created, modified, or cancelled? | Hotels receive the booking from D-EDGE too; they need to know when to expect both. |
| How do you use the [Confirm bookings](/channel-manager-api/build/reference/confirm-bookings.md) acknowledgement? | Tells D-EDGE whether your retry logic relies on it, as recommended. |

## Price conventions

For the prices D-EDGE sends you, and for the booking prices you send D-EDGE, state whether the amounts include or exclude the commission, VAT, and local and city taxes. Describe the cases where your platform allows several configurations.

## Next steps

> **[Certification steps](/channel-manager-api/get-certified/certification-steps.md)**
>
> The hand-over, the two test phases, and the pilot.

> **[Test scenarios](/channel-manager-api/get-certified/test-scenarios.md)**
>
> Every scenario D-EDGE runs, what it sends, and what it expects.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.