Here we list common mistakes you should not repeat. If you have any question regarding them please do not hesitate to contact our support team.
- DO NOT make hotel mappings in the test environment (that is, when under the evaluation or pre-production plan).
- DO NOT send a CheckRates request for every rateKey in the availability response, only for those needed (rateType RECHECK). For rateKeys with BOOKABLE rateType, only send a CheckRates request if you need extra info like RateComments.
- DO NOT send more than one rateKey in one CheckRates operation. Despite being possible, is better to do it separately, as it will improve the error control in your side (i.e.: In a CheckRates operation with multiple rateKeys, an error valuating one rateKey will result in error for the entire request.), and some of Hotelbeds's external suppliers do not allow valuation of multiple rates at the same time. Even if you send multiple keys, DO NOT send a CheckRates request with rateKeys of both RECHECK and BOOKABLE.
- DO NOT send a CheckRates together with a booking request. If you need to send a CheckRates, first analyze its response in case it has an error and only if it's completion code was 200, then you can proceed to the confirmation.
- Always take into account the Completion code of the responses. If you receive a 400 error code check your requests, you are sending something wrong. If you receive a 500 error code that means that the product is not available anymore, you must restart your booking process from the beginning. In both cases, do not try to send the same request again, you will receive the same error until you change your request message. For more information about the completion codes, review our API ERRORS.
- Remember that the correct workflow to make a booking is the following:
1) Send ONE Availability request
2) if rateType == RECHECK then send ONE CheckRates Request
3) Send ONE Booking request.
It is never needed to send more than one availability request (or CheckRates) to make one booking. If you feel that you need to do so in order to adapt your workflow to ours, please contact us.
- Your code must be prepared to accept non-breaking changes in the API: we might do those changes at any time, and that should not break your integration.