> ## 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. # Best practices > Price models, payment amounts, and a clean booking flow Patterns that make a Channel Manager API integration certifiable first time, drawn from what the D-EDGE team checks during testing. ## Declare the price model your platform really uses The `priceModel` you return in [Get hotel](/channel-manager-api/build/reference/get-hotel.md) shapes every planning update for the life of the connection, so derive it from how your planning database stores prices rather than from what seems richest. A platform storing one price per room and day has no use for `PerOccupancy`: it would receive combinations it cannot store. The reverse is worse: a per-person platform declared `PerDay` receives one price for the default occupancy and nothing else. The three models and what each one requires are on the [Price models](/channel-manager-api/build/guidelines/price-models.md) page. Along the same line, if your platform has no rate notion, declare a single `rate` with a default code rather than inventing rate lines: one honest price line beats a fake rate structure. You can connect as many rate plans as your platform manages. Which ones a hotel opens to your platform is agreed between you and the hotel; D-EDGE never arbitrates that list. ## Always return the currency Return the `currency` attribute in every [Get hotel](/channel-manager-api/build/reference/get-hotel.md) response, next to `priceModel` and `updateType`. It fixes the currency of every planning update you will receive for the hotel, so you can check prices against it. Without it, D-EDGE sends prices in the currency configured for the hotel on its side, and a difference with your platform's currency surfaces only when a hotel's prices come out wrong on your side. Return the currency the hotel prices in on D-EDGE, and refuse anything else with `IncorrectPriceCurrency`. ## Restrictions you do not support Not supporting `noArrival`, `noDeparture`, `minimumStay`, or `maximumStay` is acceptable: D-EDGE tells hotels those restrictions are not available on your platform, which can limit the rates or hotels opened to you. The restriction really worth supporting is `isClosed`, the open or closed to sale switch. For `noArrival` there is a workaround: closed to arrival matches a high minimum stay. When you receive `noArrival="true"` and have no such notion, set your minimum stay to the highest value your system accepts (99, for instance) instead of the `minimumStay` sent in the message. It does not suit every hotel's management, but it prevents unwanted bookings. ## Fill the amounts for your payment model The four booking amounts (`totalAmount`, `paidAmount`, `dueAmount`, `payableAmount`) describe who has collected what. Three common models, for a booking of 150: | Model | totalAmount | paidAmount | dueAmount | payableAmount | | - | - | - | - | - | | Customer pays at the hotel | 150 | 0 | 150 | 0 | | You collect the payment, the hotel invoices you | 150 | 150 | 0 | 150 | | The hotel collects the prepayment through your platform | 150 | 150 | 0 | 0 | Mixed cases (deposits, partial prepayments) combine the same logic: `paidAmount` is what the customer has paid, `dueAmount` what remains at arrival, `payableAmount` what the hotel charges back to you. Discuss your exact model with your D-EDGE Connectivity Project Manager before certification: it conditions how the connection is set up. Prices are **gross (sellable) by default**: hotels set up commission-included prices in D-EDGE. If your model works on net prices, raise it with your D-EDGE Connectivity Project Manager rather than adapting amounts yourself, and use `sellType` and the commission attributes to state what your amounts contain. ## Split multi-room bookings into room elements A booking of several rooms of the same type fits either one `room` element whose stays carry a `quantity` above 1, or one `room` element per physical room. Prefer the split: it lets you name the guests of each room and give each room its own guest count, which the hotel's PMS will thank you for. Two doubles for three guests reads better as two `room` elements holding two and one guests than as a quantity of 2 with three guests attached. The same goes for guest details generally: one `guest` per person in the room is expected, each with its `ageRange` and even nameless. D-EDGE counts the elements by `ageRange` to know how many adults, children, and infants sleep in the room. Real names and birth dates on top are what make the reservation usable downstream. If your system does not split first and last names, put the whole name in `lastName`. ## Put extras where they belong An extra attached to a room enters the room's `extras` element; an extra sold on the whole booking enters the booking-level one. The distinction matters because the [price formulas](/channel-manager-api/build/reference/booking-message.md#extra-price-formulas) count guests differently: `guest` elements of the room on one side, `paxCount` of the booking on the other. Extra beds have no dedicated field: model them as a room-level extra. Whatever the level, every extra amount counts towards `totalAmount`, and every extra attribute is mandatory. A missing `unitPrice`, `extraCode`, `quantity`, `inclusive`, or `pricingType` drops the extra from the integration, with only a warning on the push response and nothing at all on the pull. ## Keep the booking lifecycle coherent * One booking, one `id`, for ever: modifications and cancellations reuse the identifier of the creation. * Date each action with its own UTC timestamp, and return a booking in the [Get bookings](/channel-manager-api/build/reference/get-bookings.md) window of its **latest** action only. * Keep stays contiguous and dates identical across the rooms of one booking: split anything else into separate bookings, or it risks non-integration downstream, in particular towards the hotels' PMSs. * If your platform supports modifications and cancellations, send them as soon as it knows them, through both channels, like creations. ## Ride the two booking channels properly [Push bookings](/channel-manager-api/build/reference/push-bookings.md) is the fast lane, [Get bookings](/channel-manager-api/build/reference/get-bookings.md) the safety net; implement both and let D-EDGE deduplicate. Treat the push `` as "received", never as "integrated": the [Confirm bookings](/channel-manager-api/build/reference/confirm-bookings.md) acknowledgement is the only integration signal. If you automate retries, resend an unconfirmed booking after 15 minutes, not before. ## Check availability before you sell Planning updates leave D-EDGE within minutes of a change (15 at most), and every booking you send is accepted: no availability check happens at integration time. Verify the availability your planning database holds at several points of your booking funnel, especially at the final confirmation step. Simultaneous bookings from two systems remain rare, and hotels know the model, but your funnel is the only guard. ## Engineer for the traffic pattern * Answer every call in less than 5 seconds: acknowledge, then process asynchronously if you need more time. Get bookings alone has 30 seconds, since a window can hold many bookings. * Absorb the initialisation stream (up to 2 years of planning, split by month) without refusing messages. * Accept ranges that start in the past and ignore the past days: D-EDGE works in UTC, so an update sent around midnight can reach a server in another time zone dated the day before. * Accept extreme prices with a ``, whether `2.00` or `340000000.50`: the hotel set them, and a price check on your side belongs in an internal alert. * On a partially wrong update, answer `` with the precise [error](/channel-manager-api/build/guidelines/responses.md) for the invalid part, and still apply the valid parts: failed updates are not resent, and a blank `` on a large synchronisation stops the stream. * Tolerate the byte order mark, the namespace declarations, and the loose content types described in [Requests](/channel-manager-api/build/guidelines/requests.md). ## Prepare for certification Certification follows the [integration journey](/overview/get-started/your-integration-journey.md) as on every API. On this API the tests run in two phases. D-EDGE first tests the four interfaces you host on your test environment, then the whole connection in production conditions, Push bookings included. Build your test hotel to the requirements of the hand-over checklist from the start, and answer the [questionnaire](/channel-manager-api/get-certified/questionnaire.md) from how your platform works today. The process and every scenario are in [Certification steps](/channel-manager-api/get-certified/certification-steps.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.