> ## 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.
# Planning updates
> D-EDGE pushes availability, prices, and restrictions
> [!NOTE]
>
> 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](/channel-manager-api/build/guidelines/authentication.md). The hosting model is described in [the introduction](/channel-manager-api/get-started/introduction.md#an-api-that-runs-on-your-endpoints).
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](/channel-manager-api/build/guidelines/requests.md). 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
**message** `element` *required*
The root element.
**child elements**
**authentication** `element` *required*
Your credentials: a `login` and a `password` attribute, each up to 50 characters. See [Authentication](/channel-manager-api/build/guidelines/authentication.md).
**inventoryUpdate** `element` *required*
The update itself.
**attributes and children**
**hotelId** `attribute · string` *required*
The hotel identifier or code, as declared in [Get hotel](/channel-manager-api/build/reference/get-hotel.md). Maximum 50 characters.
**room** `element · 1..n` *required*
One room type, identified by its `id` attribute (your room code, maximum 50 characters).
**child elements**
**inventory** `element · 0..n`
The availability part. When absent, the update concerns prices and restrictions only.
**child elements**
**availability** `element · 1..n` *required*
A date range of availability: `from` and `to` dates (inclusive, `YYYY-MM-DD`) and a `quantity` (0 to 99999), the number of rooms available on each day of the range for this room type. The three attributes are always present. Consecutive ranges may leave gaps between them.
**rate** `element · 0..n`
The prices and restrictions part for one rate.
**attributes and children**
**rateCode** `attribute · string` *required*
The rate identifier or code, as declared in Get hotel. Maximum 50 characters.
**rateName** `attribute · string`
The rate name, generally the same value as `rateCode`.
**currency** `attribute · string`
The rate currency, ISO code. When absent, the rate is not activated or mapped for this room on the D-EDGE side.
**mealPlanType** `attribute · enum`
The meal plan set up in D-EDGE for the rate: `BreakfastIncluded`, `HalfBoard`, `FullBoard`, or `AllInclusive`. Sent only when the meal plan feature is enabled for your connection, from your [questionnaire](/channel-manager-api/get-certified/questionnaire.md), and the hotel uses it. See [Meal plans](#meal-plans) below.
**planning** `element · 1..n` *required*
Prices and restrictions on a date range. Apart from `from` and `to`, all attributes are optional and independent: update exactly what is present. Consecutive ranges may leave gaps between them.
**attributes and children**
**from** `attribute · date` *required*
First day of the range, `YYYY-MM-DD`.
**to** `attribute · date` *required*
Last day of the range, included.
**unitPrice** `attribute · decimal`
The room price for the rate, per day, for the room's default occupancy. The number of decimals is not fixed: parse it as a decimal, do not assume two. Absent when the price model is `PerPerson` or `PerOccupancy` (prices then travel in `occupancy` elements), when no price is defined, or when the room and rate are closed.
**minimumStay** `attribute · integer`
Minimum stay in nights (1 to 99) to book the room and rate, applied to every day of the range.
**maximumStay** `attribute · integer`
Maximum stay in nights (1 to 99), same application.
**noArrival** `attribute · boolean`
Closed-to-arrival restriction. If your platform has no such notion, see the workaround in [Best practices](/channel-manager-api/build/best-practices.md#restrictions-you-do-not-support).
**noDeparture** `attribute · boolean`
Closed-to-departure restriction.
**isClosed** `attribute · boolean`
Open or closed to sale for the room and rate, over the range. Independent of the `isClosed` carried by each `occupancy`: `true` here closes the room and rate whatever the occupancy values say, and `false` here leaves each occupancy to its own flag.
**availability** `attribute · integer`
Availability for this room and rate combination (0 to 99999). Sent only when the connection is configured for per-rate availability, from your [questionnaire](/channel-manager-api/get-certified/questionnaire.md).
**occupancy** `element · 0..n`
Per-occupancy prices, present when the price model is `PerPerson` or `PerOccupancy`.
**attributes**
**personCount** `attribute · integer`
The person count the price applies to (1 to 99). Present with `PerPerson`, one element per count between the room's `minOccupancy` and `maxOccupancy`.
**adultCount** `attribute · integer`
The adult count the price applies to (1 to 99). Present with `PerOccupancy`, together with `childCount`, one element per combination declared in Get hotel.
**childCount** `attribute · integer`
The child count, with `PerOccupancy`.
**unitPrice** `attribute · decimal`
The room price for this occupancy, per day, over the range. The number of decimals is not fixed. When absent, the occupancy is closed and `isClosed` is `true`.
**isClosed** `attribute · boolean` *required*
Open or closed to sale for this occupancy only. It does not reopen a room and rate closed at `planning` level: an update can carry `isClosed="true"` on the `planning` and `isClosed="false"` on its occupancies, and the room and rate stay closed.
**mealPlan** `element · 0..2`
The meal price detail, for information: a `paxType` attribute (`adult` or `child`) and a `price` attribute, the price of one meal for that pax type, with no fixed number of decimals. Present only when the meal plan feature is enabled and the rate carries a separated meal plan price. Which pax types count towards `unitPrice` depends on the price model: see [Meal plans](#meal-plans) below.
```xml PerDay theme={null}
```
```xml PerPerson theme={null}
```
```xml PerOccupancy theme={null}
```
```xml Inventory only theme={null}
```
```xml Meal plan theme={null}
```
## Your response
Answer `200 OK` with the [message envelope](/channel-manager-api/build/guidelines/responses.md): `` when the update is applied, `` 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 `` 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 `` on extreme values and raise an alert on your side if you want them checked.
```xml Success theme={null}
```
```xml Failure theme={null}
```
## 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](/channel-manager-api/build/reference/get-hotel.md); 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](/channel-manager-api/build/guidelines/price-models.md) page, and [How D-EDGE picks each price](/channel-manager-api/build/guidelines/price-models.md#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](/overview/resources/glossary.md#sellable-price).
How D-EDGE adds the meals to the room price depends on the price model your platform declared in [Get hotel](/channel-manager-api/build/reference/get-hotel.md). 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:
| Price model | Meals added | Example |
| - | - | - |
| `PerDay` | The adult meal price, times the room's default occupancy (the one set on the D-EDGE side). Only the adult price is used. | A Suite with a default occupancy of 3 and a room price of 300 arrives as `unitPrice="360.00"`: three adult meals. |
| `PerPerson` | The adult meal price, times the `personCount` of each `occupancy` line. Every person counts as an adult, so only the adult price is used. | Room prices of 100 for 1 person and 120 for 2 arrive as 120 and 160. |
| `PerOccupancy` | The adult meal price times `adultCount`, plus the child meal price times `childCount`, on each `occupancy` line. | A room price of 105 for 1 adult and 1 child arrives as 137: one adult meal and one child meal. |
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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.