Skip to main content
Four of the five interfaces are requests D-EDGE makes to your endpoints. This page sets the conventions those messages follow, and the standards your endpoints must meet to receive them.

​
Content type

Everything is XML over HTTPS.
  • What D-EDGE sends: the GET requests (Get hotel, Get bookings) carry Accept: application/xml, text/xml and no body, so no Content-Type; the POST requests (Planning updates, Confirm bookings) carry Content-Type: application/xml; charset=utf-8.
  • Accept requests whether they declare application/xml, text/xml, or no content type: parse the XML body regardless of the header.
  • Every request carries Accept-Encoding: gzip, deflate: you may compress your responses, which helps on Get bookings when a window holds many bookings.
  • On the POST interfaces, the XML is posted as the raw request body, not as a form field.
  • Your responses must declare Content-Type: application/xml and contain XML only. An HTML error page or a plain-text message breaks the exchange.
Messages D-EDGE sends can start with a byte order mark (BOM). Make sure your XML parser tolerates it: a parser that does not expect the BOM fails on the very first character of the message.
The <message> root of the updates D-EDGE sends also carries two namespace declarations, xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" and xmlns:xsd="http://www.w3.org/2001/XMLSchema". They carry nothing for you: the elements themselves have no namespace. The examples on this portal leave them out; your parser must accept them.

​
Formats

Date ranges (from/to attributes) are inclusive on both ends: an update from 2027-03-01 to 2027-03-03 covers three days.

​
Identifiers are yours

Every hotel, room, and rate identifier in every message is the code your platform declared in Get hotel. D-EDGE stores the mapping and translates internally; your system never sees a D-EDGE identifier, except the D-EDGE booking reference returned by Confirm bookings. Identifiers are limited to 50 characters (20 for booking identifiers). When the configuration changes on your platform (a room or rate is added, renamed, or removed), tell the hotel, and the hotel asks D-EDGE to redo the mapping. D-EDGE does not re-read your configuration automatically.

​
Updates are deltas

Planning updates carry only what changed. Two rules follow:
  • A message may contain availability only, prices only, restrictions only, or any mix. Treat every price and restriction value as independently optional. Only the identifiers, the date ranges, the quantity of each availability range, and the isClosed flag of each occupancy are always present.
  • An absent attribute means “do not touch this value”, never “reset it”. Update exactly what the message contains for the hotel, room, rate, occupancy, and days it names, and nothing else.
The updateType your platform declares per room and rate in Get hotel also shapes what D-EDGE sends: a combination declared Inv only ever receives inventory, for example.

​
Volume and timing

Your endpoints must hold up to real production traffic:
  • Answer in less than 5 seconds. If applying an update takes longer, accept it, answer, and process asynchronously. The exception is Get bookings: a window can hold many bookings, so D-EDGE waits up to 30 seconds for that response.
  • Expect large messages. When a hotel is connected, or its configuration changes, D-EDGE sends an initialisation stream covering the hotel’s full planning: hotels manage a sliding window of up to 2 years, generally split into one message per month, sometimes more.
  • Expect updates at any time. Whenever a price, an availability, or a restriction changes in D-EDGE, an update leaves within minutes, 15 at most.
  • D-EDGE pulls your bookings every few minutes, every 5 by default, and can query several hotels in parallel.

​
Your endpoint standards

The checklist your four endpoints must meet:
  • HTTPS with a valid, trusted certificate, TLS 1.2 or higher.
  • XML responses only, always 200 OK, errors inside the message envelope; 5xx only when your service is genuinely down. See Responses.
  • Basic Auth (GET interfaces) or the <authentication> element (POST interfaces) validated on every call. See Authentication.
  • Able to absorb the initialisation volume and answer within 5 seconds (30 seconds for Get bookings).