Session lifecycle
Reuse one session across the funnel
Open a session once, then carry itssessionId through search, basket, quote, and confirmation. Do not open a new session per call. Refine the existing session with the PATCH endpoints (context, filters, display, and sort order) as the guest narrows their choice.
Match the session duration to the journey
A session has a limited lifetime. Set a duration that fits your funnel with theX-AVP-SessionDuration header when you create the session: long enough for a guest to browse and check out without losing their basket, short enough to release stale state.
Recover from an expired session
When a call returns400 with Code: InvalidSessionId, treat the session as gone. Create a fresh one, replay the guest’s context, and rebuild the basket. Build this recovery path in from the start rather than assuming sessions last forever.
Funnel integrity
Follow the funnel order
Read availability before building the basket, and quote the basket before confirming. Skipping a step can surface stale prices or let a guest reach checkout on an offer that is no longer available.Re-quote right before confirmation
Prices and availability shift while a guest fills in their details, through inventory changes, currency, or tax updates. Call Get a quote again immediately before you accept the quote, and surface any change before taking payment. This is the single most effective way to avoid the price mismatches that drive booking disputes.Read the sales terms from the API
Fetch the sales terms through Get sales terms rather than hardcoding them. A property can override the default terms in its booking engine configuration, so the value returned by the API is the only reliable one.Hand off payment to D-EDGE
Payment is hosted and handled by D-EDGE, so you never touch card details. Accepting the quote returns aredirectionUrl: send the guest there to pay, then bring them back to a confirmation. With the Hotel Domain feature enabled, that return can land on the hotel’s own website. There, your page reads the booking through Get a booking confirmation, and the return URL can act as a webhook to trigger your own post-booking steps.
Performance
Request only what you display
The description and search endpoints accept display headers (X-AVP-Properties, X-AVP-DescriptionType, and X-AVP-PictureTemplates), and the hotel and room searches accept pagination (pageNumber, pageSize). Ask only for the fields, picture templates, and page sizes your interface shows. Smaller responses land faster on the guest’s screen.
Cache descriptions, not availability
Descriptions of rates, rooms, and hotels change rarely, so cache them. Availability, quotes, and promotions change constantly: never cache them, and always read them live before showing a price or taking a booking.Resilience
Retry transient errors with care
Retry transient failures (network blips, timeouts, and occasional5xx) on GET calls with exponential backoff. State-changing calls are not idempotent (see Requests): before retrying a booking step, reconcile the basket with Retrieve the basket so you do not add a room or confirm a booking twice.
Plan for slow or unreachable calls
Decide upfront how long your interface waits for a response and what it shows past that point. Make the choice deliberately rather than letting the network decide.Log the error message and code
When a call fails, capture theMessage and Code from the response body in your logs. They let the partnership team pinpoint the failure when you report it.