This specification defines the payloads for notifications sent by Redeam's API. Use this document to build the server-side endpoints that will process these incoming HTTP POST requests.
You will only receive alerts for the events you have subscribed to using the Notification Registry API. These events include real-time updates for channel bindings, product and availability changes, and booking statuses.
Channelbinding
Channel Binding notifications
Receive a channelbinding notification.
This endpoint receives channel binding notifications when Suppliers, Products or Rates are bound to or unbound from your channel.
Use this webhook to synchronize your local catalog with updates to Product visibility.
The exact path is defined in your registered Notification Rule configuration and does not need to match /channelbinding
.
The notification payload includes an operation
field to indicate whether the change was a created
, updated
,
or removed
event.
created
: Triggered when a new binding is established at the Product level. This could be the first Rate being bound or when the entire Product is newly bound.- In a
created
case, you should call all sets of Redeam's APIs to sync the data in your system, this includes GET Suppliers, GET Products, GET Rates, GET Availabilities and GET Price Schedule.
- In a
updated
: Triggered when changes are made to bound Products and Rates, such as Rate-level adjustments within an already-bound Product. e.g., You already have a Product (e.g., a tour or experience) bound to your system. Later the Supplier adds a new Rate (like “Early Bird” or “VIP”) under that Product. Since this new Rate becomes part of the existing binding, Redeam will send an updated channel binding notification to reflect that change.- In an
updated
case you should consider:- Call Get Rates with the corresponding Product ID from the notification
- Iterate through those Rates to compare them with the ones connected in your system
- For each NEW Rate call GET Availabilities and GET Price Schedule
- For each already known Rate, no action is needed
- If a Rate is missing, it will indicate it's no longer bound
ℹ️ Note: At this time, any Rate changes, whether a Rate was
created
orremoved
, will always register as anupdate
event as the Rate object is associated to a Product and it's data.- In an
removed
: Triggered when the entire binding is removed. Only happens when it is removed in full, the Product and all the Rates under it.- In a
removed
case, you should remove that Product from your system.
- In a
Notification received
Supplier
Supplier notifications
Receive a Supplier notification.
This endpoint receives Supplier update notifications when data from a Supplier bound to your system has been modified (e.g., name, contact details).
The exact webhook path is defined in your Notification Rule configuration when registering for Supplier
notifications and does not need to match /supplier
.
ℹ️ ️Supplier visibility is managed via channel binding. This notification only informs you of changes to existing Suppliers bound to your system.
Notification received.
Product
Product notifications
Receive a Product notification.
This endpoint receives Product update notifications when data from a Product bound to your system has been modified (e.g., description, hours, location).
The exact webhook path is defined in your Notification Rule configuration when registering for Product notifications and does not need to match /product
.
ℹ️ Product visibility is managed via channel binding. This notification only informs you of updates to existing Products already bound to your system.
Notification received.
Rate
Rate notification
Receive a Rate notification.
This endpoint receives Rates update notifications when data from a Product bound to your system has been modified (e.g., changes to cancel policies, holdability, hours, or traveler restrictions).
The exact webhook path is defined in your Notification Rule configuration when registering for Rate notifications and does not need to match /rate
.
ℹ️ Rate visibility is managed via channel binding. This notification only informs you of updates to existing Rates already bound to your system.
Notification received.
Availability
Availability notifications
Receive an availability notification
This endpoint receives Availability notifications when availability for a Product or Rate bound to your system changes within the conditions specified in your rule configuration.
Availability notifications are not based on operations (e.g., created, updated), but are triggered based on:
maxLookAheadDays
: The number of days into the future to monitor for changes (default: 7).vacanciesUnder
: Used to filter availabilities based on their vacancies, if an availability change does not cause the vacancies to drop below the provided value no notification will be issued. If set to 0 all changes inside the maxLookAheadDays will trigger a notification.
The exact webhook path is defined in your Notification Rule configuration when registering for Availability notifications and does not need to match /availability
.
Notification received.
Priceschedule
Price Schedule notifications
Receive a priceschedule notification
This endpoint receives Price Schedule notifications when pricing information for a Product or Rate bound to your system changes within the time window specified in your rule configuration.
Price Schedule notifications are not triggered by operations, but by changes occurring within the defined maxLookAheadDays
range.
maxLookAheadDays
: The number of days into the future to monitor for price changes (default: 7).
The exact webhook path is defined in your Notification Rule configuration when registering for Price Schedule notifications and does not need to match /priceschedule
.
Notification received
Booking
Booking notifications
Receive a booking notification.
This endpoint receives Booking notifications for specific booking-related events, such as cancellations or ticket confirmations.
Booking notifications are operation-based and can include:
canceled
: A booking has been canceled.tickets-added
: A set of tickets has been confirmed and attached to the booking following a previously accepted (202) response.
The exact webhook path is defined in your Notification Rule configuration when registering for Booking notifications and does not need to match /booking
.
Notification received.