> ## 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. # Authentication > Credentials you define, carried two ways 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: | Model | Scope | Typical fit | | - | - | - | | **Hotel-level credentials** | One login and password per hotel | Platforms that isolate hotels as separate accounts | | **Master credentials** | One global login and password for all hotels | Platforms with a central account, and the only model that allows the all-hotels variant of [Get bookings](/channel-manager-api/build/reference/get-bookings.md) | 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: ```http theme={null} 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 `` element: ```xml theme={null} ... ``` The two POST requests also carry the same credentials in an `Authorization` header, as on the GET interfaces. Validate either the header or the `` 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](/channel-manager-api/build/guidelines/responses.md). ## 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](/channel-manager-api/get-certified/certification-steps.md#phase-two-live-certification), 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](/channel-manager-api/build/reference/booking-message.md#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](/overview/resources/contact-us.md) to rotate it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.