Documentation

Booking Confirm Transfers logo icon

The confirm call creates new bookings for an activity product.

Since previous operations such as detail are providing a rateKey, almost all the information to confirm a booking is temporary stored in APITUDE for activities and it will be used when confirming a booking. It means that the process is simple. So, from a business perspective, the following information is needed to confirm a booking:

rateKey: The rate key identifies an activity, modality and rate. It’s returned in the detail response.
Language code (if needed)
Pickup (if the activity is an excursion)
Selected dates (from and to)
Personal data for the holder and paxes
Payment data (if the payment is going to be performed through APITUDE Payment Platform)

The confirmation response, is very similar to the booking detail response. From a business perspective, the following information is returned:

Booking number
Activity information (name, description, operational information, date, time and paxes)
If needed, a special voucher URL that needs to be provided to the final customer

Additionally, in the event that you need to connect with a payment platform to let some time for your customer to pay for the booking, a different approach can be followed:

Preconfirm: Stock and data is locked for 30 minutes.
Reconfirm: After you have finished with the payment you can confirm the booking.

See more details for two-step confirmations here.

Specifications

PUT https://api.test.hotelbeds.com/activity-api/3.0/bookings

Request

The confirm api call always returns the same structure, but it can be called with some optional parameters.

The following are some examples:

Confirm Request

The following is an example of a ticket confirmation request in a single step:

{
  "language": "en",
  "clientReference": "ABC12345 - ES",
  "holder": {
    "name": "John",
    "surname": "Smith",
    "title": "Mr",
    "email": "j.smith@hotelbeds.com",
    "address": "Cami Son Fangos 100",
    "zipCode": "07007",
    "mailing": true,
    "mailUpdDate": 1455547156925,
    "country": "ES",
    "telephones": ["123456789","123456798"]
  },
  "activities": [{
    "preferedLanguage": "en",
    "serviceLanguage": "en",
    "rateKey": "3ajeb1pcqslb8r850t2atsqk4d",
    "from": "2016-03-29",
    "to": "2016-03-29",
    "paxes": [
    {
      "age": 68,
      "name": "John",
      "surname": "Smith",
      "type": "ADULT"
    },
    {
      "age": 25,
      "name": "Margaret",
      "surname": "Smith",
      "type": "ADULT",
    },
    {
      "age": 7,
      "name": "Peter",
      "surname": "Smith",
      "type": "CHILDREN",
    }]
  }]
}

The relevant information in the example above is:

Holder: Personal data of the booking holder. If it is also a pax, his or her information is repeated below in the paxes list.
rateKey: Identifies the product or service to be booked.
serviceLanguage: Identifies the language in which the activity is going to be offered to the final customer.
from and to: Dates when the final customer is going to attend the activity. If the activity duration is 1 day, then from and to have the same value.
Paxes: List of paxes and pax type. The ages must match the ones provided in the detail api call. The pax list is optional. If the paxes information is not provided, then a list of paxes with the ages sent in the “detail” api call is returned.
Questions and answers: if there are questions returned in the “detail” api call, all question(s) will need an answer in the "confirm" request.

If the “detail” api call did not provide serviceLanguage or session, then it won’t be required in the booking confirmation request.

The following are the specs for a confirm request:

NAME	Type	DESCRIPTION
language	String	Language code to be used in the contents response.
clientReference	String	Text to be provided in the booking and stored in APITUDE along with other information. Use your booking number or expedient number or reference. Bookings can be retrieved by client reference. See the booking detail api call for information on how to retrieve a booking.
holder	Holder	Booking holder information element
holder/@name	String	Holder name
holder/@surname	String	Holder surname
holder/@title	String	Holder title (Mr, Ms, Miss)
holder/@email	String	Holder e-mail
holder/@address	String	Holder postal address.
holder/@zipCode	String	Holder zip code.
holder/@mailing	Boolean	True If the holder agrees to receive communications via e-mail.
holder/@country	String	Holder Country name
holder/@telephones	List	Booking holder telephones list
activities	List	Activities to be confirmed. More than one can be provided in the same confirmation.
activities/@answers	List	If the activity required some questions to be answered, then the answers for each question must be provided in the “answers” attribute.
activities/answers/question	Question	Question being answered
activities/answers/question/@code	String	Question code
activities/answers/question/@text	String	Question text. Not needed, but it can be provided.
activities/answers/question/@required	Boolean	Indicates if question is required. Not needed, but it can be provided in the request.
activities/answers/@answer	String	This is the answer to the question raised before in the @text attribute.
activities/@comments	List	List of comments provided by the final customer at the moment of confirming the booking.
@preferedLanguage	String	Indicates the language preferred of the activity among the ones provided (if provided) for the selected rate.
@serviceLanguage	String	Activity language code among the ones provided in the rate (if provided) for the selected rate.
@rateKey	String	Rate key to be confirmed taken from the detail api call.
@session	String	Session code among the ones provided (if provided) in the selected rate.
@from	String	Activity date from. Difference between date from and date to must be equals to the activity duration. Most common case of duration = 1 day, generates a date from and to with the same value. Format is yy-mm-dd.
@to	String	Activity date to. Difference between date from and date to must be equals to the activity duration. Most common case of duration = 1 day, generates a date from and to with the same value. Format is yy-mm-dd.
paxes	List	List of activity paxes. The paxes information is mandatory. However, if this was provided in the detail and not informed in the confirmation the list and distribution of paxes to be used will be the one used in the Detail. Otherwise if you use a new list of paxes in the Confirm the previous list will be replaced with the new one. See the link on the Detail call. At least the number of paxes and the pax type must match the information provided in the detail because changing that information could affect the activity price. The holder can be or not in the paxes list. If the holder is going to enjoy the activity, then he / she will appear two times: one in the holder section and another one in the paxes list.
paxes/@age	Integer	Pax age
paxes/@name	String	Pax name
paxes/@surname	String	Pax surname
paxes/@type	PaxType	Pax type (ADULT, CHILD) Paxes must be grouped by type, and all ADULTS must be informed before all CHILD (see example above)

Documentation

Dashboard Menu

Specifications

Request

Confirm Request