How to configure System Notification Events

Introduction & Previous Concepts

System notifications allow us to send event-based alerts to predefined notification channels, ensuring timely communication about specific system events.

If you haven't set up your notification channels yet, please refer to the following documentation for guidance on how to do so.

https://thiio.atlassian.net/wiki/spaces/THIIOSM/pages/2581528652

Procedure

In the menu, click to expand Settings.
And then click in System notifications.
You will see a list of 10 notification events.
1. Order completed: Triggered when a successful order is finalized. For admin, quote, or shop sales, this occurs upon purchase. In funnels, it triggers when a user reaches the "Thank You" page or after 30 minutes, if the page is not visited.
2. Contact created: Is called in these situations:
  1. When a lead is created through the admin, shop, or funnel page.
  2. When a reactivation (we receive information for a contact that already exists) for a lead/customer occurs in the shop or a funnel page.
3. Shipping tracking info updated: Triggered when an order's tracking information is updated.
4. Product conflicts: Called when a product conflict occurs (ex: a customer who purchased a digital product that he already has).
5. Transaction declined: When a purchase transaction gets rejected in the system. Because this is at the transaction level (in funnels, an order can have many transactions if upsells are involved), this event can be triggered multiple times inside a single purchase flow. For example, the cart page sale was approved, but all the next upsells were declined due to insufficient funds.
6. Refund applied: Occurs when a refund or void transaction is processed.
7. Subscription canceled: Triggered when a subscription is canceled.
8. Customer created: When a lead makes their first successful purchase in the system. (Right now, this only works with postback channels.)
9. Approved transaction: When a purchase transaction succeeds in the system. (in funnels, an order can have many transactions if upsells are involved), this event can be triggered multiple times inside a single purchase flow. For example, the cart page transaction was approved, and the following upsells were also purchased. This would result in multiple fires of this system notification event.
10. Survey completed: When a survey is finished.
If the event you want to use is disabled, enable it by toggling the switch on its right, otherwise click on the Add channels button or # channels button.
You will see a list of the current channels added to this event (the list will be empty if no channels were attached previously).
Click on Plus Button in the bottom right corner to attach a channel.
You will see a form like this one:
1. Channel: Select one of your previously created channels. If you have none, click the Plus button on the right. If you need to add a new channel, please read this document first:
  How to create a notification channel
2. Filters: Depending of the current notification, some filters will show and others will be hidden, please refer to the next document for details:
  Notification filters
Click on save to see that the channel was successfully linked to the event.
If you click on the 3 vertical dots on the right, you will see three options available:
1. View details: Option to view the filters applied to the notification event for the selected channel.
2. Edit: Here you can update the filters of the notification event.
3. Delete: You can remove the channel to being notified of this event.

Postback notes

Retry on Failed Notifications

In the event of an error we automatically retry a postback request up to 3 times if we receive any of these HTTP codes:

408: Client request timeout
429: Too many requests
500-599: Any error in the 500-599 range

If a request failed the 3 tries, you could make a manual retry for these specific events through the Orders UI in the admin:

Order completed.
Approved transaction.
Transaction declined.
Refund applied.

We have a timeout of 30 seconds when dealing with these requests, so if your endpoint takes longer to respond, we will mark the operation as failed, and it won’t be retried automatically (assuming it hasn’t failed 3 times previously). If you need the data again, you would need to make a manual retry (the 30 second timeout limitation still applies).

To avoid problems with the timeout, we recommend you not perform heavy operations in your endpoint, get only the data, and dispatch a background job to execute your needed processes.

Payloads

Here we will show you some examples of payloads you can receive when notifying postback channels.

This is only a reference, in some values that are objects you could receive null. For example, admin orders don’t have a funnel, you would receive a null value on the funnel key. If you need to access an object property in your end validate that such prop is not null first.