DEV Community: SuprSend

One Platform for Every Notification Channel, and a CLI to Manage It All From Your Terminal

Nikita Navral — Wed, 21 Oct 2026 10:42:52 +0000

If you've ever built notifications into a product, you know it starts with one email and ends with a small platform: multiple channels, multiple vendors, templates, user preferences, retries, analytics, and a PM asking for copy changes every week.

This post is a quick introduction to SuprSend, the notification infrastructure we work on, and then a closer look at the SuprSend CLI, which lets you manage all of it from your terminal and your Git repo.

What is SuprSend?

SuprSend is a notification infrastructure platform. Instead of wiring up each channel and vendor yourself, you integrate once and manage the notification layer in one place.

It covers the pieces most teams end up building on their own:

Multiple channels: email, SMS, push, in-app inbox, WhatsApp, Slack and more, through one integration
Workflows: the logic for when, to whom and on which channel a notification goes out
Templates: content for each channel, with variables and personalization
User preferences: letting end users choose what they get and where
Multi-tenancy: per-customer branding and settings for B2B products
Analytics: delivery and engagement data in one place across channels

The goal is simple: your engineers shouldn't spend sprints reinventing notification plumbing.

The gap: great platform, but changes happen in a dashboard

Most of these assets (templates, workflows, preferences) are authored in a dashboard. That's friendly for PMs and marketers, but it creates a mismatch for engineering teams:

The source of truth isn't in your repo
Staging and production can drift apart
Changes don't go through pull requests
Promoting to production often means someone needs production dashboard access

Engineers manage everything else from code: app logic lives in a repo, ships through PRs, deploys through CI and rolls back through Git. Notifications should be able to work that way too.

Enter the SuprSend CLI

The SuprSend CLI brings the platform into the terminal. Every core asset (workflows, templates, schemas, events, preference categories and translations) can be managed through commands that fit into scripts and CI/CD pipelines.

Install on macOS or Linux:

brew install --cask suprsend/tap/suprsend

Then authenticate with a service token. For Windows and CI environments, download the binary from GitHub Releases, or build from source.

Each asset can be:

listed
pulled to local files
edited in your editor
pushed back
committed from draft to live
synced between workspaces

You can also activate or deactivate workflows from the shell, which is useful for shipping a new workflow, or for taking a misbehaving one offline during an incident.

How it fits the tools you already use

The CLI is built to slot into your setup rather than replace it.

Your editor

Pulling an asset writes it as readable JSON into your project. Edit it in your IDE with your usual linting, syntax highlighting and AI completions. When you push it back, it's validated against SuprSend schemas before it's saved.

Git

Once assets are local files, they live in your repo like any other code. Commits show who changed what, diffs show exactly what shifted, and a revert rolls back a bad change in seconds. Your Git log becomes your notification change history.

CI/CD

Every command is scriptable. A GitHub Action, CircleCI job or any other pipeline can run pulls, pushes and syncs as deploy steps, so notification changes ship on the same cadence as your app code.

Three things you can do with it

1. Promote staging to production in one command

suprsend sync --from staging --to production

Because your pipeline does the promotion, nobody needs UI access to the production workspace to ship a change. Production access stays locked down, and changes flow through reviewed pull requests.

2. Get type-safe payloads

Generate native type definitions from your SuprSend schemas and drop them into your SDK:

suprsend schema generate-types --schema order-confirmation --output ./types

A wrong payload key then fails in your IDE, in CI and in your build, before any send is attempted. The schema becomes a guardrail instead of a runtime surprise.

3. Manage workflows and templates as code

Bootstrap a new workspace by provisioning templates from a script instead of building them one by one in the UI
Migrate templates from another tool or an internal codebase without recreating them by hand
Review changes in PRs like any other code

Open source and verifiable

The CLI is open source and free to use. Install via Homebrew, grab the binary from GitHub Releases, or build from source. If you're in a security-sensitive environment, you can verify the binary's signature with Cosign before installing.

Where to go from here

📖 CLI docs: install and run your first command
🧰 All CLI commands: the full surface
🌐 SuprSend: the platform itself

Over to you: how does your team manage notification templates today? Dashboard, Git, or a mix? Tell us in the comments.

Choosing The Right Message Queue Technology For Your Notification System

Nikita Navral — Fri, 16 Oct 2026 10:57:47 +0000

Your notification system works great at 100 messages a minute. Then your app goes viral, a flash sale hits, and suddenly your OTPs are stuck behind 2 million promotional pushes.

Sooner or later, every notification system needs a message queue. The hard part is picking one. Kafka, RabbitMQ, SQS, Pub/Sub and Kinesis all "move messages," but they behave very differently when you need ordering, retries, replays or priorities.

This guide walks through the factors that matter for notifications, compares the five most common options, and ends with a checklist you can use to decide.

First, what do notifications need from a queue?

Forget feature lists for a second. Here's what actually matters, with a real scenario for each.

Scalability

Your sports app sends a push whenever a team scores. Traffic is quiet until a derby match, then every user gets a notification within seconds. You need a queue that scales out without redesign.

Message retention

You send transaction alerts in real time. One night your consumer crashes for 30 minutes. If the queue discards messages that aren't consumed, those users never hear about their money moving.

With retention, messages wait in the queue (for an hour, a day, longer) and are processed when the consumer comes back.

Low latency

A fraud team needs to be alerted the moment a suspicious transaction appears. Delay matters here.

A caveat: Redis Pub/Sub is often cited for this, but it's fire-and-forget. If no subscriber is listening, the message is gone. For anything you can't afford to lose, use Redis Streams or a durable broker.

High throughput

A food delivery app sends status updates ("being prepared", "on its way") for every order. Volume is high, and many consumers need to process it in parallel. This is where Kafka and Kinesis shine.

Message ordering

A trading platform sends market alerts. If "price dropped" arrives after "price recovered," users act on stale information. You need ordering guarantees, at least per user or per entity.

Prioritization

A hospital monitoring system alerts nurses when a patient's heart rate crosses a threshold. That alert can't wait behind a batch of routine reports.

One thing to know: most queues don't have native priority. The usual pattern is separate queues or topics per priority:

TOPICS = {
    "critical": "notif.critical",   # OTP, security, health alerts
    "high":     "notif.high",       # transactional
    "low":      "notif.low",        # promos, digests
}

producer.send(
    TOPICS[msg.priority],
    key=msg.user_id.encode(),   # same user -> same partition -> ordered
    value=payload,
)

Each topic gets its own consumers and throughput limits, so a promo blast can't starve your OTPs. (RabbitMQ is the exception, with native priority queues.)

Dead letter queues (DLQs)

An e-commerce site sends order confirmations. Some email addresses are invalid and fail every time. Without a DLQ, those messages are retried forever or block the line. With a DLQ, failures move aside where you can inspect them and fix the cause.

{
  "RedrivePolicy": {
    "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789012:notif-dlq",
    "maxReceiveCount": 5
  }
}

That's an SQS redrive policy: after 5 failed receives, the message goes to the DLQ.

The five contenders, side by side

	RabbitMQ	Kafka	AWS SQS	Google Pub/Sub	AWS Kinesis
Model	Broker with exchanges and queues (AMQP)	Distributed log, consumer groups	Queue (pull)	Topics and subscriptions (push or pull)	Streams split into shards
Ordering	FIFO per queue	Per partition	FIFO queues, per message group	Per ordering key (opt-in)	Per shard / partition key
Latency	Very low	Low	Low	Low	Low
Throughput	Moderate to high	Very high	Very high	High	High (shard-bound)
Retention / replay	Until acked (Streams plugin adds replay)	Configurable, replayable	Up to 14 days, no replay	Configurable, can seek back	24h up to 365 days, replayable
Native priority	Yes	No (use separate topics)	No (use separate queues)	No (use separate topics)	No (use separate streams)
Dead letter queue	Dead-letter exchanges	DIY (a DLQ topic)	Native	Native	No native DLQ (handle in the consumer)
Ops burden	Moderate (self-host or managed)	Heavy if self-hosted, managed options exist	Fully managed	Fully managed	Fully managed
Pricing	Infra cost if self-hosted	Infra cost if self-hosted	Pay per request	Pay per volume	Pay per shard / volume
Access control	vhosts and permissions	ACLs	IAM	IAM	IAM

Limits like max message size change over time, so check each provider's docs before you design around them.

Which one should you pick?

Here are three common situations.

🚀 Startup with low-volume transactional notifications → RabbitMQ (or SQS)

Easy to set up, simple to reason about, and flexible routing. It has native priority queues and dead-letter exchanges, so you get a lot of notification-friendly features without much ceremony. If you're all-in on AWS and want zero ops, SQS is a strong alternative.

📈 Mid-sized company, high volume, low latency → Kafka

Distributed, high throughput, and great for fan-out: one event can feed email, push and analytics consumers at once. Replication and replay are strong, and you can reprocess history when something goes wrong. The trade-off is operational complexity, so consider a managed offering.

🏢 Enterprise on AWS with many microservices → Kinesis (plus SNS/SQS where it fits)

Fully managed, integrates natively with Lambda and the rest of AWS, and handles large volumes. Kinesis is a streaming service rather than a classic queue, so many teams pair it with SQS or SNS for simple fan-out and retry patterns.

At-least-once delivery means you need idempotency

Almost every queue above delivers messages at least once. Retries and rebalances can deliver the same message twice, and a user getting the same "payment received" push twice is a bug.

def handle(msg):
    if already_processed(msg.id):      # e.g. Redis SETNX or DB unique key
        return
    send_notification(msg)
    mark_processed(msg.id)

Whichever queue you pick, build this in from day one.

Latency vs throughput: you can't max both

Optimizing for one tends to cost you the other.

Low latency needs fast ingest and delivery, which uses more CPU, memory and network per message.
High throughput relies on batching and parallelism, which can add a little delay per message.

RabbitMQ leans toward low-latency, real-time delivery. Kafka leans toward high-throughput streaming, but it's tunable (settings like batch size and linger time let you trade one for the other). Even then, hardware and architecture set the limits.

A practical rule: use low-latency settings for your critical queue (OTPs, alerts), and throughput-optimized settings for the low-priority bulk queue.

A checklist for deciding

Run through these before you commit.

Define your numbers. Message volume, latency target, reliability needs.
Pick your trade-off. Latency or throughput first?
Plan for growth. Can it scale horizontally as your user base grows?
Check ecosystem fit. Your languages, frameworks and existing cloud provider.
Count the operational cost. Setup complexity, monitoring, and what your team already knows.
Check security. Durability, access control and encryption in transit.
Budget it. Infrastructure, managed service fees and maintenance time.
Prototype and load-test. Don't trust benchmarks, including the ones in this post. Test with your own traffic.

Running multi-cloud or hybrid?

A few things to watch for:

Multiple queue technologies. Different components may use different brokers. Make sure your team can operate all of them.
Standard protocols. Prefer widely supported protocols like AMQP or MQTT where you can, and keep message formats consistent to avoid fragmentation.
Complexity vs flexibility. Cross-environment connectivity adds moving parts. Make sure the flexibility is worth it.

Wrapping up

There's no single best message queue, only the best fit for your volume, latency needs, team and cloud. Balance performance, reliability, ease of use and ecosystem, and revisit the decision as your notification system grows.

And if you'd rather not build and operate this whole layer yourself (queues, priorities, retries, fallbacks), that's what we built SuprSend for. Full disclosure: we work on it, so take that into account.

Your turn: which queue are you running notifications on today, and would you pick it again? Tell us in the comments. Horror stories welcome.

Introducing SuprSend Agent

Nikita Navral — Thu, 15 Oct 2026 07:54:36 +0000

Quick intro: we're the team behind SuprSend, a notification infrastructure platform. Today we're launching SuprSend Agent, and we wanted to share what we built, how it's wired, and the guardrails we put around it.

The 30-second version

SuprSend Agent is an AI agent that lives inside the SuprSend dashboard. You describe what you need in plain English, and it builds, configures and debugs your notification setup for you.

It's connected to:

the full SuprSend API surface
the product documentation
agent skills
domain knowledge about how notifications actually work

So it doesn't just fire off API calls. It understands your use case, picks the right tools, applies the correct configuration, and tests the result.

Try it: SuprSend Agent | Docs: read the docs

Why we built it

Notifications are deceptively deep. One message passes through several layers of logic: who gets it, on which channel, at what time, with what content, and what happens if the user does (or doesn't) act. Every layer has to be configured, tested and iterated.

That depth is what lets a platform handle real-world use cases. It's also why it takes days to build a mental model before you configure anything.

The agent shifts where that effort goes:

New users skip the upfront learning curve. Ask the agent how things work, and let it set up your first workflows.
Existing users skip the click-through. No more hopping between screens to change a vendor, check an object or tweak a template.

What you can do with it

1. Ask anything (without opening another tab)

Data modeling, how a feature works, what an error means, best practices, how to approach an integration. It answers from the docs.

"How do preferences cascade from defaults to tenants to end users?"

2. Manage your assets from a chat

The agent can create, retrieve, update and commit across tenants, objects, preferences, vendors, translations and schemas.

"Update the SMS vendor for tenant cypher and show me the current preference categories."

3. Design and test a notification from one prompt

This is the one we're most excited about. Normally you decide everything yourself: flow structure, timing, branching, channels, and how the content should read on each one.

Now a prompt like this is enough:

"Set up a trial expiry reminder for new users."

The agent will:

Map out the workflow nodes
Set the time delays
Add the branching logic
Pick the right channels
Design and personalize the templates with variables
Test the result across every channel

You describe the outcome. It handles the build.

4. Ask your analytics anything

A fixed dashboard only answers the questions it was built for. The agent reads your notification data through a semantic layer over the data lake, so you can ask things like:

Which notifications performed worst in the last 30 days?
What's the best performing template this week?
How do channels compare across segments and tenants?
How many workflows are active?

"Show me delivery and open rates for the weekly-digest workflow, split by tenant, for the last 30 days."

It returns the answer, can visualize it as a chart, and can post it straight to Slack.

5. Debug "why didn't they get it?"

We all know this one. A notification doesn't arrive, and the cause could be a channel issue, a preference opt-out, a tenant override or a vendor failure. Finding it means digging through logs and screens.

"User john@cypher.com says he's not getting emails. What's wrong?"

The agent traces the delivery, finds what stopped it, explains the cause and suggests a fix.

"Cool, but is it safe on a live workspace?"

Fair question, and honestly the one we spent the most time on. The agent acts on real organizational data, so safety is built into every step:

Guardrail	What it means
Workspace-scoped access	Every session is limited to one workspace. A conversation in one can't read or change data in another.
Service token auth	Each session uses a workspace-scoped JWT that expires and auto-refreshes, so access is short-lived by default.
Permission before changes	The agent asks for confirmation before any edit. Updates read the resource's current state first, so nothing is silently overwritten.
No destructive deletes	Deletes aren't exposed to the agent at all. Only low-risk, reversible operations (like removing a user from a list) are allowed.
Validated, not guessed	It runs on validated SuprSend schemas and product knowledge, so it uses correct parameters instead of guessing.

Who is it for?

Developers, product managers, marketing, customer success and ops teams. Basically anyone who manages notifications but doesn't want to write integration code for every change. Work that used to wait on engineering can now happen in a conversation.

A bigger shift

This launch is part of a larger direction: SuprSend is becoming AI-first notification infrastructure, where you operate the platform by describing what you need instead of learning every knob and switch.

Try it and tell us what you think

Start with a first prompt in the dashboard: Try SuprSend Agent

We'd love to hear from you in the comments:

What's the first thing you'd ask the agent to build?
What guardrails would you want on an AI agent that touches production config?
What's the most painful notification bug you've ever had to debug?

We read every reply. 👇

A complete guide on Notification Service for Modern Applications in 2026

Nikita Navral — Wed, 14 Oct 2026 10:53:02 +0000

Most notification services start as a single function:

def notify(user, message):
    email_client.send(user.email, message)

It works for a while. Then product asks for push, then SMS, then an in-app inbox, then "can users pick what they get?" Before long, this one function has become a distributed system.

This post breaks down what a production notification service contains, split into the functional parts users and PMs see, and the non-functional parts that keep it alive at 3 a.m. At the end, there's a framework for deciding whether to build or buy.

The big picture

Your app --> Notification API --> Preference check --> Template render
                                        |
                              Priority queues (critical / high / low)
                                        |
                              Channel workers (email, SMS, push, inbox...)
                                        |
                              Vendor adapters --> Webhooks --> Analytics

Each box hides real engineering work. Let's go through them.

Part 1: Functional components

1. Delivery channels and vendor integrations

Users live on different channels: email, SMS, push, in-app inbox, WhatsApp, Slack or Teams, even automated calls. To maximize engagement you'll want several of them.

Every channel means picking a vendor, learning its API, testing quality of service, monitoring it, and planning a fallback. A common way to keep this manageable is an adapter layer:

class ChannelAdapter:
    def send(self, payload) -> DeliveryResult: ...

class SendgridAdapter(ChannelAdapter): ...
class TwilioAdapter(ChannelAdapter): ...
class FcmAdapter(ChannelAdapter): ...

Your core logic talks to one interface, and vendor quirks stay at the edges.

2. Templating engine

Templates quietly become the biggest ownership burden. They need constant changes for copy, personalization, branding, dynamic variables, conditional logic, multi-lingual support, and correct rendering across devices.

Each channel also has different strengths:

Email: long, detailed content
SMS: short and attention-grabbing
Push: rich media and action buttons

If every copy change needs a deploy, your engineers become a bottleneck. The fix is a visual editor so PMs and marketers can build and test without a pull request.

3. User preferences

Marketing emails get a simple unsubscribe link. Product notifications are trickier, because users want some of them (security alerts) and not others (weekly tips).

A decent preference system lets users control:

Type: which categories they get
Channel: where they get them
Frequency: instant, hourly, daily or weekly digest
Timing: quiet hours

def should_send(user, notification):
    prefs = get_preferences(user.id)
    if notification.category not in prefs.enabled_categories:
        return False
    if in_quiet_hours(user, prefs) and not notification.is_critical:
        return reschedule(notification, prefs.quiet_hours_end)
    return True

Without this, users do the only thing they can: block everything.

4. Batching and digests

Say your product has comments. If 20 people reply to a thread, you don't want 20 notifications. You want one: "20 new comments."

Batching: define a window, collect events inside it, then send one combined message.
Digests: send a summary at a cadence the user chooses, such as hourly, daily or weekly.

Depending on the notification type, you may need both.

5. Multi-tenancy

If your product serves other businesses and sends notifications to their users, you need tenant-level isolation and customization: their branding, their sending domain, their channels, their preference rules.

Example: a SaaS tool sending invoices on behalf of customers. The end user doesn't know your brand, so the email must carry your customer's logo, content and sender identity, all running on shared infrastructure.

6. Analytics

PMs need delivery, open and click data to improve notifications. But every channel and vendor reports differently, and some metrics don't exist (you can't track opens on SMS).

That means you need a normalized event model, so cross-channel analysis is possible:

{
  "event": "delivered",
  "channel": "email",
  "notification_id": "n_123",
  "user_id": "u_456",
  "timestamp": "2026-10-14T10:32:00Z"
}

Map vendor webhooks into this shape and you can compare channels apples to apples.

Part 2: Non-functional components

This is the stuff nobody sees until it breaks.

1. Scalability and load balancing

Notification traffic spikes unexpectedly: a flash sale, a viral feature, an incident. Design for bursts, and balance load across servers and regions.

2. Fault tolerance and retries

Downtime isn't acceptable for OTPs or compliance messages. You need redundancy, state management, fallback vendors, and rate-limit-aware throttling per channel.

One subtle point: not every failure deserves a retry. An expired push token is dead, and retrying it just wastes resources.

RETRYABLE = {"timeout", "rate_limited", "vendor_5xx"}
PERMANENT = {"invalid_token", "unsubscribed", "bounced"}

def handle_failure(msg, reason):
    if reason in RETRYABLE:
        retry_with_backoff(msg)
    elif reason in PERMANENT:
        mark_channel_inactive(msg.user_id, msg.channel)

Understanding why something failed matters as much as retrying it.

3. High deliverability

Reaching the user involves several things at once: multiple channels, reliable vendors, cleaning inactive contacts, and managing bounces.

4. Low latency

People expect notifications fast. Cut network round trips, optimize database queries, and shorten delivery paths. It's ongoing work, because performance degrades as you scale.

5. Observability

You need detailed logging, error tracking and performance monitoring so you can diagnose failures quickly and answer compliance questions. If you can't answer "what happened to this user's notification?", debugging becomes guesswork.

6. Message queue prioritization

This one saves a lot of pain. An OTP and a weekly newsletter shouldn't share a queue. If bulk sends clog the pipeline, login codes get delayed and drop-off rises.

Use separate queues with their own throughput limits:

QUEUES = {
    "critical": {"workers": 20, "rate": "unlimited"},   # OTP, security
    "high":     {"workers": 10, "rate": "1000/s"},      # transactional
    "low":      {"workers": 3,  "rate": "200/s"},       # promos, digests
}

This protects critical messages without over-provisioning for everything.

To build or not to build?

Here's a quick framework.

Build in-house when:

Your needs are simple. Few notification types, low volume, rare changes, a single channel. Direct vendor integration or a lightweight internal service will do.
You need heavy customization. Your use case is unusual enough that third-party platforms can't support it (like a chatbot over SMS).
Notifications are your product. If you're something like WhatsApp, owning it makes sense.

Consider alternatives when:

Resources are limited. Building and maintaining this takes real engineering capacity.
Time to market matters. A third-party service can get you live far faster.
You need complex features. Workflows, white-labeling, preferences, personalization, batching and cross-channel logic come ready-made on established platforms.
You want to focus on your core product. Getting notifications right takes experimentation, channel expertise, scaling work and observability, which pulls attention from what makes your product special.

This is the layer we built SuprSend to handle, so teams can skip the plumbing. Full disclosure: we work on SuprSend, so weigh that accordingly. The checklist above holds whichever way you go.

Wrapping up

A good notification service balances two sides. The functional side gives product teams control over templates, preferences and analytics. The non-functional side gives everyone reliability, speed and visibility. Skipping either one hurts.

Whichever path you choose, the goal is the same: a smooth, meaningful experience that keeps users connected.

Over to you: did you build your notification system in-house or use a platform? What's the one component you wish you'd planned for earlier? Tell us in the comments.

Notifications Are Not Just an API Call: 11 Reasons They Quietly Eat Your Sprint

Nikita Navral — Tue, 13 Oct 2026 13:24:26 +0000

Every product team starts the same way: "We just need to send an email when someone signs up." One SDK, one template, done by Friday.

Six months later you have four channels, three vendors, a pile of cron jobs, and a PM asking whether the payment reminder copy can be changed without a deploy.

Notifications look trivial and behave like infrastructure. They're how your product talks to users: alerts, reminders, recommendations, launches, even user-to-user messages. Send too little and the experience breaks. Send too much and people unsubscribe. Here are the 11 places where it gets hard.

1. Trivial tasks that keep landing on engineers

Notification logic is rarely hard. What's hard is iteration. Getting the content, trigger and timing right takes many tries, and PMs want to move fast. But when templates and triggers live in code, every tweak joins the sprint queue. Adding a new channel to an existing notification multiplies the work again.

The fix: let non-engineers edit content and logic without a deploy.

2. Nobody knows what's actually live

Before building a new notification, you need to know what already exists. Answering that means digging through the code or trusting a shared doc that went stale weeks ago. With several PMs involved, legacy notifications keep running because nobody wants to audit them. Cleanup becomes a once-or-twice-a-year project.

3. Testing is a coordination problem

Testing notifications isn't technically complex, but it eats time. Test sends often go to one shared device or account that not everyone can access. Scheduled notifications usually need a developer to trigger them manually whenever QA or a PM wants to check them. That's a lot of context switching for something that should be self-serve.

4. Scaling exposes the cracks

As volume grows, delivery reliability becomes your problem.

No priority separation. If a promotional blast clogs the queue, your OTP sits behind it. Scaling everything up to compensate gets expensive. What you want is immediate delivery for transactional messages and staggered delivery for promotional ones:

# Pseudocode: route by priority so promos never block transactional
queue = "transactional" if msg.category in ("otp", "payment", "security") else "promotional"
publish(queue, msg)

No fallback or retries. If the provider API is down, queued messages are lost, and so is important communication. You need retries and a fallback path.

No failure alerts. Many teams only learn about failed deliveries when the business team or a customer complains. In the worst case, they never find out. Treat delivery failures like server downtime and alert on them.

Stale deliveries. A delayed message that arrives two weeks later, like a "payment debited" notice, is worse than no message. Put an expiry on time-sensitive notifications:

# Drop the message if it's too old to be useful
if now() - msg.created_at > msg.ttl:
    mark_expired(msg)
    return

It sounds like a rare edge case, but it leaves a bad impression when it happens.

5. Analytics are scattered

Each vendor gives you its own dashboard, which makes it hard to compare delivery and click rates across channels. User-level analytics are even rarer. How many messages did one user get this week? Did several fire at once? What does the overall experience feel like from their side? Without that view, users end up either under-engaged or bombarded.

6. Multi-channel is a tightrope

Reaching users on every channel raises conversion, but it also raises unsubscribes. It's also costly to send the same message on three channels when the user saw it on the first.

A smarter approach staggers delivery across channels based on past behavior and message type:

Push -> wait 30 min -> not seen? -> Email -> wait 24h -> not seen? -> SMS

That saves money and avoids spamming people.

7. Sending to dead channels

People change numbers and leave companies. Messages to inactive contacts cost money, and high email bounce rates damage your domain reputation, which can push future emails into spam. Most tools report a bounce only after you've sent. It's far better to filter out inactive channels in advance and keep your contact data clean.

8. Multi-lingual support

Expanding into non-English markets means storing each user's language preference and maintaining a template per language, per channel. The engineering effort grows quickly, even though the logic stays the same.

9. Users want a say

Letting users choose what they get notified about is good engagement strategy. Without granular preferences, many users take the only option available and unsubscribe from everything, which hurts engagement and sales. Quora is a good example: users can opt out of specific types of emails without leaving entirely.

10. One-size-fits-all frequency

Engagement notifications usually run on a fixed schedule, because custom frequency per user isn't feasible by hand. The result is endless reminders for users who aren't interested, while engaged users could be getting more.

A smarter system adapts to behavior: send more when users respond, back off when they go quiet, and try a different way to re-engage. That requires per-user data processing feeding back into the delivery pipeline, which most startups can't justify building. So they settle for light personalization and a frequency cap. It works, but it leaves engagement on the table.

11. Vendor lock-in and reliability

No vendor guarantees 100% uptime. For time-sensitive messages like OTPs, you need a fallback vendor. But every vendor has its own API and integration rules, so each one costs real engineering time:

for vendor in ["vendor_a", "vendor_b"]:
    try:
        return send(vendor, msg)
    except VendorError:
        continue
raise DeliveryFailed(msg.id)

Looks simple, until you maintain two or three vendors' payload formats, webhooks and error codes. Most teams stay with one vendor per channel until an outage forces the issue, or pick a multi-channel vendor that may not be the cheapest option.

Wrapping up

None of these problems is impossible alone. Together, they turn "just send a notification" into a standing drain on your team's time.

That's the problem we're building SuprSend to solve, so engineering teams can stop reinventing notification infrastructure and focus on their core product.

Now I'm curious: how does your team handle notifications today? Home-grown service, a single vendor, or something else? What's been the biggest pain point? Let us know in the comments.

How to Choose the Right Notification Infrastructure for Your App or Website

Nik L. — Mon, 02 Sep 2024 13:29:40 +0000

Breaking Down the Essentials of Notification Infrastructure

To build a resilient notification infrastructure, it’s important to be familiar with its key components:

Message Queues and Brokers: The Notification Backbone The backbone of any robust notification infrastructure is the message queue, which manages the flow of notifications. By processing messages asynchronously, message queues help avoid bottlenecks and ensure fault tolerance within your notification system. These queues temporarily store and then dispatch notifications as needed.

Message brokers like RabbitMQ and Apache Kafka play a crucial role in managing these processes within your notification infrastructure. RabbitMQ supports the AMQP protocol and provides features like message acknowledgments, making it a reliable choice for notification management. Kafka, known for its ability to handle large volumes of data with minimal delay, is an ideal solution for applications that need to process real-time streams.

Real-time Communication Protocols: For Instant Updates Real-time updates are a vital component of any notification infrastructure. Protocols such as WebSocket and HTTP/2 are essential for delivering notifications instantaneously. WebSocket allows for continuous, two-way communication between the client and server, which is particularly useful for live chat or real-time notification alerts.

HTTP/2, an improvement over HTTP/1.1, enhances your notification infrastructure by reducing latency through multiplexing and header compression. This ensures that notifications reach users quickly and efficiently.

Databases and Data Stores: Powering Personalization Personalization is a critical aspect of a successful notification infrastructure. Databases and data stores are the engines that power this personalization by storing user preferences and notification data.

Redis, a commonly used in-memory key-value store, is integral to many notification infrastructures due to its speed. It allows for rapid retrieval of user-specific data, enabling your system to deliver personalized notifications without delay.

Scalable Server Clusters: Ready for Growth As your user base expands, so does the demand on your notification infrastructure. Scalable server clusters are essential for handling this growth by distributing the load across multiple servers. This distribution ensures that your notification system remains responsive, even during peak usage times.

Load balancers play a vital role in this aspect of your notification infrastructure by evenly distributing traffic. Additionally, adopting a microservices architecture allows individual components of your notification system to scale independently, making it easier to manage and maintain as your app grows.

Key Technical Considerations for Building a Notification Infrastructure

When designing your notification infrastructure, several critical aspects need to be considered to ensure it meets your needs:

Reliability and Redundancy: Ensuring Continuous Operation
A reliable notification infrastructure must minimize downtime and ensure continuous operation. Incorporating redundancy within your infrastructure means having backup systems that can take over if the primary ones fail. Failover mechanisms are also essential; they automatically switch to backups to keep your notifications flowing smoothly, regardless of any issues.
Scalability: Handling Demand Fluctuations
Scalability is a key consideration for any notification infrastructure, particularly as your user base grows. Horizontal scaling, which involves adding more servers to handle increased load, is a critical feature of scalable notification systems. A microservices architecture further enhances scalability by allowing different parts of the notification infrastructure to scale independently, maintaining high performance under varying workloads.
Customization and Personalization: Delivering Relevant Content
Customization and personalization are vital for an effective notification infrastructure. Notifications need to be tailored to user preferences and behaviors to maximize engagement. This requires a sophisticated approach to data handling, enabling your notification system to generate and deliver personalized content in real-time.
Security: Protecting User Data
Security is a cornerstone of any notification infrastructure. Ensuring that all data transmitted through your notification system is encrypted protects it from unauthorized access. Authentication mechanisms validate users and systems accessing the infrastructure, while data protection measures ensure compliance with privacy regulations.
Data Analytics and Monitoring: Gaining Real-time Insights
Real-time analytics and monitoring are essential components of a modern notification infrastructure. Monitoring tools like Prometheus and Grafana provide insights into system performance, allowing you to detect and address issues promptly. These tools help you optimize your notification infrastructure over time, ensuring it continues to meet user needs efficiently.

Enhancing Your Notification Infrastructure with Specialized Services

Specialized services like SuprSend can significantly enhance your notification infrastructure, making it more efficient and easier to manage:

Streamlined API Integration
SuprSend offers APIs that streamline the integration of notifications into your app or website. This simplifies the development process, ensuring that your notification infrastructure is both robust and easy to maintain.
Advanced Routing and Filtering
Precision is key in a well-functioning notification infrastructure. SuprSend’s advanced routing and filtering capabilities allow you to target notifications effectively, ensuring that the right messages reach the right users at the right time.
Push and Pull Mechanisms
Flexibility is another critical component of a successful notification infrastructure. SuprSend supports both push notifications, which actively send updates to users, and pull mechanisms, where users request updates. This flexibility allows your notification system to adapt to different user needs and scenarios.

You can see more of our engineering blogs here:

How Redis Solved Our Challenges with Dynamic Task Scheduling and Concurrent Execution [Developer's Guide]
- Discusses how Redis helped overcome challenges related to dynamic scheduling and concurrent task execution for syncing client data from a data warehouse to a store. The solution initially relied on goroutines, SQLite, and a Go service, but needed optimization for SaaS scalability.
Comparing Notification Infrastructure & Marketing Automation Tools: A Guide to Choose the Right Platform for Your Product
- Provides insights on when to choose marketing automation tools like Braze or Customer.io and when to opt for notification infrastructure tools like SuprSend, based on product needs.
Dynamically Syncing In-app Notification Center Theme with Application's Current Theme State
- Explains how to customize the app's inbox notification center to sync dynamically with the application's theme, enhancing user experience.
How Can SaaS Tools Enhance User Engagement with Notifications Channel Routing (like LinkedIn)?
- Demonstrates how SaaS tools can efficiently route notifications across different channels (e.g., email to SMS) based on availability, similar to LinkedIn's notification system, to enhance user engagement.
How to Batch Notifications for your Social Media/ Collaborative Application?
- Learn how to batch multiple notifications to streamline communication, as seen in platforms like Instagram, LinkedIn, and Google Workspace.

Building and Optimizing a Notification System and Infrastructure

Nik L. — Fri, 09 Aug 2024 16:02:58 +0000

If you're reading this, you likely understand how important it is to send timely notifications to boost user interaction and grow your business. Whether you're notifying users about new messages, upcoming events, or status updates, having a reliable notification system is crucial.

Creating a notification system in-house is challenging. It requires detailed planning, development, and ongoing maintenance. This article will break down the main parts of a notification system. By the end, you'll understand what’s needed to build one in-house, the challenges you might face, and what approach suits your company best.

Key Components of a Notification System

A well-functioning notification system has several key parts that work together. Here’s a look at each part:

Delivery Channels & Vendor Integrations:

Delivery channels are how notifications reach users. To maximize engagement, you need to support multiple channels like email, SMS, in-app messages, push notifications, WhatsApp, Slack/Teams, and automated calls. Integrating with these channels can be complex, requiring vendor evaluation, API integration, service quality checks, and fallback strategies.

Templating Engine:

A notification system must create messages that fit each channel. Emails might include detailed information, while SMS should be brief. Push notifications can include multimedia and interactive elements. Managing templates involves handling copywriting, personalization, branding, dynamic content, multilingual support, and testing. A visual editor for non-engineers can help manage these templates.

User Preferences:

Proper targeting helps avoid notification fatigue and keeps users happy. Users should have control over what notifications they receive, how often, and through which channels. You need an easy-to-use interface for users to set their preferences, including types of notifications, channels, frequency, and timing. Allowing users to opt in or out of notifications helps prevent them from blocking all communications.

Batching & Digest:

For some notifications, grouping several alerts into one message can be better than sending multiple separate alerts. For example, if there are several comments, it’s better to batch them and send them together. Summary digests can also be sent at user-preferred intervals (e.g., hourly, daily, weekly) to keep users updated without overwhelming them.

Multi-Tenancy Support:

If your system serves multiple customers, it needs to handle multi-tenancy. This means isolating data, customizing notifications for each customer, and supporting branding and preferences for each tenant. For example, a SaaS platform sending invoices needs to use the customer’s branding and preferences in notifications.

Notification Analytics:

To improve notifications, you need to track their performance. Metrics like delivery rates, open rates, and user engagement are crucial. Different channels have different tracking methods, so standardizing how you measure user actions is important for effective analysis.

Non-Functional Aspects of Notification Systems

Reliable and efficient notification services also depend on several non-functional components:

Scalability & Load Balancing:

Notification services must handle varying levels of traffic. Ensuring scalability helps manage increased loads without performance issues. Load balancing across servers and regions keeps the service available and responsive.

Fault Tolerance, Redundancy, & Failure Retries:

To avoid downtime, the system must have redundancy and failover plans. This includes managing state, using fallback vendors, controlling request rates, and retrying failed notifications when appropriate.

High Deliverability:

Ensuring notifications are delivered successfully involves managing multiple channels, choosing reliable vendors, and handling bounce rates. Keeping channels clean and active improves deliverability.

Low Latency:

Notifications should arrive quickly. Minimizing delay involves optimizing delivery routes, reducing network trips, and improving database queries. Continuous efforts are needed to maintain low latency as the system grows.

Observability & Diagnosis:

Monitoring and diagnosing issues are essential for smooth operation. Implementing detailed logging, error tracking, and performance monitoring helps identify and resolve problems quickly.

Message Queue Prioritization:

Not all notifications are equally important. High-priority notifications, like authentication alerts, should be sent immediately, while less urgent notifications, like newsletters, can be delayed. Prioritizing messages helps manage queue efficiency and control costs.

Deciding to Build or Buy

After understanding the components, you need to decide whether to build a notification system in-house or use an existing solution:

When to Build:

Simplicity: If your notification needs are minimal and infrequent, a simple integration or a basic central service might work.
Custom Needs: For highly specific requirements that third-party solutions can't meet, building a custom system is better.
Core Product: If notifications are central to your product, having full control through an in-house system may be necessary.

When to Consider Alternatives:

Resource Constraints: Limited engineering resources might make it more efficient to use existing services.
Time to Market: Using third-party solutions can speed up development and launch.
Complex Features: Established platforms often offer advanced features like workflows and cross-channel communication.
Focus on Core Competencies: Using external services allows you to focus on your main business rather than the complexities of notification management.

SuprSend is designed to handle the complexities of notification orchestration for you.

As an engineering leader, consider your company's needs, resources, and long-term goals when deciding whether to build a notification system in-house or use a third-party solution. The goal is to create a seamless and engaging user experience.

Check out more of our engineering insights here:

How Redis Solved Our Challenges with Dynamic Task Scheduling and Concurrent Execution
The problem statement was simple, or so we thought. In our previous setup, we used goroutines for scheduling database queries, allowing us to run the whole setup on minimal setup with SQLite and go service. Seems simple enough, but when we decided to also have this feature on our SaaS platform, at the onset, we didn’t realize we would also be walking into a new set of challenges of dynamic scheduling and concurrent task execution.
We needed a way to sync data in a scheduled manner from the client's data warehouse to our data store.
Comparing Notification Infrastructure & Marketing Automation Tools
We discuss around when should one prefer marketing automation tools ike Braze, Cutomer.io and when does it make sense to check notification infrastructure tools like SuprSend.
Dynamically Syncing In-App Notification Center Theme with Application's Current Theme State
Showcasing some customization capabilities of our app inbox notification center
Enhancing User Engagement with Notifications Channel Routing
Learn how to do efficient notifications channel routing, i.e, if email is unavailable send on SMS with smart logic.

Send emails using Java (Javamail API or Simple Java Mail or SuprSend Java SDK)

Nik L. — Fri, 02 Aug 2024 04:43:06 +0000

Method 1: Using JavaMail API for Email Notifications

Overview:

The JavaMail API is a robust, platform-independent, and protocol-independent framework designed to support Java client applications in performing comprehensive email and messaging functionalities. This API offers a generic interface with abstract classes representing various objects created in transactional email systems. It is especially useful for enterprise-level applications where reliability and extensive functionalities are paramount.

Pros:

Well-Structured and Widely Adopted:
- JavaMail API is renowned for its solid structure and widespread usage, particularly in enterprise environments.
Versatile Functionality:
- It provides an extensive set of functionalities, including reading, composing, and sending emails.
Programmatic Integration:
- Simplifies the integration with other programs, making it easier to send confirmations and other messages programmatically.

Cons:

Extended Compilation Time:
- Developers may face longer code compilation times due to the API's complexity.
Memory Consumption:
- Using the JavaMail API can lead to significant consumption of Java heap space.

Implementation Steps:

Step 1: Installing JavaMail API

Include JAR files (mail.jar and activation.jar) in the CLASSPATH.
Configure an SMTP server (e.g., Pepipost) for email transmission.

Step 2: Setting Up the Mail Session

Create a session object with host information using javax.mail.Session.

Properties properties = new Properties(); 
Session session = Session.getDefaultInstance(properties, null);

Alternatively:

Properties properties = new Properties(); 
Session session = Session.getInstance(properties, null);

Network authentication:

Session session = Session.getInstance(properties, new javax.mail.Authenticator() {
  protected PasswordAuthentication getPasswordAuthentication() {
    return new PasswordAuthentication("sender@gmail.com", "password");
  }
});

Step 3: Composing the Email

Use the javax.mail.internet.MimeMessage subclass to set the sender, receiver, subject, and message body.

MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress(from));
message.addRecipient(Message.RecipientType.TO, new InternetAddress(to));
message.setSubject("This is the email subject");
message.setText("This is the email body");

Step 4: Adding Attachments

To include attachments, create a Multipart object and add a BodyPart for each attachment.

Multipart multipart = new MimeMultipart();

BodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setText("This is the email body");
multipart.addBodyPart(messageBodyPart);

messageBodyPart = new MimeBodyPart();
DataSource source = new FileDataSource("path/to/attachment.txt");
messageBodyPart.setDataHandler(new DataHandler(source));
messageBodyPart.setFileName("attachment.txt");
multipart.addBodyPart(messageBodyPart);

message.setContent(multipart);

Step 5: Sending the Email

Use the javax.mail.Transport class to send the email.

Transport.send(message);

Complete Code Example:

import java.util.Properties;
import javax.mail.*;
import javax.mail.internet.*;
import javax.activation.*;

public class SendMail {
    public static void main(String[] args) {
      String to = "receiver@gmail.com";
      String from = "sender@gmail.com";
      String host = "smtp.gmail.com";

      Properties properties = System.getProperties();
      properties.put("mail.smtp.host", host);
      properties.put("mail.smtp.port", "465");
      properties.put("mail.smtp.ssl.enable", "true");
      properties.put("mail.smtp.auth", "true");

      Session session = Session.getInstance(properties, new javax.mail.Authenticator(){
        protected PasswordAuthentication getPasswordAuthentication() {
          return new PasswordAuthentication("sender@gmail.com", "password");
        }
      });

      try {
        MimeMessage message = new MimeMessage(session);
        message.setFrom(new InternetAddress(from));
        message.addRecipient(Message.RecipientType.TO, new InternetAddress(to));
        message.setSubject("Your email subject goes here");

        Multipart multipart = new MimeMultipart();
        BodyPart messageBodyPart = new MimeBodyPart();
        messageBodyPart.setText("You have a new message");
        multipart.addBodyPart(messageBodyPart);

        messageBodyPart = new MimeBodyPart();
        DataSource source = new FileDataSource("path/to/attachment.txt");
        messageBodyPart.setDataHandler(new DataHandler(source));
        messageBodyPart.setFileName("attachment.txt");
        multipart.addBodyPart(messageBodyPart);

        message.setContent(multipart);

        Transport.send(message);
      } catch (MessagingException mex) {
        mex.printStackTrace();
      }
   }
}

Method 2: Using Simple Java Mail for Email Notifications

Overview:

Simple Java Mail is a user-friendly mailing library designed to simplify the process of sending SMTP emails in Java. It serves as a wrapper around the JavaMail API, streamlining the email sending process by reducing the complexity of the underlying API.

Pros:

Robust and Lightweight:
- Simple Java Mail is robust while maintaining a lightweight footprint of 134kB.
RFC Compliance:
- It complies with all relevant RFCs, ensuring compatibility with various email clients.
Authenticated SOCKS Proxy Support:
- Supports sending emails through an authenticated SOCKS proxy.
Advanced Features:
- Offers support for HTML content, images, and attachments, and allows sending emails to multiple recipients simultaneously.

Cons:

Limited Community Support:
- The community support for Simple Java Mail is smaller compared to JavaMail API.

Implementation Steps:

Step 1: Creating an Email Object with HTML and Attachments

Email email = EmailBuilder.startingBlank()
    .from("From", "from@example.com")
    .to("1st Receiver", "rec1@example.com")
    .to("2nd Receiver", "rec2@example.com")
    .withSubject("Enhanced Email with HTML and Attachments")
    .withHTMLText("<html><body><h1>Hello!</h1><p>This is an enhanced email with HTML content.</p></body></html>")
    .withAttachment("path/to/attachment.txt")
    .buildEmail();

Step 2: Creating a Mailer Object using MailerBuilder

Mailer mailer = MailerBuilder
    .withSMTPServer("smtp.mailtrap.io", 2525, "username", "password")
    .withTransportStrategy(TransportStrategy.SMTPS)
    .buildMailer();

Step 3: Sending the Enhanced Email

mailer.sendMail(email);

Complete Code Example:

import org.simplejavamail.api.email.Email;
import org.simplejavamail.email.EmailBuilder;
import org.simplejavamail.mailer.Mailer;
import org.simplejavamail.mailer.MailerBuilder;
import org.simplejavamail.api.mailer.config.TransportStrategy;

public class SendEnhancedMail {
    public static void main(String[] args) {
        Email email = EmailBuilder.startingBlank()
            .from("From", "from@example.com")
            .to("1st Receiver", "case1@example.com")
            .to("2nd Receiver", "case2@example.com")
            .withSubject("Enhanced Email with HTML and Attachments")
            .withHTMLText("<html><body><h1>Hello!</h1><p>This is an enhanced email with HTML content.</p></body></html>")
            .withAttachment("path/to/attachment.txt")
            .buildEmail();

        Mailer mailer = MailerBuilder
            .withSMTPServer("smtp.mailtrap.io", 2525, "username", "password")
            .withTransportStrategy(TransportStrategy.SMTPS)
            .buildMailer();

        mailer.sendMail(email);
    }
}

Method 3: Using SuprSend for Multichannel Notifications with JAVA SDKs

Overview:

SuprSend offers a comprehensive third-party multichannel notification infrastructure that supports sending notifications across various channels like email, SMS, and push notifications through a unified API. By leveraging SuprSend, developers can manage complex notification workflows seamlessly.

Key Features & Benefits:

Extensive Integration Options:
- Integrates seamlessly with over 50 Communication Service Providers (CSPs) and supports multiple channels including Mixpanel, Segment, Twilio, Mailchimp, Slack, Teams, SNS, Vonage, Whatsapp, and more.
No Tech Dependency:
- Manages the entire notification lifecycle without heavy reliance on the engineering team. Integrate the JAVA SDK once, and the product team can handle the rest.
Intelligent Routing:
- Implements intelligent cross-channel flows across providers without requiring technical dependencies.
In-App SDK:
- Provides a developer-ready in-app layer for both web and mobile applications.
Granular Template Management:
- Features an intuitive drag & drop editor for designing templates, offering superior control over content.
Powerful Workspace:
- Manages multiple projects with distinct integrations, workflows, and templates within each workspace.
Unified Analytics:
- Provides a unified view of cross-channel analytics, enabling data-driven decision-making.
Smart Automation:
- Automates synchronization, refreshing, and notification triggers to streamline operations.
Scalability:
- Automates scalability, ensuring a hassle-free experience.

Cons:

Cost Considerations:
- Managing multiple notification channels may incur costs.
*Monthly Notification Limit:*
- Though SuprSend provides 10k notifications free every month, which resets every month, you can also buy credits.

Limits:**

There may be restrictions on the number of notifications per month.

Implementation Steps:

Step 1: Integrating the JAVA SDK

Install the SuprSend JAVA SDK:
- Add the SDK to your JAVA project via Maven or Gradle.

Step 2: Configuring the API Key and Workspace Secret

Set Up Configuration:
- Obtain the API key and workspace secret from your SuprSend account and configure them in your JAVA project.

Step 3: Creating and Sending Notifications

Send Notifications via JAVA SDK:
- Use the SDK to send notifications, specifying the required channel (email, SMS, push, etc.) and the content.

import com.suprsend.Notification;
import com.suprsend.NotificationBuilder;
import com.suprsend.SuprSendClient;

public class SendNotification {
    public static void main(String[] args) {
        // Initialize the SuprSendClient with API key and Workspace Secret
        SuprSendClient client = new SuprSendClient("your_api_key", "your_workspace_secret");

        // Build the notification
        Notification notification = NotificationBuilder.startingBlank()
            .withRecipientEmail("recipient@example.com")
            .withRecipientSMS("recipient_phone_number")
            .withSubject("Notification Subject")
            .withHTMLBody("<html><body><h1>Hello!</h1><p>This is a multichannel notification.</p></body></html>")
            .build();

        // Send the notification
        client.sendNotification(notification);
    }
}

Complete Code Example with JAVA SDK:

import com.suprsend.Notification;
import com.suprsend.NotificationBuilder;
import com.suprsend.SuprSendClient;

public class SuprSendExample {
    public static void main(String[] args) {
        // Initialize the SuprSendClient with API key and Workspace Secret
        SuprSendClient client = new SuprSendClient("your_api_key", "your_workspace_secret");

        // Create the notification
        Notification notification = NotificationBuilder.startingBlank()
            .withRecipientEmail("receiver@example.com")
            .withSubject("Subject of the Notification")
            .withHTMLBody("<html><body><h1>Hello!</h1><p>This is a notification from SuprSend.</p></body></html>")
            .withAttachment("path/to/attachment.txt")
            .build();

        // Send the notification
        client.sendNotification(notification);
    }
}

These methods offer a comprehensive guide to sending email notifications using Java, with varying levels of complexity and integration capabilities to suit different needs and scenarios.

You may want to check out other SuprSend SDKs too. Consider giving us a star after usage. It's free and open.

suprsend / suprsend-go

SuprSend SDK for go

suprsend-go

SuprSend Go SDK

Installation

go get github.com/suprsend/suprsend-go

Usage

Initialize the SuprSend SDK

import (
    "log"

    suprsend "github.com/suprsend/suprsend-go"
)

func main() {
    opts := []suprsend.ClientOption{
        // suprsend.WithDebug(true),
    }
    suprClient, err := suprsend.NewClient("__api_key__", "__api_secret__", opts...)
    if err != nil {
        log.Println(err)
    }
}

Trigger Workflow

package main
import (
    "log"

    suprsend "github.com/suprsend/suprsend-go"
)

func main() {
    // Instantiate Client
    suprClient, err := suprsend.NewClient("__api_key__", "__api_secret__")
    if err != nil {
        log.Println(err)
        return
    }
    // Create WorkflowTriggerRequest body
    wfReqBody := map[string]interface{}{
        "workflow": "workflow-slug",
        "recipients": []map[string]interface{}{
            {
                "distinct_id": "0f988f74-6982-41c5-8752-facb6911fb08",
                // if $channels is present, communication will be tried on mentioned channels only (for this request).
                // "$channels": []string{"email"},

…

View on GitHub

suprsend / suprsend-py-sdk

SuprSend SDK for python3

suprsend-py-sdk

This package can be included in a python3 project to easily integrate with SuprSend platform.

Installation

suprsend-py-sdk is available on PyPI. You can install using pip.

pip install suprsend-py-sdk

This SDK depends on a system package called libmagic. You can install it as follows:

# On debian based systems
sudo apt install libmagic

# If you are using macOS
brew install libmagic

Usage

Initialize the SuprSend SDK

from suprsend import Suprsend
# Initialize SDK
supr_client = Suprsend("workspace_key", "workspace_secret")

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__

from suprsend import WorkflowTriggerRequest
# Prepare Workflow body
wf = WorkflowTriggerRequest(
  body={
    "workflow": "purchase-made"
    "recipients": [
        {
          "distinct_id": "0f988f74-6982-41c5-8752-facb6911fb08",
          # if $channels is present, communication will be tried on mentioned

…

View on GitHub

suprsend / suprsend-node-sdk

Official SuprSend SDK for Node.js

suprsend-node-sdk

This package can be included in a node project to easily integrate with SuprSend platform.

Installation

npm install @suprsend/node-sdk@latest

Initialization

const { Suprsend } = require("@suprsend/node-sdk");

const supr_client = new Suprsend("workspace_key", "workspace_secret");

Trigger workflow from API

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.

const { Suprsend, WorkflowTriggerRequest } = require("@suprsend/node-sdk");
const supr_client = new Suprsend("workspace_key", "workspace_secret");

// workflow payload
const body = {
  workflow: "_workflow_slug_",
  actor: {
    distinct_id: "0fxxx8f74-xxxx-41c5-8752-xxxcb6911fb08",
    name: "actor_1",
  },
  recipients: [
    {
      distinct_id: "0gxxx9f14-xxxx-23c5-1902-xxxcb6912ab09",
      $email: ["abc@example.com"

…

View on GitHub

suprsend / suprsend-react-inbox

SuprSend SDK for integrating inbox functionality in React applications

@suprsend/react-inbox

Integrating SuprSend Inbox channel in React websites can be done in two ways:

SuprSendInbox component which comes with UI and customizing props.
SuprSendProvider headless component and hooks, incase you want to totally take control of UI. (example: Full page notifications).

Detailed documentation can be found here: https://docs.suprsend.com/docs/inbox-react

Installation

You can install SuprSend inbox SDK using npm/yarn

npm install @suprsend/react-inbox

SuprSendInbox Integration

After installing, Import the component in your code and use it as given below. Replace the variables with actual values.

import SuprSendInbox from '@suprsend/react-inbox'
import 'react-toastify/dist/ReactToastify.css' // needed for toast notifications, can be ignored if hideToast=true

// add to your react component;
<SuprSendInbox
  workspaceKey='<workspace_key>'
  subscriberId='<subscriber_id>'
  distinctId='<distinct_id>'
/>

interface ISuprSendInbox {
  workspaceKey: string
  distinctId: string | null
  subscriberId: string | null
  tenantId?: string
  stores?: IStore[]
  pageSize?: number
  pagination?: boolean

…

View on GitHub

App Inbox Notification Feed in Next.js

Nik L. — Fri, 02 Aug 2024 04:28:01 +0000

A notification center in a Next.js app acts as a central hub where users can access all their notifications anytime. This feature enhances user engagement and ensures no important updates are missed. In this tutorial, we'll guide you through creating a comprehensive notification center in a Next.js application, including backend setup and frontend development for a user-friendly notification feed.

By following this guide, you'll develop a fully functional notification system in your Next.js app with real-time updates. This implementation will enhance your app's user experience and provide a scalable solution for managing notifications.

Key topics include:

Setting up a Next.js project for your notification center.
Building a backend with Node.js and Express to handle notifications.
Creating and integrating a frontend notification widget with the backend.
Implementing real-time updates for an up-to-date notification feed.
Styling the notification UI for responsiveness and user-friendliness.

No matter if you call it an in-app inbox, notification widget, or alert center, the principles and steps remain consistent. Let's get started on building your Next.js notification center!

Prerequisites

Knowledge of Next.js
SuprSend account with a secret key and token
A Next.js application

Where will we build our app inbox in Next.js?

For this tutorial, we've created a demo Next.js project called b2b2c-freight_company available on GitHub. The application is also deployed on Vercel, allowing you to see the real-time notification feed here: Freight B2B2C App.

Building a real-time notification center in Next.js

Step 1: Creating an account on SuprSend

Start by signing up on SuprSend. After onboarding, navigate to Developers → API Keys in the side panel to find your Workspace Key and Workspace Secret.

Step 2: Finding the right place for your app inbox

Typically, the app inbox is located in the header with other menu options. Alternatively, it can be an option in the side panel for a full-page notification center, similar to LinkedIn. In our case, we'll implement the notification center in the navigation header. Relevant code is available here.

Step 3: Installing and integrating SuprSendInbox in Next.js

Install the SuprSend App Inbox Package: ```bash

npm install @suprsend/react-inbox


2. **Import Necessary Packages**:
   ```javascript


   import 'react-toastify/dist/ReactToastify.css';

Disable Server-Side Rendering for SuprSend: ```javascript

import dynamic from 'next/dynamic';

const SuprSendInbox = dynamic(() => import('@suprsend/react-inbox'), { ssr: false });


4. **Place the SuprSendInbox Component**:
   ```javascript


   const workspaceKey = process.env.NEXT_PUBLIC_SUPRSEND_WORKSPACE_KEY || '';
   const subscriberId = process.env.NEXT_PUBLIC_SUPRSEND_SUBSCRIBER_ID || '';
   const distinctId = process.env.NEXT_PUBLIC_SUPRSEND_DISTINCT_ID || '';

   export default function HomePage() {
     return (
       <div className="flex min-h-screen bg-gray-900 text-white">
         <div className="fixed top-0 right-0 m-4 z-50">
           <SuprSendInbox
             workspaceKey={workspaceKey}
             subscriberId={subscriberId}
             distinctId={distinctId}
             themeType="dark"
           />
         </div>
       </div>
     );
   }

Styling the App Inbox Component: If using Tailwind CSS, integrate the inbox into your navigation panel and customize it: ```javascript

workspaceKey={workspaceKey}
subscriberId={subscriberId}
distinctId={distinctId}
themeType="dark"
/>



   Customize using props like workspaceKey, subscriberId, distinctId, and themeType. More details are in the SuprSend documentation.

  
  
  Step 4: Setting environment variables


Ensure you set the following in your .env file:



NEXT_PUBLIC_SUPRSEND_WORKSPACE_KEY=your_workspace_key
NEXT_PUBLIC_SUPRSEND_SUBSCRIBER_ID=your_subscriber_id
NEXT_PUBLIC_SUPRSEND_DISTINCT_ID=your_distinct_id


</code></pre></div><h4>
  <a name="step-5-setting-triggers-for-notifications" href="#step-5-setting-triggers-for-notifications">
  </a>
  Step 5: Setting triggers for notifications
</h4>

<p>With your app inbox set up and visible, configure triggers for sending notifications using any backend SDK. We will use the Node SDK. Documentation for sending and triggering events is available <a href="https://suprsend.com">here</a>.</p>

<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m8w4qa0sbhl3vuzt64ur.png" alt="Image description"></p>
<h3>
  <a name="key-points" href="#key-points">
  </a>
  Key Points
</h3>

<ul>
<li>Disable server-side rendering, as the app inbox operates only on the client side.</li>
<li>For generating the subscriber key, perform HMAC authentication using any backend SDK.</li>
</ul>

<p>Integrating a notification center in your Next.js app significantly boosts user engagement and ensures crucial messages are never missed. By following these steps, you can effectively implement the SuprSend app inbox, optimizing performance and functionality with dynamic import and client-side rendering. </p>

<p>This approach provides extensive customization options, fitting seamlessly within your existing design. With this robust notification system, you can focus on building more features, knowing your users are always informed and engaged. Happy coding!</p>

How to Batch Notifications Across Users in a Dedicated Time Window? w/ Example Github Application

Nik L. — Thu, 04 Jul 2024 05:38:31 +0000

Batching notifications is a feature widely adopted by major social media platforms and collaborative tools like LinkedIn, MS Teams, and Google Workspace products. This technique consolidates multiple alerts into a concise summary within a single notification, creating a clutter-free user experience and reducing interruptions.

For hands-on implementation, please refer to the provided GitHub repository and deployed application links:

GitHub: SuprSend Social App
Deployed Application: SuprSend Demo

Benefits of Batching Notifications

Frequent alerts can lead to notification fatigue, causing users to disengage. By batching notifications, we can maintain user attention and promote sustained interaction with our platform.

Technical Overview: How Batching Works

Batching notifications requires sophisticated workflows and significant development resources. Here's a closer look at the technical aspects:

Aggregation Engine:
- Efficiently aggregates related notifications, such as likes, shares, and comments, based on metadata attributes.
- Example: Instagram separates notifications for story likes and comments, ensuring clarity.
Batching Window:
- The batching window can be fixed (e.g., every 30 minutes) or dynamic (e.g., user-specific intervals).
- Example: LinkedIn batches email alerts for new messages every 30 minutes, while Google Docs batches comments based on user activity.
Scheduling:
- Determines the optimal time for delivering notifications, which could be immediately, at the end of a batching window, or at a strategic time.
- Example: SaaS companies often send a daily digest of activities the following morning.
Batched Message Presentation:
- Options range from simple counters to detailed summaries, balancing informativeness and engagement without overwhelming the user.
- Example: "Patrick and 3 others liked your photo" versus listing all activities.
Cancelling Aggregation:
- Adjusts the aggregation counter for counter-activities within the batching window.
- Example: If a user likes and then unlikes a post within the batching window, the counter is adjusted accordingly.

Practical Implementation Using SuprSend

Pre-requisites:

Account on SuprSend
Integration of SuprSend SDK in your project
Successful event calls made to SuprSend with necessary details

Steps to Implement Batching:

Identifying Triggers:
- Identify recurring events suitable for batching.
- Example: Trigger a Like_Event whenever someone likes a post in a React application using SuprSend's JavaScript SDK.

Setting Up Batch Parameters:
- Use SuprSend’s workflow builder to configure batching.
- Define batch window (fixed or dynamic), batch key (e.g., userName), and retain batch events (e.g., 15 objects).

This is the code I am using to send the event to SuprSend.

Creating Templates for Batched Events:
- Use SuprSend’s template editor and Handlebar Helpers to format notifications based on the batched event count.

Example Template that I used for this demo application using handlebars:

{{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}}

The final result would look like this:

Beyond Batching: Implementing Throttling

While batching reduces the total number of notifications, introducing throttling can further enhance user experience by limiting the frequency of notifications. By setting an upper limit on daily notifications, we ensure users are not overwhelmed even with multiple batches.

For hands-on implementation, please refer to the provided GitHub repository and deployed application links:

GitHub: SuprSend Social App
Deployed Application: SuprSend Demo

Incase you want to check out the Javascript SDK, you can head here: https://docs.suprsend.com/docs/javascript-sdk

React App Inbox with 0 Notification Costs.

Nik L. — Sun, 23 Jun 2024 08:32:01 +0000

Building a robust notification system in React can be a complex task. Juggling multi-channel notifications, real-time updates, and user interaction requires a powerful solution. Enter the SuprSend Inbox for React, a feature-packed library designed to simplify and elevate your app's notification experience.
Check out this video first to understand how will this notification infrastructure platform work?

Want to see inapp inbox in action first? Head here

2. Under the Hood

Frontend:

Built with TypeScript for type safety and enhanced developer experience.
Provides various UI components like notifications list, bell icon, and notification details view.
Customization options allow you to tailor the look and feel to match your app's branding.
Integrates seamlessly with popular state management libraries like Redux and Context.

Backend:

REST API for sending notifications, managing subscribers, and tracking user engagement.
Supports multiple notification channels like email, push notifications, and SMS via external integrations.
Scalable architecture ensures reliable performance even with high notification volumes.

Security:

HMAC authentication secures communication between your app and SuprSend's API.
Data encryption protects sensitive user information.

3. Integration Steps

Setup:

Install the @suprsend/react-inbox library using npm.
Configure the SuprSend SDK with your workspace key and subscriber ID.
Define optional settings like notification display format, custom icons, and initial visibility.

Integration:

Render the SuprSendInbox component in your React app layout.
Pass the configuration details as props to customize the Inbox's behavior and appearance.

import SuprSendInbox from '@suprsend/react-inbox'

// add to your react component
<SuprSendInbox
  workspaceKey= "<workspace_key>"
  subscriberId= "<subscriber_id>"
  distinctId= "<distinct_id>"
/>

Use SuprSend's API from your backend server to send notifications with rich content and metadata.
Leverage the SDK's event system to handle user interactions like clicking on notifications or marking them as read.

4. Advanced Features

Real-time Updates: WebSockets enable instant notification delivery, keeping the Inbox updated dynamically.
Custom Components: Build custom UI elements for specific notification types or personalize the Inbox layout with render props.
Offline Support: Store notifications locally for offline access and ensure a seamless user experience.
Deep Linking: Integrate notifications with internal app pages for smooth navigation upon clicking.
Data Analytics: Track user engagement metrics like notification open rates and click-through rates for optimization.

5. Technical Considerations

Choose appropriate notification channels based on your app's purpose and target audience.
Implement proper error handling mechanisms for API requests and network failures.
Design a user-friendly notification experience with clear visuals and intuitive interactions.

6. Resources

Send Push Notifications without Hassles of FCM Token Generation

Nik L. — Tue, 21 May 2024 14:56:07 +0000

Handling FCM tokens and marking the user state is a hassle that businesses doesn't want to get into. To solve for this, SuprSend provides you with all the popular languages SDK, with point install and integration.

Token Generation and Notification handled By SDK

You may use this option if all of your android push notifications are to be handled via SuprSend SDK. We recommend you use this method as it is just a single-step process to just register the service in your application manifest and everything else will be ready.


<!--If you are targeting to API 33 (Android 13) you will additional need to add POST_NOTIFICATIONS -->
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

<service
    android:name="app.suprsend.fcm.SSFirebaseMessagingService"
    android:enabled="true"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

Full documentation here:

React Native - Docs
Android - Docs
Flutter - Docs