Important Data Considerations

When integrating with the Travel Curious API, it’s important to note that not all data fields are guaranteed to be included in the API responses. The inclusion of data depends on the information Travel Curious receives from Operators or Ticketing Systems. However, when the data is shared, it often contains important information that should be utilised effectively to ensure a robust user experience and functionality.

• Validate Data Presence: When data is shared, ensure your application uses it effectively. This includes presenting important details to users (e.g., supplier addresses, attraction hours, or product-specific information) and leveraging it for enhanced functionality.
• Design for Flexibility: Check for data inclusion but also account for scenarios where specific fields may not be shared in the response. Ensure your application can adapt by implementing a logic that accommodates both cases - when the data is present and when it is not - without

Supplier Location vs. Product Location

Supplier head office addresses are found in the GET Suppliers response, while attraction-specific addresses are in the GET Products response.

Supplier Hours vs. Product Hours vs. Rate Hours

A Supplier can have hours details at all those 3 different levels or have the same values for all of them. It could be a product with the corresponding operating hours and then have rates under it with the specific hour times that the rate is valid for.

Rate minTravelers & maxTravelers

This field represents the minimum and maximum number of travelers to qualify for this rate which means the maximum number of tickets that can be purchased for this rate. The data is being mapped from the Supplier setup. This will prevent customers from selecting more than the allowed quantity and getting errors during Hold and Booking requests.

Rate travelerTypes, ageBand and modifier

Support list of ageBand to describe a particular age or occupation of a traveler type

• Ideally, being able to consume the name and modifier to support the full breadth of price/traveler types the operators provide. These could be things like EU_CITIZEN, MILITARY

• Minimally support all age bands in the specifications ADULT,ANY,CHILD,INFANT,SENIOR,STUDENT,YOUTH

  • The ANY type may be used instead of the above listed ageBand, if distinctions between age or occupation are not relevant to the product. It’s a generic ageband type used by some suppliers and it’s recommended to be supported, otherwise, a workaround needs to be done to map that value.

• Solve multiple instances of the same age band. There are instances where operators will send 2 prices for the same traveler type (ie 2 - ADULT). This typically means there is a difference in the name/modifier that makes it a different traveler type still limited to adults OR it means they’re running a special price for a limited time. You can:

  • Consume name/modifier and display both
  • Display only one lower or higher of the 2 prices

Freesale and Reserved

Being able to handle both types of product rates gives you, the Reseller, the flexibility to manage both general admission (FREESALE) and time-slot defined (RESERVED) types. This allows you to accommodate a broader range of use cases for different suppliers and their connected products.

Timezones and Datetime formats

To know the local timezone value, you should check the timezone field under the Rate (rates.hours.timezone). Within Travel Curious, we do a hierarchical check order to verify the rate, product, and supplier timezone, if not present at any of these levels Travel Curious defaults to UTC at that point.

Travel Curious Availabilities endpoint response start and end times will return the information in Zulu, with a value like 2023-10-06T11:00:00Z; check the timezone field on the rate response to convert availability into the appropriate timezone. If this conversion is not done, pricing and availability could return inaccurately, especially for those suppliers in a timezone that borders the end of day UTC.

Notification API

Travel Curious strongly recommends implementing the Reseller Notification API. This interface pushes notifications to resellers, indicating when data has changed through Travel Curious's APIs. Resellers can then update the appropriate objects within their own cache, reducing dependence on frequent cache updates.