Authentication

On the four interfaces you host, you define the credentials and D-EDGE presents them on every call. Only the Push bookings endpoint, hosted by D-EDGE, uses credentials issued by D-EDGE.

​

Choose a credential model

You provide credentials under one of two models: Whichever model you choose, the same credentials cover Get hotel, Planning updates, Get bookings, and Confirm bookings. Login and password are each limited to 50 characters.

​

How credentials travel

The transport depends on the HTTP method of the interface:

• On the GET interfaces (Get hotel, Get bookings), D-EDGE sends the credentials in an Authorization header, HTTP Basic Auth:
  GET /getHotel?hotelCode=1234 HTTP/1.1
  Authorization: Basic dGVzdGhvdGVsOnRlc3RwYXNzd29yZA==
  
  For a login testhotel and a password testpassword, the header value is Basic followed by testhotel:testpassword in Base64.
• On the POST interfaces (Planning updates, Confirm bookings), the credentials open the XML message itself, in the <authentication> element:
  <message>
    <authentication login="testhotel" password="testpassword" />
    ...
  </message>
  
  The two POST requests also carry the same credentials in an Authorization header, as on the GET interfaces. Validate either the header or the <authentication> element: both hold the same login and password.

Validate the credentials on every request. When they do not match, return the BadAuthentication failure (type 3) inside a 200 OK response, as described in Responses.

​

Push bookings: credentials from D-EDGE

The Push bookings endpoint is on the D-EDGE side, so this time the credentials come to you. The D-EDGE team gives you a dedicated login and password, and your system sends them as HTTP Basic Auth on each push. You receive them, with the push URL, in the second certification phase, once D-EDGE has set up the connection on its side; the first phase runs without Push bookings. These credentials are specific to this interface, and your system must be able to update them when the D-EDGE team rotates them.

​

Transport security

• Every endpoint you expose must be HTTPS, with a valid and trusted certificate, on TLS 1.2 or higher. D-EDGE is PCI DSS compliant and requires the same transport discipline from its partners.
• The Push bookings endpoint is HTTPS for the same reason.
• If your firewall filters inbound traffic, ask your D-EDGE Connectivity Project Manager for the D-EDGE IP addresses to allow. D-EDGE requests carry no User-Agent header: do not filter inbound traffic on it.
• Resolve the Push bookings host by DNS on every call, and do not pin its IP address or whitelist its domain on your outbound traffic. The address behind the URL changes when D-EDGE enables the PCI routing of card data, and that can happen after your integration is live.
• Store the credentials D-EDGE gives you for Push bookings in your secret manager or environment variables, not in source code. If a credential leaks on either side, contact us to rotate it.