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

# Booking message

> The booking XML pulled by D-EDGE or pushed by you

The `<booking>` element carries a reservation, a modification, or a cancellation from your platform to D-EDGE. The same structure serves both booking interfaces: it is what your endpoint returns inside `<bookings>` on [Get bookings](/channel-manager-api/build/reference/get-bookings.md), and what your system sends on [Push bookings](/channel-manager-api/build/reference/push-bookings.md).

Three invariants keep a booking integrable, whatever the channel:

* **Amounts add up**: `totalAmount` equals the sum of all nights (`unitPrice` × `quantity`) plus extras, taxes included.
* **Stay dates are constant**: every room of a booking covers the same dates, and the stay is contiguous.
* **People are counted**: one main customer with at least a first and last name (except on a cancellation), and one `guest` element per person in each room, each carrying an `ageRange`, named or not.

## Structure

**booking** `element` *required*

One booking.

**attributes**

**id** `attribute · string` *required*

Your **unique** booking identifier, maximum 20 characters. The same `id` must be used again when the booking is modified or cancelled.

**action** `attribute · enum` *required*

What happened: `Create`, `Modify`, or `Cancel`.

**currency** `attribute · string` *required*

The booking payment currency, 3-letter ISO code.

**date** `attribute · datetime` *required*

UTC date and time of the action: the creation, modification, or cancellation time, `YYYY-MM-DDTHH:MM:SS`.

**totalAmount** `attribute · decimal` *required*

Total booking amount, taxes included: the room or stay prices plus the extras. Positive, 2 decimal places.

**paidAmount** `attribute · decimal` *required*

Amount already paid by the customer, taxes included. Positive, 2 decimal places.

**dueAmount** `attribute · decimal` *required*

Amount the customer still pays on arrival, taxes included. Positive, 2 decimal places.

**payableAmount** `attribute · decimal` *required*

Amount the hotel charges back to you, the distributor, taxes included. Positive, 2 decimal places. How the four amounts combine per payment model is worked out in [Best practices](/channel-manager-api/build/best-practices.md#fill-the-amounts-for-your-payment-model).

**origin** `attribute · string`

Origin of the booking: your platform or booking website name.

**subOrigin** `attribute · string`

A finer origin, when your platform distinguishes one.

**paxCount** `attribute · integer` *required*

Total number of people in the whole booking.

**adultCount** `attribute · integer`

Number of adults in the booking. Send `adultCount`, `childCount`, and `infantCount` together, or none of the three: with none, D-EDGE derives the split from the `guest` elements.

**childCount** `attribute · integer`

Number of children. Sent together with `adultCount` and `infantCount`.

**infantCount** `attribute · integer`

Number of infants. Sent together with `adultCount` and `childCount`.

**commissionType** `attribute · enum`

How your commission is expressed, together with `commissionValue`: `percent` (a percentage of `totalAmount`) or `amount` (a fixed amount).

**commissionValue** `attribute · decimal`

The percentage or the amount, depending on `commissionType`. Positive, 2 decimal places.

**sellType** `attribute · enum`

Whether `totalAmount` is `net` (commission excluded, the hotel's net revenue) or `gross` (commission included).

**dayUse** `attribute · boolean`

Marks a day-use booking, for information.

**arrivalTime** `attribute · time`

The customer's arrival time, format `HH:mmZ` (the `Z` matters). Useful for day use, valid on any booking.

**departureTime** `attribute · time`

The customer's departure time, same format.

**child elements**

**customer** `element` *required*

The main customer. `firstName` and `lastName` attributes are required except on a cancellation; `title` takes `Mr`, `Mrs`, or `Miss` (defaults to `Mr`). If your platform does not split first and last names, put everything in `lastName`.

**child elements**

**comment** `element · 0..1`

The customer's free-text comment, as text or CDATA.

**contact** `element · 0..1`

Contact details: `email`, `phone`, and `fax` attributes. The email is optional but strongly recommended when the customer provided a real one; never send a generic address.

**child elements**

**address** `element · 0..1`

The postal address as text or CDATA, with `postalCode`, `city`, and `country` attributes (ISO 3166-1, 2 letters, upper case).

**creditCard** `element · 0..1`

The guarantee card, when your platform transmits it: `number`, `cardHolder`, `expiryDate` (`YYYY-MM`), `cardType`, and `cardVerificationCode` attributes. `cardType` takes `Visa` (the default when empty), `AmericanExpress`, `MasterCard`, `JCB`, or `Dinner` (Diners Club, spelled as the API expects it). The verification code is not required. Card details demand HTTPS end to end. If your platform cannot transmit them, make sure hotels can retrieve them on your side, and tell your D-EDGE Connectivity Project Manager: it changes how the connection is set up. What happens to the card once it reaches D-EDGE is described in [Card data](#card-data).

**company** `element · 0..1`

The corporate company attached to the booking, stored as a company profile and passed on to provider systems such as PMSs. Required attributes: `name` and `id` (an identifier maintained on your side). Optional `contact` child with `email` and `phone` attributes and an `address`, as on the customer.

**travelAgent** `element · 0..1`

The travel agency attached to the booking, same shape as `company`; the `id` commonly carries the IATA number, and the contact `email` is required.

**rooms** `element · 0..1`

The booked rooms. Required except on a cancellation.

**child elements**

**room** `element · 1..n` *required*

One booked room type, identified by its `id` attribute: your room code, as declared in [Get hotel](/channel-manager-api/build/reference/get-hotel.md), maximum 50 characters. An unmapped code prevents the booking from being integrated.

**child elements**

**stays** `element` *required*

The stay, day by day.

**child elements**

**stay** `element · 1..n` *required*

One night: `date` (`YYYY-MM-DD`), `quantity` (rooms of this type that night), `unitPrice` (price of one room that night, 2 decimals), and `rateCode` (your rate code, maximum 50 characters; an unmapped value integrates the booking on an arbitrary rate).

**guests** `element` *required*

The people staying in the room, one `guest` per person. D-EDGE counts them by `ageRange` to set the number of adults, children, and infants of the room, so send one element per person even when you know nothing about them.

**child elements**

**guest** `element · 1..n` *required*

One person. `ageRange` is required: `10` adult, `8` child, `6` infant. Everything else is optional: `firstName`, `lastName`, `title` (one of `Mr`, `Mrs`, or `Miss`, no other value; `Mr` when absent), and `birthDate` (`YYYY-MM-DD`). An element carrying only an `ageRange`, such as `<guest ageRange="8" />`, is enough for the count; add the identity when your platform has it.

**extras** `element · 0..1`

Extras sold with this room. Same `extra` structure as the booking-level element below; the room level allows a per-room guest count in the price formulas.

**extras** `element · 0..1`

Extras sold at booking level, when they are not attached to a room.

**child elements**

**extra** `element · 1..n` *required*

One extra type. All attributes are required. When `unitPrice`, `extraCode`, `quantity`, `inclusive`, or `pricingType` is missing, the extra is dropped and the booking integrates without it, with an `ExtraIntegrationError` warning (codes `204` to `208` in [Responses](/channel-manager-api/build/guidelines/responses.md#error-codes-d-edge-returns)).

**attributes**

**from** `attribute · date` *required*

Start of the extra's period, `YYYY-MM-DD`.

**to** `attribute · date` *required*

End of the period, included, `YYYY-MM-DD`.

**extraCode** `attribute · string` *required*

The extra's code on your platform, maximum 50 characters.

**extraName** `attribute · string` *required*

The extra's name; keep it under 50 characters for readability.

**quantity** `attribute · integer` *required*

The quantity of this extra, without re-including guest or night counts: the formula does that.

**unitPrice** `attribute · decimal` *required*

The unit price, combined with `pricingType` to compute the total. See [Extra price formulas](#extra-price-formulas) below.

**inclusive** `attribute · boolean` *required*

`true` when the extra is included or free (`unitPrice` is then `0`), `false` when it is charged.

**pricingType** `attribute · enum` *required*

How the total is computed: `PerStay`, `PerNight`, `PerGuest`, or `PerGuestPerNight`.

**distributor** `element · 0..1`

Additional information from your platform, as `comment` children: as many as you need, each holding free text or CDATA, with an optional `name` attribute you choose. `Cancel Policy` and `Guaranty` below are examples, not a fixed list. This is where cancellation policies travel, since the API does not model them.

```xml Full booking theme={null}
<?xml version="1.0" encoding="utf-8"?>
<booking id="EOC4440" action="Create" currency="EUR"
         date="2027-04-14T10:03:25" totalAmount="397.00" paidAmount="397.00"
         dueAmount="0.00" payableAmount="397.00" origin="MySite.com"
         paxCount="3" adultCount="2" childCount="1" infantCount="0"
         commissionType="percent" commissionValue="10.00" sellType="gross"
         dayUse="false" arrivalTime="15:00Z" departureTime="11:00Z">
  <customer firstName="Alain" lastName="Dupont" title="Mr">
    <contact email="alain.dupont@example.com" phone="0620304050">
      <address city="Paris" country="FR" postalCode="75002">
        <![CDATA[24 rue du sentier]]>
      </address>
    </contact>
    <creditCard number="4111111111111111" cardHolder="Alain Dupont"
                expiryDate="2028-03" cardType="Visa" />
    <comment><![CDATA[Quiet room, please.]]></comment>
  </customer>
  <travelAgent name="My Travel Agency" id="IATA12456">
    <contact email="agency@example.com" phone="+33120304050" />
  </travelAgent>
  <distributor>
    <comment name="Cancel Policy">
      <![CDATA[In the event of a no-show, the first night is charged.]]>
    </comment>
    <comment name="Guaranty"><![CDATA[Credit card guarantee]]></comment>
  </distributor>
  <rooms>
    <room id="CLA">
      <stays>
        <stay date="2027-10-02" quantity="1" unitPrice="62.50" rateCode="BAR" />
        <stay date="2027-10-03" quantity="1" unitPrice="63.00" rateCode="NR" />
        <stay date="2027-10-04" quantity="1" unitPrice="60.00" rateCode="BAR" />
      </stays>
      <guests>
        <guest firstName="Alain" lastName="Dupont" title="Mr" ageRange="10" />
      </guests>
    </room>
    <room id="SUP">
      <stays>
        <stay date="2027-10-02" quantity="1" unitPrice="70.50" rateCode="BAR" />
        <stay date="2027-10-03" quantity="1" unitPrice="70.50" rateCode="BAR" />
        <stay date="2027-10-04" quantity="1" unitPrice="70.50" rateCode="BAR" />
      </stays>
      <guests>
        <guest firstName="Helene" lastName="Dupont" title="Mrs" ageRange="10" />
        <guest firstName="Lea" lastName="Dupont" title="Miss"
               ageRange="8" birthDate="2019-02-05" />
      </guests>
    </room>
  </rooms>
</booking>
```

```xml Room-level extras theme={null}
<?xml version="1.0" encoding="utf-8"?>
<booking id="EOC4441" action="Create" currency="EUR"
         date="2027-09-14T10:03:25" totalAmount="249.00" paidAmount="0.00"
         dueAmount="249.00" payableAmount="0.00" origin="MySite.com"
         paxCount="1" adultCount="1" childCount="0" infantCount="0">
  <customer firstName="Jean" lastName="Dupont" title="Mr">
    <contact email="jean.dupont@example.com" />
  </customer>
  <rooms>
    <room id="CLA">
      <stays>
        <stay date="2027-10-02" quantity="1" unitPrice="50.00" rateCode="BAR" />
        <stay date="2027-10-03" quantity="1" unitPrice="50.00" rateCode="BAR" />
        <stay date="2027-10-04" quantity="1" unitPrice="50.00" rateCode="BAR" />
      </stays>
      <guests>
        <guest firstName="Jean" lastName="Dupont" title="Mr" ageRange="10" />
      </guests>
      <extras>
        <extra from="2027-10-02" to="2027-10-04" quantity="1" unitPrice="16.00"
               extraCode="R894" extraName="Minibar" inclusive="false"
               pricingType="PerNight" />
        <extra from="2027-10-02" to="2027-10-04" quantity="2" unitPrice="8.50"
               extraCode="124TF" extraName="Breakfast" inclusive="false"
               pricingType="PerGuestPerNight" />
      </extras>
    </room>
  </rooms>
</booking>
```

## Extra price formulas

The total price of an extra follows its `pricingType`, and the guest count in the formula depends on where the extra sits:

| `pricingType` | Total price |
| - | - |
| `PerStay` | `unitPrice` × `quantity` |
| `PerNight` | `unitPrice` × `quantity` × number of nights (`from` to `to`) |
| `PerGuest` | `unitPrice` × `quantity` × guest count |
| `PerGuestPerNight` | `unitPrice` × `quantity` × guest count × number of nights |

At **room level**, the guest count is the number of `guest` elements in the room. At **booking level**, it is the booking's `paxCount`. In the room-level example above, the total checks out as 150 (three nights at 50) + 48 (minibar: 16 × 1 × 3 nights) + 51 (breakfast: 8.50 × 2 × 1 guest × 3 nights) = 249.00.

Provide one `extra` element per extra type (`extraCode`), and remember the invariant: every extra amount counts towards `totalAmount`.

## Card data

When your platform sends card details, D-EDGE routes the booking flow through its PCI environment before a booking reaches the rest of the platform. Tell your D-EDGE Connectivity Project Manager that your bookings carry cards. The routing is set up per connection, and D-EDGE raises a security alert when card numbers reach a connection without it.

The routing covers the booking flow only:

* The body of the requests you send on [Push bookings](/channel-manager-api/build/reference/push-bookings.md).
* The body of the responses you return on [Get bookings](/channel-manager-api/build/reference/get-bookings.md).
* [Planning updates](/channel-manager-api/build/reference/planning-updates.md) carry no card data and stay outside it.

Two things happen to a booking on the way in. The card number is replaced by a token, and the verification code is replaced by `000`. Both replacements happen before the booking enters the D-EDGE platform, so the platform itself never holds the card. D-EDGE keeps the real card in its PCI vault, from which it is read or passed on to the right people and systems under strict rules.

The detection runs over the whole message, not only `creditCard`. A card number or a verification code (CVV, CVC) found in any other element or attribute, such as a free-text comment, is treated as card data and replaced where it sits.

The detection works on the shape of a value, so data that only looks like card data is replaced too. Keep these values out of every element other than `creditCard`:

* A number of 12 to 19 digits that starts like a card number, such as `4` (Visa), `51`–`55` (Mastercard), or `34` and `37` (American Express).
* A value that starts with `CVV` or `CVC`.

Send the card in `creditCard` all the same: it is where D-EDGE reads it.

You never see a token. D-EDGE returns no booking to you on this API, so the replacements stay on the D-EDGE side of the flow.


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