Notification Registry

The Notification Registry API allows you to register and manage webhook configurations for the Redeam 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.

• POST/: Create a notification rule.
• GET/: Retrieve an existing notification rule.
• PUT/: Update an existing notification rule.
• DELETE/: Delete the notification rule.

Notification rules are not supplier-specific

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

⚙️ 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, Redeam 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.

🔗 See Channel Binding Notification Rules API Reference for schema, parameters and examples.

{

  "url": "https://www.example.com/channelbinding",

  "disabled": false,

  "config": {

    "operations": [

      "created"

    ]

  }

}

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.

🛠️ Configure When:

You want to be notified when existing supplier details change.

⚙️ Operations:

• updated: Existing supplier data has changed.

🔗 See Supplier Notification Rules API Reference for schema and parameters.

{

  "url": "https://www.example.com/supplier",

  "disabled": false,

  "config": {

    "operations": [

      [

        "updated"

      ]

    ]

  }

}

Product Rule

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

🛠️ Configure When:

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

⚙️ Operations:

• updated: Product data has been modified.

🔗 See Product Notification Rules API Reference for schema and parameters.

{

  "url": "https://www.example.com/product",

  "disabled": false,

  "config": {

    "operations": [

      [

        "updated"

      ]

    ]

  }

}

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.

🛠️ Configure When:

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

⚙️ Operations:

• updated: Rate attributes have changed.

🔗 See Rate Notification Rules API Reference for schema and parameters.

{

  "url": "https://www.example.com/rate",

  "disabled": false,

  "config": {

    "operations": [

      [

        "updated"

      ]

    ]

  }

}

Availability Rule

Availability Notifications are slightly different than the other notifications as Redeam 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.

⚙️ Operations:

• Not operation-based; triggered by rule-driven data change.

🔧 Configurable Parameters:

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

🔗 See Availability Notification Rules API Reference for schema and parameters.

{

  "url": "https://www.example.com/availability",

  "disabled": false,

  "config": {

    "maxLookAheadDays": 30,

    "vacanciesUnder": 5

  }

}

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.

⚙️ Operations:

• Not operation-based; triggered by rule-driven data change.

🔧 Configurable Parameters:

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

🔗 See Price Schedule Notification Rules API Reference for schema and parameters.

{

  "url": "https://www.example.com/priceschedule",

  "disabled": false,

  "config": {

    "maxLookAheadDays": 30

  }

}'

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.

⚙️ 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.

🔗 See Booking Notification Rules API Reference for schema and parameters.

{

  "url": "https://www.example.com/booking",

  "disabled": false,

  "config": {

    "operations": [

      "canceled",

    ]

  }

}

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.

{

  "throttleDelay": "10s",

  "disableAll": "false",

  "updatedOn": "2024-01-18T10:05:15Z",

  "createdOn": "2024-01-18T10:05:15Z"

}

Testing Notifications with Redeam's Test Endpoints

To validate your implementation of the Notifications API, Redeam 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.

Available Test Endpoints

You can simulate the following notification types:

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:

{

  "supplierID": "65cddcad-b3e0-4fd9-a466-7188104742a2",

  "operation": "updated"

}

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