Application notifications

Application notifications allow you to be informed of the changes occurring to your Application.

In a similar way to webhooks, notifications send requests to a URL of your choice with a predefined payload. To view the payload content, see the notification schemas.

Depending on the notification type, the following are possible:

• Requests are sent either in real time after a qualifying event occurs or based on a schedule before it occurs.
• You can configure the request payload size. A larger payload means fewer requests are sent, optimizing the use of hardware resources.

To learn about notifications for loyalty programs, see Loyalty notifications.

Notification types

A notification type represents a qualifying Application-related event for which you can create a notification and receive requests, for example, coupons that are expiring soon.

You can create and manage notifications of the following types:

Campaign-related changes Real-time

Notification schemas

Be notified of the following events in real time:

• A campaign was created, edited, or deleted.

  Editing includes changes made to mandatory attributes or the Settings section of any campaign.

• The state of a campaign changed.

• One or more rules changed.

• The evaluation for one or more campaigns changed.

note

• Requests are sent for all the above events and for all the campaigns of the Application. You cannot select which requests to receive.
• Requests are categorized by campaign. For example, if a qualifying event occurs in two campaigns, a request for each of those campaigns is sent.
• A separate request is sent if the campaign evaluation tree changes.

You can create one or more notifications of this type.

Requests are sent every five minutes. This means:

• A request can take up to five minutes to be sent after a qualifying event occurs.
• If a qualifying event occurs repeatedly in that interval, the request reflects the latest effective change. For example, if a campaign is activated, disabled, and activated again in that interval, the request reflects only one activation event.

When you create a notification, you can choose to receive requests that contain up to five objects per request.

Strikethrough pricing updates Real-time Scheduled

Notification schema

Be notified of the following events in real time:

• A cart item catalog was updated via the Sync cart item catalog endpoint, and the update triggered at least one strikethrough rule.
• A rule, cart item filter, or value map was updated.
• A campaign became Expired or its state changed:
  • Running ⇨ Disabled
  • Disabled ⇨ Running
  • Scheduled ⇨ Running
• A strikethrough notification was created or activated.
• Data was imported into a collection, when the collections are used in Running campaigns containing strikethrough rules.
• A campaign evaluation tree was edited, when a campaign containing strikethrough rules is a part of the campaign evaluation tree.
• A campaign evaluation group was changed, when the campaign is Running and contains strikethrough rules.
• The value of a custom attribute with associated entity Application or campaign was edited, when the attribute is used in one of the following places of a Running campaign:
  • A strikethrough rule.
  • A cart item filter.
  • The payload of a per-item custom effect that is referenced in a strikethrough rule.
• The payload of a per-item custom effect was edited.
• The API name of a per-item custom effect was changed, when the effect is referenced in a strikethrough rule of a Running campaign.
• The name, currency, or time zone setting of an Application was changed in the Application settings, when it is referenced in a strikethrough rule of a Running campaign.

You can create only one notification of this type.

Requests are sent every five seconds. They are generated sequentially. Talon.One waits for the response of a request before sending the next one.

When you create a notification, you can configure the payload to contain between 200 and 1000 objects per request.

(Optional) Scheduling strikethrough pricing updates

Feature access

This feature is in the early access phase. To unlock this feature, contact your Customer Success Manager.

In addition to receiving strikethrough pricing updates in real time, you can schedule updates before a campaign with strikethrough rules starts, ends, or both.

If you have already created a notification for real-time updates, and you then also schedule updates, all requests include an updated payload containing the version, validFrom, startTime, and endTime parameters.

Scheduled and real-time strikethrough pricing updates operate in conjunction. For example, if updates are scheduled, but there are last-minute changes to a campaign, updates are sent in real time. This ensures that you receive the latest and most relevant strikethrough pricing and label information.

Coupon-related changes Real-time

Notification schemas

Be notified in real time when a coupon is created, edited, or deleted, whether it happens through the Campaign Manager, Management API, or the Rule Engine. However, this does not include imported coupons.

You can create only one notification of this type.

Requests are sent immediately after a qualifying event occurs.

When you create a notification, you can configure the payload to contain up to 2000 objects per request. Alternatively, choose to receive a single request that contains only the batch ID of the coupons.

Expiring coupons Scheduled

Notification schema

Be notified through scheduled triggers when a coupon is close to expiration. You can add up to three scheduled request triggers, each with a different alert time before coupon expiration.

You can create only one notification of this type.

Schedule	Action	Payload size
Daily at 00:00 UTC	Retrieves coupons that meet all of the following criteria: Has an expiration date Expiration date is today + scheduled days (UTC)	Up to 2000 objects per request, or a single request with the batch ID of the coupons.

note

• The timestamps in the payload refer to the time zone of the Application.
• Requests include coupons that have already been redeemed. To filter out redeemed coupons in your integration, you can use the usageLimit and usageCounter fields in the payload.

Example

You want to notify customers one week before their coupons expire. You have added a scheduled trigger for 1 week before expiration.

Let's assume the current time is July 15, 00:00 UTC. That means that today + 7 days is July 22.

Talon.One checks the following coupons:

Code	Expiration date (UTC)	Included in Request	Reason	Calculation
XCUK4M	July 7, 09:20	No	Coupon has already expired	Expiration date is before today + 7 days
B3YMWA	July 22, 00:00	Yes	Coupon expires on the scheduled date	Expiration date is today + 7 days
F7RYEP	July 22, 23:59	Yes	Coupon expires on the scheduled date	Expiration date is today + 7 days
Q9JF5L	July 23, 14:20	No	Coupon expires later	Expiration date is after today + 7 days

Talon.One sends a request that contains two coupons expiring on July 22.

Request logging and retry policy

All notification types have a response timeout of 10 seconds. Requests that time out are logged with no response code.

Progressively delayed resend attempts are made up to 10 times or until a 2xx response is received, whichever occurs first. Resend attempts are made when a notification request cannot be sent for the following reasons:

• 5xx response codes.
• 429 Too Many Requests response code.
• There's no response at all.

Related pages

• Scheduling campaigns
• Managing campaigns
• Understanding campaign evaluation
• Notification schemas
• Loyalty notifications
• Displaying notification logs