Declare the price model your platform really uses
ThepriceModel you return in Get hotel 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 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 thecurrency attribute in every Get hotel 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 supportingnoArrival, 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:
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 oneroom 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’sextras element; an extra sold on the whole booking enters the booking-level one. The distinction matters because the 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 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 is the fast lane, Get bookings the safety net; implement both and let D-EDGE deduplicate. Treat the push<success> as “received”, never as “integrated”: the Confirm bookings 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
<success>, whether2.00or340000000.50: the hotel set them, and a price check on your side belongs in an internal alert. - On a partially wrong update, answer
<failure>with the precise error for the invalid part, and still apply the valid parts: failed updates are not resent, and a blank<failure>on a large synchronisation stops the stream. - Tolerate the byte order mark, the namespace declarations, and the loose content types described in Requests.