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

# Price models

> How your platform stores prices decides how D-EDGE sends them

The price model is the one setting your platform declares in [Get hotel](/channel-manager-api/build/reference/get-hotel.md) and that D-EDGE applies in every [planning update](/channel-manager-api/build/reference/planning-updates.md) for the life of the connection. It says how your planning database stores a price: per room and day, per person count, or per adult and child combination. Get it right once, and prices arrive in a shape your platform can store without translation.

The model is set per hotel, in the `priceModel` attribute of the `rooms` element returned by Get hotel. D-EDGE reads it when the hotel is connected and keeps it until the hotel asks for the mapping to be redone.

## The three models

The same rate, on the same room, over the same dates, under each model. Restrictions travel on `planning` in every case; only the price moves.

**PerDay**

The default, applied when the attribute is absent.

* **Your platform stores** one price per room type, rate, and day.
* **Get hotel declares** nothing beyond rooms and rates.
* **Prices arrive** in the `unitPrice` attribute of `planning`, for the room's default occupancy.

```xml theme={null}
<rate currency="EUR" rateCode="BAR" rateName="BAR">
  <planning from="2027-03-01" to="2027-03-31" unitPrice="142.00"
            minimumStay="1" maximumStay="14" noArrival="false"
            noDeparture="false" isClosed="false" />
</rate>
```

**PerPerson**

* **Your platform stores** one price per room type, rate, day, and person count.
* **Get hotel declares** `minOccupancy` and `maxOccupancy` on every room. D-EDGE sends a price for every person count in that range.
* **Prices arrive** in one `occupancy` element per person count, carrying `personCount` and `unitPrice`.

```xml theme={null}
<rate currency="EUR" rateCode="BAR" rateName="BAR">
  <planning from="2027-03-01" to="2027-03-31" minimumStay="1"
            maximumStay="14" noArrival="false" noDeparture="false"
            isClosed="false">
    <occupancy personCount="1" unitPrice="100.00" isClosed="false" />
    <occupancy personCount="2" unitPrice="120.00" isClosed="false" />
  </planning>
</rate>
```

**PerOccupancy**

* **Your platform stores** one price per room type, rate, day, and adult and child combination.
* **Get hotel declares** `minOccupancy`, `maxOccupancy`, and the `occupancies` list on every room. D-EDGE prices exactly the combinations listed.
* **Prices arrive** in one `occupancy` element per declared combination, carrying `adultCount`, `childCount`, and `unitPrice`.

```xml theme={null}
<rate currency="EUR" rateCode="BAR" rateName="BAR">
  <planning from="2027-03-01" to="2027-03-31" minimumStay="1"
            maximumStay="14" noArrival="false" noDeparture="false"
            isClosed="false">
    <occupancy adultCount="1" childCount="0" unitPrice="100.00" isClosed="false" />
    <occupancy adultCount="1" childCount="1" unitPrice="105.00" isClosed="false" />
    <occupancy adultCount="2" childCount="0" unitPrice="120.00" isClosed="false" />
  </planning>
</rate>
```

Under `PerPerson` and `PerOccupancy`, an `occupancy` element without `unitPrice` is closed, with `isClosed="true"`. That flag closes one occupancy only; the `isClosed` on the `planning` element closes the whole room and rate, and the two are independent. Whatever the model, the price you receive is the final [sellable price](/overview/resources/glossary.md#sellable-price) for that room, rate, and day, meals included when the rate carries them. The full attribute list, and the meal plan detail, are on the [Planning updates](/channel-manager-api/build/reference/planning-updates.md) page.

## How D-EDGE picks each price

The hotel sets its room prices in D-EDGE in its own way, whatever model you declare. Every room type has a default occupancy, for instance 2 people, and the hotel sets one price per rate and day for it. The hotel may also set a price for alternative occupancies: 1 person, 3 people, 2 adults and 1 child. D-EDGE derives the prices your model asks for from that configuration, so you receive a price for every occupancy you declared, even when the hotel set prices for fewer.

| Your model | What D-EDGE sends | Where each price comes from |
| - | - | - |
| `PerDay` | One `unitPrice` per room, rate, and day. | The price of the room's default occupancy. Prices the hotel set for other occupancies are not sent. |
| `PerPerson` | One `occupancy` per person count, up to the room's `maxOccupancy`. | The price of the smallest hotel occupancy with at least that many adults. When no hotel occupancy reaches the count, the highest price the hotel set. |
| `PerOccupancy` | One `occupancy` per combination declared in Get hotel. | The price of the smallest hotel occupancy with at least as many adults, and at least as many people in total. When none fits, the combination reaches you closed, without a price. |

Three consequences worth knowing before you compare prices with a hotel:

* **The same price on several occupancies is normal.** A hotel with a price on its default occupancy only sends that price to every person count or combination. Under `PerPerson`, a room at 450 for its default occupancy of 4 reaches a platform with a `maxOccupancy` of 3 as 450 for 1, 2, and 3 people. A hotel with prices of 420, 430, and 440 for 1, 2, and 3 people reaches the same platform as 420, 430, and 440.
* **A gap is filled from above.** A person count the hotel has not set up takes the price of the next occupancy up and stays open. A person count the hotel has closed reaches you closed, with that same price for information. Under `PerOccupancy`, D-EDGE never computes a child price: 1 adult and 2 children take the price of the smallest hotel combination that holds them, for instance 2 adults and 1 child.
* **The default occupancy rules the rest.** When the hotel has set no price on its default occupancy, or has closed it, every occupancy of the room and rate reaches you closed, whatever the alternative occupancies say.

Under `PerPerson` and `PerOccupancy`, the `maxOccupancy` you declare must be reachable in D-EDGE: the hotel's default occupancy, or an occupancy it prices on every rate, must hold at least that many people. When it is not, D-EDGE does not send the update and reports an occupancy mismatch on its side, so the hotel can align the room configuration in one of the two systems.

Whether the hotel prices per room, per occupancy, or with per-person supplements in D-EDGE, the rules are the same: D-EDGE first resolves the hotel configuration into one price per occupancy, then applies them.

## Choosing a model

Derive the model from how your planning database stores prices, not from the richest option: a model your platform cannot store loses prices on your side. The trade-offs are worked out in [Best practices](/channel-manager-api/build/best-practices.md#declare-the-price-model-your-platform-really-uses).

## Changing the model

The model belongs to the mapping. If your platform changes how it stores prices, update your Get hotel response and ask the hotel to have the mapping redone by its D-EDGE contact. D-EDGE re-reads the configuration and switches the shape of the next updates. Nothing changes until that re-read happens.


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