> ## 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. # FAQ > Common questions, answered ## Getting started > **How do I get access to the APIs?** > > 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](https://www.d-edge.com/partner-contact/). 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](/overview/get-started/your-integration-journey.md), from your first tests to the rollout. > **Can I try the APIs before I have credentials?** > > Yes. Import the [API collections](/overview/resources/api-collections.md) into Postman or Insomnia and run any request against the [mock environment](/overview/resources/glossary.md#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](/channel-manager-api/get-started/quick-start.md) shows. > **What credentials does D-EDGE deliver?** > > 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 > **Which API fits my use case?** > > Each API solves a distinct shape of question: > > * **[Channel Manager API](/channel-manager-api/get-started/introduction.md)**: 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](/best-price-api/get-started/introduction.md)**: cheapest available offer across stay dates. Right for guest-facing pricing surfaces (calendars, listings, "from" prices). > * **[Quotation API](/quotation-api/get-started/introduction.md)**: every bookable room and rate combination for a known stay. Right for booking funnels and chatbots. > * **[Daily Rates API](/daily-rates-api/get-started/introduction.md)**: full daily breakdown in one call. Right for nightly sync pipelines and back-office dashboards. > * **[Booking Engine API](/booking-engine-api/get-started/introduction.md)**: the full direct booking funnel in one stateful session. Right for building a hotel's direct booking experience end to end. > * **[Gift Shop API](/gift-shop-api/get-started/introduction.md)**: a hotel's online gift shop, from catalogue to payment. Right for voucher storefronts and gifting experiences. > * **[CRM API](/crm-api/get-started/introduction.md)**: 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](/overview/get-started/explore-our-apis.md) for a side-by-side comparison. > **How is the Booking Engine API different from the pricing APIs?** > > 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](/overview/resources/glossary.md#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. > **Can I use multiple APIs in the same integration?** > > 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 > **Who hosts the endpoints?** > > 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](/channel-manager-api/get-started/introduction.md#an-api-that-runs-on-your-endpoints). > **Why do I need both Get bookings and Push bookings?** > > 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](/channel-manager-api/build/best-practices.md#ride-the-two-booking-channels-properly). > **Why must my endpoints return 200 OK on errors?** > > D-EDGE reads errors from the XML body and only parses the body of a `200 OK`. Errors travel inside the `` envelope as a `` with a type and a message, still under `200 OK`; a `5xx` is reserved for a service that is genuinely down. A `` on a planning update also means the update is not resent, so reserve it for messages you could not apply. See [Responses](/channel-manager-api/build/guidelines/responses.md). > **Which price model should I declare?** > > 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](/channel-manager-api/build/guidelines/price-models.md). > **Why do I receive the same price for several occupancies?** > > 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](/channel-manager-api/build/guidelines/price-models.md#how-d-edge-picks-each-price). > **How are meal plans included in the prices D-EDGE sends?** > > 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](/channel-manager-api/build/reference/planning-updates.md#meal-plans). > **My platform has no closed-to-arrival restriction. What should I do?** > > 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](/channel-manager-api/build/best-practices.md#restrictions-you-do-not-support). > **Does D-EDGE send room descriptions, photos, or cancellation policies?** > > 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 `` comments of the booking message. See [What the API covers](/channel-manager-api/get-started/introduction.md#what-the-api-covers). > **How fast must my endpoints answer?** > > 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](/channel-manager-api/build/guidelines/requests.md#volume-and-timing). > **What happens when my endpoint is down or refuses an update?** > > An update your endpoint refuses with a `` 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](/overview/resources/contact-us.md) to agree how to resynchronise the hotels concerned. See [Always 200 OK](/channel-manager-api/build/guidelines/responses.md#always-200-ok). > **How much data does the initial synchronisation send?** > > 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](/channel-manager-api/build/guidelines/requests.md#volume-and-timing). > **What happens to the card details I send in a booking?** > > 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](/channel-manager-api/build/reference/booking-message.md#card-data). > **How does certification work on the Channel Manager API?** > > 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](/channel-manager-api/get-certified/certification-steps.md). > **How long does certification take?** > > 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](/channel-manager-api/get-certified/certification-steps.md) states how many sessions each phase allows. > **Can I check my endpoints before D-EDGE tests them?** > > Yes. The [Channel Manager API test scenarios collection](/overview/resources/api-collections.md#channel-manager-api-test-scenarios) 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. > **Do my endpoint URLs change between certification and production?** > > 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](/channel-manager-api/build/reference/push-bookings.md) 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](/channel-manager-api/get-certified/certification-steps.md). ## Booking Engine API > **How long does a session last?** > > 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](/booking-engine-api/build/best-practices.md). > **How do I avoid creating duplicate bookings?** > > 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](/booking-engine-api/build/best-practices.md). > **Does D-EDGE handle payment, or do I collect card details?** > > 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](/booking-engine-api/build/best-practices.md). > **What can I offer when the requested stay is unavailable?** > > 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](/booking-engine-api/resources/use-cases/alternative-availability.md). > **Can I show the booking confirmation on the hotel's own website?** > > Yes, with the [Hotel Domain](/overview/resources/glossary.md#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](/booking-engine-api/resources/use-cases/branded-confirmation-page.md). > **Can I run promotions or apply a promo code?** > > 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](/booking-engine-api/resources/use-cases/promotional-campaigns.md). > **Can I recover an abandoned booking?** > > 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](/booking-engine-api/resources/use-cases/abandoned-booking-recovery.md). ## Gift Shop API > **What is the difference between the two kinds of gift shop products?** > > 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](/gift-shop-api/get-started/introduction.md#two-kinds-of-products). > **Can a gift card pay for a booking?** > > 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](/gift-shop-api/resources/use-cases/gift-card-to-direct-booking.md). > **Does the Gift Shop API use OAuth 1.0?** > > 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](/gift-shop-api/build/guidelines/authentication.md). > **Who receives the voucher after payment?** > > 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](/gift-shop-api/resources/use-cases/voucher-for-a-friend.md). ## CRM API > **What is an entity?** > > 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](/crm-api/build/guidelines/requests.md). > **Where does a guest profile's data come from?** > > 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](/crm-api/build/guidelines/requests.md#sourced-attributes). > **How do I handle duplicate profiles?** > > **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](/crm-api/build/best-practices.md). > **Can I delete a guest profile?** > > 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](/crm-api/build/best-practices.md). > **Why does a merge answer with an empty body?** > > 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](/overview/resources/glossary.md#task): read it until its `status` reaches `completed`, and take the score or the merged profile's identifier from its `result`. See [Responses](/crm-api/build/guidelines/responses.md). > **How do I know what an update stored?** > > 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](/crm-api/build/best-practices.md). ## Authentication > **I'm getting 401 errors. What should I check?** > > 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](/gift-shop-api/build/guidelines/authentication.md) 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](/crm-api/build/guidelines/authentication.md) 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](/channel-manager-api/build/guidelines/authentication.md) page. > **Why OAuth 1.0 and not OAuth 2.0?** > > 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 > **How real-time is the data?** > > The pricing and booking APIs read live data from the [CRS](/overview/resources/glossary.md#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. > **Are there rate limits?** > > 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](/overview/resources/contact-us.md) a few days ahead. > **Can I cache API responses?** > > 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 > **How do I get support?** > > The [Contact us](/overview/resources/contact-us.md) 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 `` type and message, with the hotel and booking identifiers. > **How do I connect a new hotel once my integration is live?** > > 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](/overview/run-your-integration/connect-a-new-hotel.md) for both processes. > **I want to change my integration. What should I do?** > > 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](/channel-manager-api/get-certified/certification-steps.md#change-your-implementation). > **What's the SLA?** > > 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 > **Are the APIs GDPR and PCI DSS compliant?** > > 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](/channel-manager-api/build/reference/booking-message.md#card-data). ## Localisation > **Which currencies are supported?** > > 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. > **Can the APIs convert prices into another currency?** > > 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](/best-price-api/resources/use-cases/multi-currency-price-display.md) use case. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.