Where do I find it?
CONFIGURATION > SYSTEM & SETUP > Booking Webhooks > Asynchronous booking notification webhook
What does it mean?
Overview
Use the modified_booking webhook when an external system needs to know that a booking has changed in TourCMS.
For example, a customer messaging tool may need the latest travel details after an itinerary update, or an operations system may need to refresh its records after an upsell or customer detail change.
Because booking edits can involve several steps, TourCMS does not always send this notification automatically. Instead, trigger it once the booking is fully updated, so the receiving system can retrieve the final version.
What it is
The modified_booking webhook is a TourCMS feature that lets you notify configured supplier subsystems or integrations when a booking has been changed in TourCMS.
When the webhook is triggered, the external system can use the booking information to pull in the latest version and update its own records or customer-facing view.
What it isn’t
Most OTA-initiated changes that come via TourCMS are handled as a cancellation and rebooking. Manual changes made by your staff are also not pushed back to OTAs. For that reason, this webhook is mainly useful for specific integration workflows where an external subsystem needs to be told that a booking has been modified.
If you are unsure whether your setup needs this webhook, please contact our support team before enabling it.
What should I do?
If your subsystem has implemented the modified_booking webhook, open or create the asynchronous booking notification webhook and tick the modified_booking event:
Next, open the booking in TourCMS. After you have made the booking changes that you want to share with the subsystem, go to the Docs & comms tab. You will see a section for notifying integrators:
Select Notify integrators. You can then review or choose which subsystem, or subsystems, should be notified of the booking change:
When you select Send, TourCMS sends the webhook notification to the selected subsystem.
As with other asynchronous webhooks, TourCMS will retry sending the webhook if the subsystem is temporarily unavailable.
You can check what happened to the webhook in the booking audit trail:
Triggering the booking_modified webhook via API
If you modify bookings in TourCMS using the API and want to trigger the webhook after your changes are complete, use the Booking webhook trigger endpoint (currently, only modified_booking is accepted).
For example, you might add components, remove components or update customer details using the API. Once all changes have been completed, call this endpoint so the subsystem can retrieve the latest booking version.
Good to know
The webhook tells the subsystem that a booking has changed; the subsystem is responsible for retrieving and processing the latest booking details.
Trigger the notification after you have finished making all booking changes, not during each individual edit.
TourCMS will retry asynchronous webhook delivery if the receiving subsystem is temporarily unavailable.
This feature is most useful for supplier integrations and specialist workflows, rather than standard OTA change handling.
FAQs
➕ When should I trigger the modified booking webhook?
Trigger it after you have finished making all the changes that the subsystem needs to know about. This helps avoid sending a notification before the booking is in its final updated state.
➕ Does this automatically update OTAs?
No. Manual changes made by your staff in TourCMS are not pushed to OTAs by this webhook. It is intended to notify configured subsystems or integrations.