Árni Gunnar Ragnarsson·September 25, 2026
#26.39 - Trip price examples now published through api connectors

Your website can now show real prices for a trip without a customer starting a booking. Static trips carry pre-calculated prices for a set of party combinations: A couple, a family of four, a solo traveller and those prices are published through the api on both trip lists and trip detail. You define a default set of parties once for the whole workspace, new trips pick it up automatically, and you can push an updated set onto existing trips whenever you like. Prices that haven't been calculated yet, that can't be booked, or that sit past a booking cutoff are held back, so a customer never sees a figure they can't act on. The calculator is kept in step with the cart, so the price on the page is the price in the basket.
Lists can now spell dates and identifiers the way each destination expects. Date columns are available in ISO, day-first, month-first, GDS and compact formats, and identifier columns can be written as entered, digits only, or in canonical form — the same way name columns already worked. If your workspace declares its identifiers as Icelandic kennitala, lists can read a traveller's birth date straight out of the identifier when the birth-date field is empty. Saved lists keep working exactly as they are, and identifiers with leading zeros are protected when you open an export in a spreadsheet.
Trips can now apply their participant limits through the workspace API, not just the booking form. A new switch in the trip's Participants conditions is off by default; turn it on and orders and availability checks made through the API are refused when the party falls outside the limits, using the same wording customers see on the booking form. The limits are shared with connected systems, and price examples for parties outside the limits are hidden from the API while staying visible to you in admin. Trips also publish planned and booked participant counts where a planned capacity is set, so a site can show how full a trip is.
Cancelling an order is now a settlement rather than a status flip. You pick a reason from a fixed list, optionally retain part of what the customer paid as a cancellation fee, and the fee is booked as a proper line with its own VAT treatment — all in one operation that also releases the inventory. Retained fees are reportable revenue. Alongside that, the order payments page now shows the masked card number beside each card payment, and View Details opens a panel with the card brand, expiry, funding type, issuing country, 3-D Secure result and authorization code where the gateway reported them.
Elsewhere: the group portal has been rebuilt to match the order portal, with the same branded header, travel dates, total price and outstanding balance, and it now lists only real bookings — drafts and cancelled orders no longer appear on a page anyone with the link can open. Portal dates show exactly as entered no matter where the customer is reading from, so a 07:40 departure reads 07:40 in Copenhagen and Los Angeles alike, and the booking flow now shows the full departure-to-return range. Trip data exports now carry six sheets covering orders, participants, bookings, payments, booking participants and question answers, including completed and locked orders. Booking pages tell customers what went wrong when something fails instead of spinning, and every dropdown in admin is now fully keyboard-operable, with a search box on longer lists. The ticket detail panel lets you step between all Amadeus tickets on an order without closing it.
Also improved: passport numbers are available as a list column, clients can be saved without an email address, spreadsheet exports defuse text that would otherwise run as a formula, order confirmation emails no longer show empty booking sections, trip pages and global search are noticeably faster, and Straumur, Stripe and Rapyd checkout pages now open correctly from the order payment page.