Skip to main content
D-EDGE sends HTTP POST requests to the URL you provide, with the XML message as the raw body and the credentials inside the message. The hosting model is described in the introduction.
Planning updates are the heart of the connection: whenever a hotel’s planning changes in D-EDGE, following a manual change or a new booking, an update reaches your endpoint within minutes. A single message targets one hotel, and can cover any mix of room types, rates, and days. Its date ranges are not necessarily contiguous: one message can update the first week of March and the last week of April, with nothing in between. Your endpoint must accept updates at any time. It must also absorb the large ranges of the initialisation stream sent when a hotel is connected or reconfigured: up to 2 years of planning, usually split by month. On request, that stream can start with a pass that closes every room type you host, before the real planning arrives. Updates are deltas: an absent element or attribute means “do not touch this value”, as set out in Requests. Ranges can also start in the past, typically the day before. D-EDGE dates its planning in UTC, so an update sent around midnight may carry a date already past on a server running in another time zone. Accept these updates and ignore the past days rather than refusing the message.

​
The message we send

​
element
required
The root element.

​
Your response

Answer 200 OK with the message envelope: <success> when the update is applied, <failure> with the right error code when it is refused. When a message mixes valid and invalid parts (an unknown rate next to a known one, for instance), answer <failure> with the error code of the invalid part. A failure tells D-EDGE the update was not processed, and a refused update is not resent. D-EDGE still recommends applying the valid parts on your side, to limit the gaps between the two systems. A price is never a reason to refuse: D-EDGE forwards what the hotel set, whether 2.00 or 340000000.50. Answer <success> on extreme values and raise an alert on your side if you want them checked.

​
How prices arrive per price model

The price sits either in the unitPrice attribute of planning or in its occupancy children, depending on the priceModel your platform declared in Get hotel; the examples above show one message per model. Read prices according to the model you declared rather than inferring it from each message: the model does not change between updates. The three models are compared on the Price models page, and How D-EDGE picks each price explains where each price comes from when the hotel set prices for fewer occupancies than your model asks for.

​
Meal plans

When the meal plan feature is enabled for your connection and the hotel separates meal prices from room prices, the rate carries a mealPlanType and each planning may carry mealPlan elements. The unitPrice you receive is still the total room price, meals included: the mealPlan elements only tell you, for information, the price of one meal per adult or child. Whether the feature is enabled or not, the price you receive is always the final sellable price. How D-EDGE adds the meals to the room price depends on the price model your platform declared in Get hotel. In every case the meal price is per person and per day, the adult price always counts, and infants never do. With an adult meal at 20 and a child meal at 12: The Meal plan example above follows the PerDay rule: the Superior Room has a default occupancy of 2, so a room price of 102 plus two adult meals at 20 gives the unitPrice of 142.