Price models

The price model is the one setting your platform declares in Get hotel and that D-EDGE applies in every planning update 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
PerPerson
PerOccupancy

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.

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

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.

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

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.

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

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.

Get started

Build

Get certified

Resources

The three models

How D-EDGE picks each price

Choosing a model

Changing the model

​The three models

​How D-EDGE picks each price

​Choosing a model

​Changing the model

The three models

How D-EDGE picks each price

Choosing a model

Changing the model