Notification Registry

The Notification Registry API allows you to register and manage webhook configurations for the Travel Curious Notification service. This service enables notifications for Channel Binding, Supplier, Product, Rate, Availability, Price Schedule and Booking. Notifications are only sent for the specific services you have registered for.

This Notification Registry API is not a reoccurring call; it's a configuration task that is typically done once and only revisited if you need or want to update the previously set rules.

The following registry endpoints provide you the functionality to manage the registry list. This is where you setup the rules for the kind of notifications you would like to receive.

Each one of the HTTP methods below are applicable to Channel Binding, Supplier, Product, Rate, Availability, Price Schedule and Booking services. Notifications are controlled by the rules registered via the registry API outlined in the registry swagger. Each notification type has it's own rules.
  • POST/: Create a notification rule.
  • GET/: Retrieve an existing notification rule.
  • PUT/: Update an existing notification rule.
  • DELETE/: Delete the notification rule.

Notification rules filtering

Notification Rules support optional filtering so you can control exactly which binding changes your system receives. This allows you to reduce noise, limit unnecessary processing, and focus on specific Suppliers, Products, and Rates.

What Filtering Does

Filtering determines which binding events are delivered to you, based on the identifiers included in the notification rule.

Filtering applies before the notification is sent. That means Travel Curious will only deliver events that match the Supplier, Product, or Rate IDs you specify.

How Filtering Interacts With Operations

Filtering does not change which operations exist (created, updated, removed). Instead, it limits which events of those types you receive.

Example:

If your rule has:

Example
Copy

You will only receive updated events for Supplier SUP-123. Updates for any other Supplier will not trigger notifications to your webhook.

What Happens If No Filters Are Provided?

If you do not specify supplierIDs,productIDs``, or rateIDs your rule applies to All Suppliers, Products, and Rates visible to your channel.

This is the default, “listen to everything” mode.

Why Filter? Common Use Cases

  • Performance optimization: Reduce payload volume and unnecessary sync work.
  • Phased integrations: Monitor or sync a limited portion of your catalog.
  • Selective partnerships: Only receive updates for suppliers you actively resell.

Channel Binding Rule

As you may know, Channel Binding is the process of linking specific Suppliers, Products, and Rates from an Operator or Ticketing System to a Reseller (you). Once visibility is granted, either the Travel Curious team or the Operator/Ticketing System can bind the relevant products to you for sale.

This means the Operator determines which of their offerings (tickets, experiences, or services) you can promote and distribute. Channel Binding ensures a controlled and efficient product distribution across multiple sales channels.

When it comes to Channel Binding rules in the Notification Registry API, you can configure specific operation types to receive notifications when products are created (newly bound to you), updated, or removed. This allows you to stay informed about changes in your product visibility and take necessary actions accordingly.

🛠️ Configure When:

You want to receive updates about supplier, products or rates bound/unbound to you.

⚙️ Configurations

💻 Operations:

  • 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.

  • updated - Triggered when changes are made to bound Products and Rates, such as Rate-level adjustments within an already-bound Product.

    • 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, Travel Curious will send an updated channel binding notification to reflect that change.

  • removed - Triggered when the entire binding is removed. Only happens when it is removed in full, the Product and all the Rates under it.

ℹ️ Note: At this time, any Rate changes, whether a Rate was created or removed, will always register as an update event as the Rate object is associated to a Product and it's data. This is not a pricing change.

🔍 Filtering:

Channel Binding rules support filtering through two optional fields inside ChannelBindingConfig:

  • supplierIDs — limit notifications to changes affecting specific Suppliers
  • productIDs — limit notifications to changes affecting specific Products

If you specify supplierIDs or productIDs, only binding events for those Suppliers or Products will be delivered. If omitted, the rule applies to all Suppliers and Products visible to your channel.

🔗 See Channel Binding Notification Rules API Reference for schema, parameters and examples.
Create Request Example
201 Rule Created response example
Copy

Supplier Rule

Create a Supplier Notification Rule to receive alerts whenever there are updates to suppliers bound to your system, such as changes to supplier contact details.

Since supplier visibility is managed through channel bindings, Channel Bindings Notifications are the primary source for tracking newly accessible suppliers.

🛠️ Configure When:

You want to be notified when existing supplier details change.

⚙️ Configurations

💻 Operations:

  • updated: Existing supplier data has changed.

🔍 Filtering:

Supplier rules support filtering directly inside the SupplierConfig object using:

  • supplierIDs — restrict notifications only to certain Suppliers

If you specify supplierIDs, only updates to those Suppliers will be delivered. If omitted, the rule applies to all Suppliers bound to your channel.

🔗 See Supplier Notification Rules API Reference for schema and parameters.
Create Request Example
201 Rule Created response example
Copy

Product Rule

A Product Notification Rule allows you to receive real-time updates on changes to products bound to your system.

Using both Product Notifications and Channel Bindings Notifications ensures full visibility into product availability and updates within your system.

🛠️ Configure When:

You want to receive updates to product details like description, hours, or location.

⚙️ Configurations

💻 Operations: __

  • updated: Product data has been modified.

🔍 Filtering:

Product rules support filtering using ProductConfig object fields:

  • supplierIDs — receive updates only for Products belonging to specific Suppliers
  • productIDs — receive updates only for specific Products

If you specify supplierIDs or productIDs, only updates for matching Products will be delivered. If omitted, the rule applies to all Products bound to your channel.

🔗 See Product Notification Rules API Reference for schema and parameters.
Create Request Example
201 Rule Created response example
Copy

Rate Rule

Just like Product Notification Rules, Rate Notification Rules enables you to receive real-time alerts for updates to rates bound to your system.

Using both Rate Notifications and Channel Bindings Notifications ensures full visibility into rate availability and updates within your system.

🛠️ Configure When:

You want updates about rate details such as cancel policies, holdable, hours, traveler conditions, etc

⚙️ Configurations

💻 Operations:

  • updated: Rate attributes have changed.

🔍 Filtering:

Rate rules support filtering through the following RateConfig fields:

  • supplierIDs — restrict Rate updates to specific Suppliers
  • productIDs — restrict updates to Rates belonging to specific Products
  • rateIDs — restrict updates to specific Rate IDs only

These filters help limit the volume of Rate notifications, especially for Suppliers with many Rates. If you specify supplierIDs, productIDs or rateIDs, only Rate updates associated with those Suppliers, Products or Rates will be delivered. If omitted, the rule applies to all Rates associated with bound Products to your channel.

🔗 See Rate Notification Rules API Reference for schema and parameters.
Create Request Example
201 Rule Created response example
Copy

Please note that for price updates you should use Price Schedule Rules.

Availability Rule

Availability Notifications are slightly different than the other notifications as Travel Curious gives Resellers more control over the requests. Availability Notification is not sent for all changes, it is trigged based on the values set by you when creating the Availability rule in Notification Registry.

🛠️ Configure When:

You want notifications for availability changes under specific future dates and vacancy thresholds.

⚙️ Configurations

  • Not operation-based; triggered by rule-driven data change.
  • maxLookAheadDays: The maximum number of days into the future to consider when determining if an availability change warrants a notification. The default is 7 days.
  • 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.

🔍 Filtering:

Availability rules also support Supplier and Product filtering inside the AvailabilityConfig object:

  • supplierIDs — restrict availability updates to specific Suppliers
  • productIDs — restrict updates to availability belonging to specific Products
  • rateIDs — restrict availability updates to specific Rate IDs only

A notification is triggered only when:

  1. The change matches your Supplier/Product filters
  2. The availability change meets the threshold rules

This prevents unnecessary notifications for irrelevant or distant inventory. If you specify supplierIDs, productIDs or rateIDs, availability changes will only be delivered for matching Suppliers, Products or Rates. If omitted, availability notifications apply to all catalog items within your look-ahead window and vacancy threshold.

🔗 See Availability Notification Rules API Reference for schema and parameters.
Create Request Example
201 Rule Created response example
Copy

Here is an example to help illustrate how Availability Notifications will be triggered based on the values specified in the rules.

Scenario:

  • maxLookAheadDays is set to 7 days.
  • vacanciesUnder is set to 5 vacancies.

Example 1: Notification is triggered

  • Today is October 1st.
  • A change in availability is detected for an event happening on October 5th (which is within the 7-day window defined by maxLookAheadDays).
  • The system then checks the vacancies for the event, and it sees that the number of available spots has dropped from 10 to 3.
  • Since 3 is less than the vacanciesUnder threshold of 5, the system considers this change significant and sends a notification about the availability change.

Example 2: No notification is triggered

  • Today is October 1st.
  • A change in availability is detected for an event happening on October 20th (which is outside the 7-day window defined by maxLookAheadDays).
  • Since the event is more than 7 days away, the system ignores the change and doesn’t send a notification, even if vacancies are low.

Example 3: No notification due to vacancies

  • Today is October 1st.
  • A change in availability is detected for an event happening on October 4th (within the 7-day window).
  • However, the number of available spots drops from 10 to 7, which is still greater than the vacanciesUnder threshold of 5.
  • Since the change in vacancies isn’t significant enough, no notification is issued, even though the event is within the 7-day window.

Summary:

  • First, the system checks if the availability change occurs within the next 7 days (maxLookAheadDays).
  • If the event is within that window, it then checks whether vacancies have dropped below 5 (vacanciesUnder).
  • If both conditions are met, the system sends a notification. Otherwise, no notification is issued.

Price Schedule Rule

When creating a Price Schedule Notification Rule, you can set a parameter to control the changes you are notified about, you can determine the time frame within which changes must occur in order to trigger notifications to your system.

🛠️ Configure When:

You want to be notified of price changes within a certain date window.

⚙️ Configurations

  • Not operation-based; triggered by rule-driven data change.
  • maxLookAheadDays: The maximum number of days into the future to consider when determining if an availability change warrants a notification. The default is 7 days.

🔍 Filtering:

Price Schedule rules support filtering through:

  • supplierIDs — only receive pricing changes for specific Suppliers
  • productIDs — only receive pricing changes for specific Products
  • rateIDs — only receive pricing changes for specific Rates

These filters ensure your pricing integration processes only relevant price updates. If you specify supplierIDs,productIDs or rateIDs, only price schedule changes for those Suppliers, Products or Rates will be delivered. If omitted, the rule applies to all eligible Products and Rates within your maxLookAheadDays pricing window.

🔗 See Price Schedule Notification Rules API Reference for schema and parameters.
Create Request Example
201 Rule Created response example
Copy

Booking Rule

Booking Notifications inform you of booking-related events, such as cancellations or the confirmation of tickets attached to bookings. These events allow you to stay in sync with the booking lifecycle - especially in asynchronous flows where 202 responses are supported.

🛠️ Configure When:

You want to be notified of booking cancellations and/or when tickets are confirmed after a delayed (202) booking response.

⚙️ Configurations

💻 Operations:

  • 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.

🔍 Filtering:

Booking rules support filtering through:

  • supplierIDs — only receive booking changes for specific Suppliers
  • productIDs — only receive booking changes for specific Products
  • rateIDs — only receive pricing changes for specific Rates

If you specify supplierIDs, productIDs or rateIDs, only Booking updates associated with those Suppliers, Products or Rates will be delivered. If omitted, the rule applies to all Bookings and corresponding operation subscribed.

🔗 See Booking Notification Rules API Reference for schema and parameters.
Create Request Example
201 Rule Created response example
Copy

Notification Metadata Configuration

The Notification Metadata endpoints allows you to define a single, shared metadata object that applies globally across all notification rules configured for your account. This is useful for setting rule-wide modifiers that affect webhook behavior, such as delaying delivery or temporarily disabling notifications.

🛠️ Configure When:

You want to apply a global configuration that influences how all your webhook notifications behave - without modifying individual rules. Ideal for staging environments, load testing, or temporarily suspending delivery.

⚙️ Operations / Configuration Settings:

Unlike rule-specific configurations, the metadata object is not event-driven and has no operations like created or updated to subscribe to. Instead, it defines global webhook delivery parameters that apply across your account’s notification rules:

  • throttleDelay: A delay interval (e.g., "10s") to throttle notification delivery.
  • disableAll: A flag to disable all webhook notifications temporarily.
  • createdOn / updatedOn: Timestamps for tracking metadata object creation and updates.

🔗 See Notification Metadata API Reference for schema and parameters.
Create Request Example
201 Created response example
Copy

Testing Notifications with Travel Curious's Test Endpoints

To validate your implementation of the Notifications API, Travel Curious provides test endpoints that simulate real notification events. These allow you to trigger sample notifications for various event types and ensure your system is correctly receiving and processing them.

These test notifications are not tied to live data and will not reflect actual supplier/product activity. They are intended for functional and integration testing only.

Available Test Endpoints

You can simulate the following notification types:

Notification TypeEndpoint
Channel BindingPOST/channelbinding/test
SupplierPOST/supplier/test
ProductPOST/product/test
RatePOST rate/test
AvailabilityPOST/availability/test
Price SchedulePOST/priceschedule/test
Booking (Cancellation)POST/booking/test

How to Use

Send a POST request to the corresponding POST /{type}/test endpoint. Each request will simulate a notification payload and send it to your registered webhook URL(s).

Example Request:

Test Request Example
Copy

Verifying the Response

Once triggered, the simulated notification will appear in your webhook receiver, just like a live notification. You can use this to:

  • Verify signature handling (token, sum)
  • Test your parsing logic
  • Validate downstream sync or audit actions
  • Confirm appropriate logging or error-handling behaviour

For more details about each endpoint and their schema please check the Notification Registry API documentation.
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
Next to read:
Travel Curious Notifications

Questions? We'd love to hear them. Contact Travel Curious Support.

On This Page
Notification RegistryNotification rules filteringChannel Binding RuleSupplier RuleProduct RuleRate RuleAvailability RulePrice Schedule RuleBooking RuleNotification Metadata ConfigurationTesting Notifications with Travel Curious's Test EndpointsWhat Filtering DoesHow Filtering Interacts With OperationsWhat Happens If No Filters Are Provided?Why Filter? Common Use CasesAvailable Test EndpointsHow to UseVerifying the Response