A good notification service is more than a communication channel; it can bridge the gap between the product and the users, increasing product adoption.
Think of it this way: timely and relevant #alerts can nudge users with some actionable intent for your product.
But frankly, notification services are not business use cases for most companies, and hence the grunt work of building and maintaining that service is not preferred by developers, well.... too much.
We shifted these 7 functional components from developers to product teams in our notification service.
1) Multichannel Delivery: Doing multiple API integrations was a headache for devs who would be working on core business use-cases. It's freed now, since SuprSend already supports these providers, hence a product person can easily configure the API tokens and start using the vendor.
2) User Preferences: Letting users customize their experience is like giving them the remote control. Who doesn't love being in charge? We do it at two levels, our customers and then their customers all from our embedded notification center, which devs don't need to build or maintain.
3) Templating Engine: Say goodbye to template headaches in codebases! Our central engine is like your notification toolkit, all in one place for all channels. It has always been challenging to later find and change one customer's template because their mood changed.
4) Multi-tenancy: It's like serving up personalized experiences for multiple customers at once. No extra coding required! Fully maintained at SuprSend.
5) Workflow Engine: We make notification magic happen smoothly, like a well-oiled machine... or a really good toaster.
6) Observability: Ever had someone swear they didn't get a notification? With us, we'll track it down to that user level faster than your keys in the couch cushions. This is a nasty request coming from product teams to developers. Should we really leave our work, and catch the mouse for you?
7) Batching/Digests: Multiple notifications in one neat package? At least that's what I would want at the end of the day.
Following example shows a sample request for triggering a workflow.
It triggers a pre-created workflow purchase-made to a recipient with id: distinct_id,
email: user@example.com & androidpush(fcm-token): __android_push_fcm_token__
fromsuprsendimportWorkflowTriggerRequest# Prepare Workflow bodywf=WorkflowTriggerRequest(
body={
"workflow": "purchase-made""recipients": [
{
"distinct_id": "0f988f74-6982-41c5-8752-facb6911fb08",
# if $channels is present, communication will be tried on mentioned
It is a unified API to trigger workflow and doesn't require user creation before hand. If you are using our frontend SDK's to configure notifications and passing events and user properties from third-party data platforms like Segment, then event-based trigger would be a better choice.
After installing, Import the component in your code and use it as given below. Replace the variables with actual values.
importSuprSendInboxfrom'@suprsend/react-inbox'import'react-toastify/dist/ReactToastify.css'// needed for toast notifications, can be ignored if hideToast=true// add to your react component;<SuprSendInboxworkspaceKey='<workspace_key>'subscriberId='<subscriber_id>'distinctId='<distinct_id>'/>