Sep 16, 2025 | TripBuilder Release Notes v356

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 have reintroduced the feature flag to control the display of availability re-check functionality in TA tools. This allows hiding the feature to re-check the availability in Planner from TAs as needed.

We've resolved a filtering issue in Customer Care where itineraries with "Cancellation In Progress" status were not appearing when users applied the "In Progress" filter. This omission affected the visibility and management of itineraries that were actively being cancelled, making it difficult for Customer Care teams to track and manage ongoing cancellation processes.

The "In Progress" filter now correctly includes itineraries with "Cancellation In Progress" status alongside other in-progress statuses like "Booking In Progress" and "Booking Change In Progress". This ensures that all active processes, whether they involve new bookings, changes, or cancellations, are properly captured when

Customer Care users filter for work-in-progress items.

This fix provides Customer Care teams with complete visibility into all active itinerary processes, enabling better workload management and ensuring that cancellations in progress receive appropriate attention and follow-up during the Customer Care workflow.

The ‘discard’ action on an itinerary can have far-reaching consequences if not used correctly. For example, if during a booking change a component has failed to book or cancel during completion, discarding that itinerary will remove the component from TripBuilder but won’t update the status in a supplier system (without manual verification). This can leave the user with an itinerary showing no component, making it easy to end up with a double booking, or no booking at all.

To reduce these use cases we have updated 'discard' action permissions after failed booking changes. Only admin users can discard failed booking changes in 'change initiated' status. Customer Care users are notified if they do not have permission.

Please use this action with caution admin users, and always perform manual verification after component failures before using the itinerary actions.

The ‘Manual Processing’ status is used to define itineraries where one or more components have failed to book - meaning it is a partial booking (payment is taken and some components have booked) that needs further action before it can be a fully confirmed booking.

The status label "Manual Processing" has been replaced by the more accurate

"Action Required" for all customers and market segments. The new label is shown in red for increased visibility and consistency in Customer Care and on the Agent Centre. For data and reporting purposes we have made no changes - the renaming is purely a UI change.

The Promo Code API allows external systems to create and manage promotional codes directly in TripBuilder without accessing the Customer Care interface. Each code can be configured with percentage or fixed-amount discounts, validity periods, usage limits, minimum spend requirements, and geographic restrictions.

To use the API, you'll need the SettingsApi role enabled for your account and your API credentials for authentication. The API provides endpoints to create codes (which auto-generate unique codes if not specified), list existing codes with filtering options, retrieve code details, update validity dates or limits, and activate or deactivate codes through workflow actions. Codes start in "Draft" status and must be published to become usable at checkout.

All API-created codes appear immediately in the Customer Care interface marked as "API Created," maintaining full visibility for your support team who can still modify or deactivate them as needed.

Full documentation is available at https://docs.tripbuilder.app/settings-api-v1.html#tag/Settings/operation/create-promocode

Fixed an issue where passenger names containing accented or special Latin characters were rejected by the AERTiCKET Hub integration.

The system now automatically transliterates non-ASCII characters in passenger names to their closest Latin alphabet equivalents before submission to AERTiCKET Hub.

Examples:

This ensures successful flight bookings while preserving the original names in the platform for customer records and documentation.