We are happy to announce our latest TripBuilder release. Please see these release notes for the most significant changes. Let us know if you have any questions, feedback, or ideas for features or improvements!

We've made further accessibility improvements across TripBuilder pages to strengthen WCAG 2.1 Level AA compliance.

Interactive elements including map controls, calendar dropdowns, hotel/room selection buttons, and activity cards now support full keyboard navigation with visible focus indicators.

We have also replaced non-semantic div elements with proper button elements, corrected heading hierarchies across detail pages, and enhanced image carousels with accessible navigation controls.

We improved travel documentation clarity by displaying the full date range for multi-day accommodation stays. When customers view their travel documents, hotel bookings that span multiple days now show the complete date range in parentheses alongside the accommodation name, making it immediately clear how long each stay lasts and reducing confusion when activities occur during the accommodation period.

Tour operators can now select Trinidad and Tobago Dollar (TTD) as a frontend selling currency for customer-facing pricing.

Key Benefits:

We have extended our failure notification system to include Marketplace Operators, giving them visibility when components fail during bookings or cancellations made by their customers.

Previously, only Tour Operators received these failure emails, leaving Marketplace Operators unaware of issues affecting their marketplace customers.

We've increased booking timeouts for ConnectAPI (accommodations) and TravelGateX accommodation suppliers from their previous hard-coded values to 105 seconds, reducing false timeout failures when suppliers experience temporary delays.

Bookings that take 60-100 seconds to process will now complete successfully instead of timing out prematurely. This should directly reduce booking failure rates during peak periods or when suppliers experience performance degradation.

Configuration: These timeout settings are configurable via environment variables, allowing operations teams to adjust supplier-specific timeouts.

We've introduced automatic retry protection when booking or booking change failures occur. When a partial failure happens, customer care users (including admins) now encounter a 5-minute cooldown period (configurable per instance in settings) before they can retry the booking. During this time, a countdown timer displays in the UI, and if retry is attempted (and the discard action on a booking change), a modal explains that retry protection prevents system overload and recommends checking component booking status with the supplier or Marketplace Operator directly. The timer resets to 5 minutes after each subsequent failed retry attempt and persists across page refreshes and navigation.

This protection helps maintain platform stability during high-load scenarios while reducing the risk of duplicate bookings caused by rapid retry attempts or users failing to check the status of the component at source before attempting retry.

Additionally, if an itinerary contains only components sourced from a Marketplace Operator, the retry action becomes unavailable entirely, prompting the Tour Operator to contact the Marketplace Operator to understand the individual booking statuses.

NOTE - Please always check the status of a component that has failed to book with the supplier offline, before using the ‘Retry’ action.

More information can be found in our double booking prevention guide here.