Booking Confirm Request

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)
  • Session 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

Live URL: https://api.hotelbeds.com/activity-api/3.0/bookings

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

Method: PUT

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",
    "session": "AFTERNOON",
    "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.
  • Session: Identifies the available session selected by 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<String>

Booking holder telephones list

activities

List<Activity>

Activities to be confirmed. More than one can be provided in the same confirmation.

activities/@answers

List<Answer>

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<String>

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<Pax>

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)

Docs Navigation