Skip to main content

​
Getting started

Start with the mock environment, which needs no credentials and no agreement. When you know what you want to build, submit a partnership enquiry on d-edge.com. The partnership team reviews your request and gets back to you within a few days. From there, you go through the six steps of the integration journey, from your first tests to the rollout.
Yes. Import the API collections into Postman or Insomnia and run any request against the mock environment, with no credentials. When D-EDGE delivers your credentials, set each API’s baseUrl variable to the live base URL. On the Channel Manager API, most interfaces run on your endpoints, so the collection plays D-EDGE. Its requests go to a mock standing in for your server, then to your own server once you set channelManagerApi.yourBaseUrl, as its Quick start shows.
Four OAuth 1.0 values for the pricing and Booking Engine APIs: consumer key, consumer secret, token, and token secret. The Gift Shop API uses a single API key, sent as the X-API-KEY header. The CRM API uses OAuth 2.0 client credentials: a client ID, a client secret, and the token endpoint that issues your bearer tokens. D-EDGE also delivers the identifier of the entity your integration works on. The base URL of the environment is delivered alongside. The Channel Manager API works the other way round: you define the credentials D-EDGE uses to call your endpoints, and D-EDGE only issues the credentials of its Push bookings endpoint. See each API’s Authentication page for the details.

​
Choosing the right API

Each API solves a distinct shape of question:
  • Channel Manager API: a hotel’s availability, prices, and restrictions pushed to your platform, and your bookings sent back. Right for OTAs, wholesalers, tour operators, and any distribution system with its own planning database.
  • Best Price API: cheapest available offer across stay dates. Right for guest-facing pricing surfaces (calendars, listings, “from” prices).
  • Quotation API: every bookable room and rate combination for a known stay. Right for booking funnels and chatbots.
  • Daily Rates API: full daily breakdown in one call. Right for nightly sync pipelines and back-office dashboards.
  • Booking Engine API: the full direct booking funnel in one stateful session. Right for building a hotel’s direct booking experience end to end.
  • Gift Shop API: a hotel’s online gift shop, from catalogue to payment. Right for voucher storefronts and gifting experiences.
  • CRM API: the guest profiles a hotel or group holds in the D-EDGE CRM. Right for guest data sync, personalisation, and privacy workflows.
See Explore our APIs for a side-by-side comparison.
The pricing APIs (Best Price, Quotation, Daily Rates) are stateless: each call is self-contained and returns prices or availability. The Booking Engine API is stateful: you open a session, then search, build a basket, quote, and confirm across several calls that share that session. Use the pricing APIs to display and compare offers; use the Booking Engine API to take the booking. The Gift Shop API follows the same stateful model for the hotel’s gift shop.
Yes. A booking engine typically pairs Best Price (entry-point pricing) with Quotation (offer comparison). A revenue-management tool typically pairs Daily Rates (sync) with Best Price (guest-facing surfaces). A direct booking experience can pair Best Price (entry-point pricing) with the Booking Engine API (the funnel from search to confirmation). A hotel website can pair the Gift Shop API (the voucher storefront) with the Booking Engine API (the funnel where a gift card is spent). A guest experience platform can pair the CRM API (the guest profiles) with the Booking Engine API (the funnel where the guest books).

​
Channel Manager API

You do, for four of the five interfaces. D-EDGE calls your Get hotel, Planning updates, Get bookings, and Confirm bookings URLs with the credentials you defined. The only D-EDGE-hosted endpoint is Push bookings, which your system calls with credentials D-EDGE issues. See An API that runs on your endpoints.
The push makes integration immediate; the pull guarantees that nothing is lost when a push fails. Both are required, and D-EDGE deduplicates: a booking that arrives through both channels is integrated once. The Confirm bookings message then tells you each booking is really in. See Best practices.
D-EDGE reads errors from the XML body and only parses the body of a 200 OK. Errors travel inside the <message> envelope as a <failure> with a type and a message, still under 200 OK; a 5xx is reserved for a service that is genuinely down. A <failure> on a planning update also means the update is not resent, so reserve it for messages you could not apply. See Responses.
The one that matches how your planning database stores prices: PerDay for one price per room and day, PerPerson for one price per person count, PerOccupancy for one price per adult and child combination. D-EDGE keeps the model for the life of the connection and shapes every planning update from it, so choose from your data rather than from the richest option. See Price models.
Because the hotel set a price on its default occupancy only in D-EDGE. Under PerPerson and PerOccupancy, D-EDGE fills each occupancy you declared from the smallest hotel occupancy that can hold the guests, so a hotel with a single price sends that price everywhere. Hotels with prices on alternative occupancies send distinct prices. The rules and worked examples are in How D-EDGE picks each price.
The unitPrice of a planning update is always the total room price, meals included. When the meal plan feature is enabled, the rate carries a mealPlanType and the mealPlan elements give the price of one adult or child meal, for information. What D-EDGE adds to the room price depends on the price model. Under PerDay, it adds the adult meal price times the room’s default occupancy; under PerPerson, the adult meal price times the person count of each occupancy line; under PerOccupancy, the adult and child meal prices times the adult and child counts. Infants never count. See Meal plans.
Not supporting noArrival is acceptable: D-EDGE tells hotels the restriction is not available on your platform, which can limit the rates or hotels opened to you. There is a workaround. When you receive noArrival="true", set your minimum stay to the highest value your system accepts, 99 for instance, instead of the minimumStay sent in the message. No stay can start on that day, so it behaves as closed to arrival. See Restrictions you do not support.
No. The Channel Manager API carries availability, prices, restrictions, and bookings. Descriptive content (hotel, room, and rate descriptions, photos) and cancellation policies stay on your platform by design. A booking can carry the policy that applied to it as free text, in the <distributor> comments of the booking message. See What the API covers.
In less than 5 seconds on Get hotel, Planning updates, and Confirm bookings. If applying an update takes longer, accept it, answer, and process it asynchronously. Get bookings has 30 seconds, because a busy window can hold many bookings. See Volume and timing.
An update your endpoint refuses with a <failure> is not resent, and during a full synchronisation D-EDGE may stop the rest of the stream. A 5xx is acceptable only when your service is genuinely down. Keep outages short, and once your endpoint is back, contact us to agree how to resynchronise the hotels concerned. See Always 200 OK.
Up to two years of planning per hotel, usually split into one planning update per month, sometimes more. D-EDGE sends it when a hotel is connected or its mapping is redone, so size your endpoint for that stream from the start. See Volume and timing.
D-EDGE routes your booking flow through its PCI environment when your platform sends cards. The card number is replaced by a token and the verification code by 000 before the booking enters the D-EDGE platform. The real card goes to the D-EDGE PCI vault, where it is read or passed on under strict rules. The detection covers the whole message, so a card number or verification code written into a comment or any other element is replaced too, and so is a value that only looks like one. See Card data.
As on every API, your D-EDGE Connectivity Project Manager runs it. On this API the tests run in two phases: the test scenarios against your test environment first, then the whole connection in production conditions with Push bookings. Because D-EDGE calls the endpoints you host, the scenarios are published in advance, and your questionnaire decides which ones apply. See Certification steps.
It depends on the number of test sessions your integration needs. In phase one, D-EDGE reports the scenarios that failed after each session, you fix them, and D-EDGE runs the session again. Phase two opens once phase one passes. Certification steps states how many sessions each phase allows.
Yes. The Channel Manager API test scenarios collection runs the published scenarios against your endpoints, in Postman or Insomnia, and names every check after its scenario. Point its URL variables at your test environment and fill in your own room and rate codes. Run the folders in order, and leave out the scenarios your platform does not support.
Your four endpoints do. You hand over your test URLs for both test phases, then your production URLs before the pilot, under the same credential model. The Push bookings URL and its Basic Auth credentials do not: D-EDGE issues them in phase two, and they stay the same through production. See Certification steps.

​
Booking Engine API

A session has a limited lifetime. You can set a custom duration with the X-AVP-SessionDuration header when you create the session. When a call returns 400 with Code: InvalidSessionId, the session has expired: create a fresh one and replay the guest’s context. See Best practices.
State-changing calls (POST, PATCH, DELETE) are not idempotent, so do not blindly retry them: a retry can add a room twice or confirm a booking twice. Retry only when you are sure the previous call never reached the server, reconcile the basket with the basket endpoint first, and re-quote right before confirmation. See Best practices.
D-EDGE hosts and handles payment. Accepting a quote returns a redirectionUrl to a D-EDGE-hosted page where the guest enters their card, so you never touch card data. After payment, the guest returns to a confirmation. See Best practices.
Ask the room search for alternatives through the X-AVP-Properties header: the party split across rooms, or a longer or shorter stay that unlocks a restricted rate. For a hotel group, you can also search the other hotels nearby. See Alternative availability.
Yes, with the Hotel Domain feature enabled. The post-payment redirect lands on the hotel’s domain, and GET /v2/booking/{sessionId}/confirmation returns the stay, customer, room, and payment details for your own page. Fetch it on the redirect rather than polling. See Branded confirmation page.
Yes. Read the active public promotion, including a flash-sale countdown, with GET /v2/{sessionId}/promotion, and unlock a private rate or offer by seeding the code into context.promoCode when you create the session. The session scope then reports which rates the code granted. See Promotional campaigns.
Yes. The funnel is stateful, so you can capture the guest’s context and basket and bring them back with a deep link. If the session is still alive, retrieve the basket and re-quote; if it has expired, open a new session from the saved context and rebuild the basket. See Abandoned booking recovery.

​
Gift Shop API

Every product carries a usage field. Direct is a value voucher: the beneficiary spends it on the hotel’s or group’s online booking engine, where the code deducts its value from the total at payment; its price always appears on the voucher. Indirect is a service, such as a spa session: the beneficiary redeems the code with the shop owner, at the hotel or within the group, which marks it as used in the D-EDGE platform; its price can be hidden. See Two kinds of products.
Yes. The beneficiary enters a value voucher’s code on the payment page of the hotel’s booking engine, and the code deducts its value from the booking total. This also holds for a booking funnel built with the Booking Engine API, since its payment page is hosted by D-EDGE. See Gift card to direct booking.
No. The Gift Shop API authenticates with a single API key, sent as the X-API-KEY header on every request. D-EDGE delivers it with the shop’s configuration. See Authentication.
It depends on the sendTo choice made in the cart: the voucher goes by email to the beneficiary the shopper designated, or to the shopper themselves. The shopper always receives the purchase confirmation, and on Indirect products the voucher document can hide the price (a Direct voucher always shows its value). See Voucher for a friend.

​
CRM API

The workspace that holds the guest profiles you work on: a hotel or a group, identified by a UUID that D-EDGE delivers with your credentials. Every CRM API route on a guest or a segment is scoped to an entity, and your token decides which entities you can read and write. See Requests.
Four origins feed a profile as the guest’s journey unfolds: the booking arrives through the D-EDGE platform, the PMS sends the identity, the guest adds their own details, and the hotel staff notes preferences during the stay. Every attribute keeps its origin in a from field, and your integration writes its own contributions the same way. See Sourced attributes.
Merge guests compares the profiles you list and merges them when their similarity reaches a threshold you control, and Compute merge confidence gives you that similarity before you decide. The merged profile keeps its sources in composedWith, and reading a source identifier afterwards returns the merged profile, so the identifiers you stored keep working. Unmerge a guest splits it back apart when the match turns out to be wrong. See Best practices.
The way to honour a guest’s removal request is Anonymise a guest, which strips the profile of its personal data. For communication preferences rather than removal, a profile carries per-channel opt-out flags you can read and write. See Best practices.
Merging guests and computing a merge confidence run in the background, so the call answers as soon as the work is accepted. The location header points at a task: read it until its status reaches completed, and take the score or the merged profile’s identifier from its result. See Responses.
Read the profile back with Get a guest. Creating and updating a guest answer with an empty body and a location header. An attribute whose value the API does not accept is left out and the status code stays 200, so the response alone does not confirm what landed. See Best practices.

​
Authentication

On the OAuth 1.0 APIs, three common causes:
  • Wrong credentials: confirm you’re using the values delivered by D-EDGE for the environment you’re hitting.
  • Clock drift: OAuth signing includes a timestamp. If your server clock drifts more than five minutes from D-EDGE’s, signatures reject. Sync with NTP.
  • Reused nonce: every request must carry a unique nonce. Generating a UUID per call avoids replay rejections.
On the Gift Shop API, a 401 means the X-API-KEY header is missing, invalid, or does not give access to the operation. See its Authentication page.On the CRM API, a 401 means the bearer token is missing, invalid, expired (tokens live 300 seconds), or without access to the entity. Request a fresh token and check the entity identifier. See its Authentication page.On the Channel Manager API, D-EDGE authenticates to your endpoints with the credentials you defined. When they do not match, answer with the BadAuthentication failure (type 3) inside a 200 OK response, never with a 401. See its Authentication page.
OAuth 1.0 with HMAC-SHA1 is the authentication standard across D-EDGE’s existing connectivity, including PMS, RMS, and channel-manager integrations that have been running for years. The priority on those APIs is keeping the partner ecosystem stable. Newer services adopt the newer standard as they arrive: the CRM API authenticates with OAuth 2.0 client credentials. The Channel Manager API sits outside this question: its endpoints run on your side, and D-EDGE presents the credentials you defined, as HTTP Basic Auth or inside the XML message.

​
Data and traffic

The pricing and booking APIs read live data from the CRS at request time. There is no D-EDGE-side cache that hides recent changes: what you see in the response is what’s bookable now. The Gift Shop API reads the shop’s configuration and catalogue as the hotelier maintains them in the D-EDGE platform. The CRM API works on the guest profiles as they stand in the D-EDGE CRM at request time. The Channel Manager API works the other way round: D-EDGE pushes each planning change to your platform within minutes, 15 minutes at most.
Yes, and they scale with your partnership scope. Discuss your expected traffic during the kick-off call so D-EDGE sizes the connection correctly. If you’re rolling out a TV spot, a flash sale, or any event likely to multiply your normal volume by ten or more, contact us a few days ahead.
Yes, and you should: caching keeps your interface fast and reduces load on both ends. The right TTL depends on the use case: the pricing APIs, the Booking Engine API, and the Gift Shop API each carry caching guidance on their Best practices page. The Channel Manager API needs no cache on your side: D-EDGE pushes each change to your planning database, so what you hold is already the current planning.

​
Operations

The Contact us page lists the right address for each type of partner. When reporting an error, include the error identifiers from the response, which let the team correlate your report with D-EDGE’s internal traces. Send the identifiers of the API you call:
  • Pricing APIs (Best Price, Quotation, and Daily Rates): the traceId.
  • Booking Engine API: the Message and Code.
  • Gift Shop API: the problem details fields (title, detail, and instance).
  • CRM API: the error code and message.
  • Channel Manager API: the <failure> type and message, with the hotel and booking identifiers.
It depends on the API. On the Channel Manager API, the property requests the connection to your platform from the D-EDGE platform, and you accept the request. D-EDGE then builds the mapping from your Get hotel response, the property validates it, and D-EDGE starts the initial synchronisation. On the other APIs, the property requests activation from its D-EDGE account manager, then D-EDGE enables API access and sends you the access details for that property. See Connect a new hotel for both processes.
On the Channel Manager API, email your D-EDGE Connectivity Project Manager at least a month before you ship. Anything that touches the connection counts: new fields, another price model, a new endpoint URL, a version change, or a change of infrastructure. D-EDGE reviews the change with you and updates the connection where it needs to. See Change your implementation.
SLA terms are set in your partnership agreement. The platform runs on cloud-native infrastructure with horizontal scalability and is monitored continuously by the partnership team. For the specific targets that apply to your integration, refer to your contract or ask your D-EDGE Connectivity Project Manager.

​
Compliance

Yes. D-EDGE is PCI DSS certified across the booking and payment flows and GDPR compliant across the platform. Data processing terms are part of the partnership agreement. Card details can travel in Channel Manager API booking messages, which is why every endpoint on that API must run on HTTPS with TLS 1.2 or higher. When a partner sends cards, the booking flow runs through the D-EDGE PCI environment: see Card data.

​
Localisation

The APIs return prices in any currency configured at the property level. Specify the currency in the request filter.currency (Best Price), filter.currencies (Quotation, Daily Rates), or the session’s display.currency (Booking Engine API). Gift Shop API prices come back with each catalogue product, in the currency the shop sells in. On the Channel Manager API, each hotel’s prices arrive in the currency your Get hotel response declares for that hotel, which must be the hotel’s currency in D-EDGE.
No. Prices come back in a currency configured at the property level, and the currency filters select among those currencies rather than convert. Requesting a currency the property does not sell in returns an empty response. To display prices in the guest’s currency, convert at display time with a public daily rate source, as shown in the Multi-currency price display use case.