Quick start

Your first milestone on the Channel Manager API is an endpoint on your side, ready to answer D-EDGE. This guide walks you through the smallest working piece of the integration: the Get hotel interface, the endpoint D-EDGE calls first to read a hotel’s configuration from your system. Once it answers correctly, you have proven the whole mechanic of the API: an endpoint you host, a request D-EDGE sends, an XML response you return.

Prerequisites

A signed partnership agreement, and a dedicated D-EDGE Connectivity Project Manager. Both come out of the integration journey.
A server that can expose an HTTPS endpoint with a valid certificate and TLS 1.2 or higher.
A test hotel configured on your platform, with at least three room types and three rates: the test scenarios need them, so build it that way from the start.

There are no credentials to receive at this stage: you define the credentials D-EDGE will use to call your endpoints, and hand them over with your URLs. See Authentication for the two credential models.

Expose your Get hotel endpoint

Serve an HTTPS URL that accepts a GET request with a hotelCode query parameter and Basic Auth credentials. This is the request D-EDGE sends:

GET /getHotel?hotelCode=1234&lang=EN HTTP/1.1
Authorization: Basic dGVzdGhvdGVsOnRlc3RwYXNzd29yZA==
Accept: application/xml, text/xml
Host: yourdomain.com

The Authorization header carries the login and password you defined, Base64-encoded. The lang parameter is optional: room and rate names in English are all that is required.

Return the hotel configuration

Answer with 200 OK, a Content-Type: application/xml header, and the hotel’s rooms and rates. Here is a minimal valid response for a hotel on the PerDay price model, with one room and two rates:

<?xml version="1.0" encoding="utf-8"?>
<message>
  <rooms hotelId="1234" hotelName="My test hotel" priceModel="PerDay" currency="EUR">
    <room code="CLA" name="Classic Room">
      <rate code="BAR" name="Flexible Rate" updateType="PRI" />
      <rate code="NR" name="Prepayment Rate" updateType="PRI" />
    </room>
  </rooms>
</message>

Three attributes in this response shape the whole integration:

priceModel decides how prices will arrive in every future planning update, for the life of the connection. Choose it to match how your platform stores prices. See Price models.
currency announces the currency your platform expects for the hotel. Always return it: without it, D-EDGE sends prices in its own configured currency and raises no error.
The code attributes are your identifiers. D-EDGE stores them as the mapping and uses them in every message from then on: you never handle D-EDGE identifiers, apart from the booking reference returned by Confirm bookings.

Test it yourself

You do not need D-EDGE to test. The test scenarios collection runs D-EDGE’s own scenarios against your endpoints. The API collections carry the calls of the documentation: set channelManagerApi.yourBaseUrl to your server and send the Get hotel request. Or simulate the call with any HTTP client and check your own response:

curl --request GET \
  --url 'https://yourdomain.com/getHotel?hotelCode=1234&lang=EN' \
  --user 'testhotel:testpassword' \
  --header 'Accept: application/xml, text/xml'

Check that the response is XML only (no HTML wrapper), that the status is 200 OK, and that a wrong password returns the failure envelope rather than an HTTP error:

<?xml version="1.0" encoding="utf-8"?>
<message>
  <failure type="3" message="BadAuthentication">
    <comment><![CDATA[Credentials are invalid for this Hotel (1234)]]></comment>
  </failure>
</message>

Returning errors inside a 200 OK response is the rule across the whole API. See Responses.

Hand over your endpoints

When your four interfaces are ready, hand them over to your D-EDGE Connectivity Project Manager with the credentials you defined, your test hotel, and your questionnaire. The checklist is in Certification steps, which then runs the test scenarios against your endpoints in two phases.Once certified, each hotel joins as described in Connect a new hotel. D-EDGE calls Get hotel to build the mapping, then sends the initial synchronisation, up to two years of planning. From there, updates flow whenever something changes, and the booking interfaces close the loop.

Common issues

Symptom	Likely cause	Where to look
D-EDGE reports an unreadable response	The endpoint returned HTML or plain text instead of XML	Responses
A push response is plain text instead of XML	An unexpected D-EDGE error; handle it like a `203` `InternalError` and retry later	Push bookings
Updates stop after an error	Your endpoint returned `<failure>`, which can stop the processing, and failed updates are not resent	Responses
Parsing breaks on the first characters of a message	Messages D-EDGE sends can start with a byte order mark (BOM)	Requests
Prices arrive in an unexpected shape	The `priceModel` returned in Get hotel does not match how your platform stores prices	Price models

Next steps

Reference

Every interface: the request we send, the response we expect.

Guidelines

Credentials, message conventions, error handling, and price models.

Best practices

Price models, payment amounts, and a clean booking flow.

Certification steps

The hand-over, the two test phases, and the pilot.

Get started

Build

Get certified

Resources

Prerequisites

Expose your Get hotel endpoint

Return the hotel configuration

Test it yourself

Hand over your endpoints

Common issues

Next steps

Reference

Guidelines

Best practices

Certification steps

​Prerequisites

Expose your Get hotel endpoint

Return the hotel configuration

Test it yourself

Hand over your endpoints

​Common issues

​Next steps

Reference

Guidelines

Best practices

Certification steps

Prerequisites

Common issues

Next steps