Vendor Fallback

We understand that ensuring notification delivery can be challenging, especially when you are dependent on third-party vendors to route your messages to the end user. Factors such as provider limitations, network failures, and service outages can disrupt the delivery of your notifications.

To ensure that your messages get delivered promptly and reliably, we have added the support for vendor fallback. With vendor fallback, you can add multiple vendors to the fallback list and If one provider fails, your messages will automatically be rerouted through another provider, minimizing the risk of message delivery failures.

It is essential for system notifications like OTPs, password reset mails and some of the transactional use cases like payment confirmation, stock market alerts etc.

How Vendor Fallback works?

Vendor Fallback logic comprises of 3 major components

1. Vendor Priority List - The list of vendor configurations to be tried in the order of their priority.
2. Fallback time - The time within which the notification should be routed to the next vendor if the first vendor fails to deliver the message
3. Fallback Rule - What are the cases in which fallback would happen. There are 2 cases in which fallback happens currently:
   1. if delivery fails, fallback happens immediately
   2. if delivery report is not received within fallback time, fallback happens after fallback time is over

👍

Success Metric closes workflow and vendor fallback

There can be cases when the notification is delivered to the user but the vendor fails to send delivery report in the fallback period. This may lead to sending duplicate notification to the user. We solved this in vendor fallback method using success metric. Now, success metric not only stops channel routing, it also works as an indication that the user has received the message and stops vendor fallback.

Example Use case

Let's take an example of OTP verification text (SMS) with the following condition:

• Primary vendor - Messagebird
• Fallback 1 vendor - Twilio
• Fallback within - 30 secs (Fallback to Twilio if Messagebird fails to deliver SMS in 30 secs)
• Success Metric - "OTP Verification" (do not fallback to Twilio if "OTP verification" event is received within 30 secs)

In this case, if Messagebird fails to deliver the SMS within 30 secs of triggering the notification and the "OTP Verification" event is not received, SMS will be routed through Twilio.

Setting vendor fallback from SuprSend dashboard

Go to SuprSend dashboard -> "Vendor Settings" page and click on "Edit List". You can add fallback rule for above example like this:

You'll find all the saved vendor configurations in "Unused Vendor Configuration". Enable it to add it in the fallback list.

Once enabled, you can drag and drop to change the priority of vendors

Save the changes after editing.