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.
Top comments (0)