The prebook service validates that the searched fare is still valid for booking, and also provides a token with an expiration date, which is required to complete the booking. This service validates that the searched fare is still valid. Only active affiliates can use this service.
To continue to the payment step, use the field from the response: prebook_id
The following section describes part of the response structure
Extended_Info Structure:
In this structure, the information that may be returned includes ‘Exchange Policies’ (change and cancellation policy), ‘Important Data’ (information on required documents such as visas, vaccinations, etc.), and/or ‘Hints’ (a list of mandatory information that must be provided to complete the booking).
exchange_policies
Describes the change and cancellation rules applicable to the quoted product, to display them clearly in the UI and support decisions (e.g., enable/disable actions). Product indexes:
- K0: Activities
- F0: Flights
- H0: Hotels
Common schema:
| Field | Description |
|---|---|
| product_type | ticket, flight, hotel |
| product_title | descriptive title of the product |
| header | brief description of the policy (optional; more common in Activities) |
| footer | additional policy details (optional; common in Flights) |
| ranges | list of intervals with: |
| lable: explanation of the interval/condition | |
| percentage: penalty percentage (if applicable) | |
| conditions | product-specific rules for changes/cancellations |
| description (activities/hotels) or title (flights) | |
| question_and_answer: Q&A for common cases (optional) | |
| disclaimers | important notices (optional) |
| title (optional) | |
| description | |
| summary (common in flights) | operational summary |
| operations_summaries | |
| disclaimers: additional clarifying notes |
important_data
Is returned only for the flight flow and consists of two substructures:
- routes: requirements related to each itinerary location (e.g., destination or connection).
- travelers: requirements that apply to passengers.
Both routes and travelers share the same fields:
| Field | Description |
|---|---|
| location | IATA code of the locations |
| location_type | type of location; one of 'ORIGIN', 'DESTINATION', 'STOPOVER', or 'CONNECTION' |
| country_code | country code of the destination |
| requirements | list of requirement items, each with: |
| id: requirement ID | |
| req_type: requirement type; one of 'doc', 'entry_requirement', 'passport', 'return_proof', 'ticket', 'visa' | |
| description: short title of what is being requested | |
| link: source URL for the requirement (not inclued in the example response because it rarely appears) |
hints
Is returned for all flows. It defines how to construct and validate the booking form using a hierarchical model with node types and validation rules.
• Top-Level Fields
- modality: identifies the payment modality
- payment_option: payment option associated with the selected modality
- hint: root container that includes the substructures form, context_information, and validations
• Node Model
- hint_type: indicates the node type (object/parent, array, or scalar field)
- validations: rules to be satisfied at the node (defined by the API contract)
- nested elements: nodes can contain other nodes, forming a hierarchical schema
• Form Structure Note
- Each node in form includes its own hint_type and validations.
• Context Information (hint.context_information)
- client_ip
- user_agent
- Includes its own hint_type and validations.
• Validations (hint.validations)
- List of rules to enforce across nodes.
- Apply them at object, array, and field levels before submitting the form.