
The way SuprSend works is that our backend fires an event and SuprSend takes care of everything else. Which channels to send on, what template to use, whether to batch or delay, what the user's preferences are. All of that is configured outside our code.
This event-driven approach keeps our notification logic minimal. We just need to send the right event with the right data and SuprSend does the rest. If product wants to change the email template or add a push notification to an existing flow they do it in the dashboard. Our code does not change at all.
We started with a few event types and have been adding more as we build new features. Each time it takes a few minutes to set up a new workflow for the event in the dashboard. The API accepts the event and the workflow handles the logic. It is clean and predictable.
For developers who want to keep their backend simple and not clutter it with notification logic this approach works well. Our notification code is basically a few API calls that fire events. Everything else is managed outside the codebase. Review collected by and hosted on G2.com.
A way to validate event payloads against expected schemas before they trigger workflows would be a nice safety feature. Review collected by and hosted on G2.com.