Loading...
Loading...
Bi-weekly engineering deep dives on auth, notifications, and developer infrastructure. No spam.
Sign Up for UpdatesPublished by Zyphr
It’s Monday morning, and you just picked up a Jira ticket to implement a standard "Welcome" flow for a new SaaS product. On the surface, it’s simple: send a welcome email, verify the user’s phone number via SMS, and trigger a push notification when their account setup is complete.
By lunch, you’re drowning in browser tabs. SendGrid is open to handle the transactional email templates. Twilio is open because your 10DLC registration is still pending for SMS. And the Firebase console is up, wrestling with a deprecated FCM legacy key that won’t play nice with your service worker. This is the fragmented reality of modern development. To fix this, you need a multi-channel notification api that unifies these disparate services into a single point of control.
This is the multi-channel mess. You’re currently managing three different SDKs, three distinct billing accounts, three sets of credentials, and three wildly different API patterns. Every time you need to update a user’s notification preferences, you have to write custom "glue code" to sync state across these disconnected platforms. This isn’t just annoying—it’s architectural debt that grows exponentially as the product scales. We built Zyphr because we believe notifications shouldn’t be a fragmented afterthought. When you treat email, SMS, and push as isolated silos, you’re building a fragile system that’s guaranteed to break the moment a vendor changes their API version or a billing credit expires. You can read more about why notifications belong in a single API architecture and why consolidating this layer is the only way to maintain engineering velocity.
The goal today is simple: we’re going to implement all three channels—email, SMS, and push—using a single SDK and one unified API key. And we’re going to do it in 15 minutes.
Before we touch the code, you'll need a Zyphr account. You can start on the free tier to follow along. Once you're in the dashboard, grab your ZYPHR_API_KEY from the settings panel. This key acts as your master passport for every communication channel we support.
The first thing you’ll notice about Zyphr is the lack of bundle bloat. Instead of importing three heavy libraries that each bring their own dependencies (and potential security vulnerabilities), you only need one package.
npm install @zyphr/sdk
In your Node.js backend or an Edge function, initialize the client. We designed the SDK with a single-client architecture. This means zyphr.emails, zyphr.sms, and zyphr.push all live under one umbrella, sharing the same authentication context and configuration.
import { Zyphr } from '@zyphr/sdk';
// Initialize once at the application level
const zyphr = new Zyphr(process.env.ZYPHR_API_KEY);
That’s it. You’ve just configured your entire notification infrastructure. No need to initialize separate providers for different regions or manage multiple connection pools. The SDK handles connection persistence and retries automatically.
Transactional emails—the workhorse of SaaS—are often the first point of failure. Most developers hardcode HTML strings into their functions (a nightmare for maintenance) or use external template builders that are disconnected from the codebase. This creates a friction point between design and engineering.
Zyphr uses Handlebars for templating, hosted directly on our platform. Let’s assume you’ve created a template in your dashboard with the slug welcome-email. This template likely has placeholders like {{firstName}} and {{loginUrl}}.
When you send an email, you aren't just firing a message into the void. You’re targeting a subscriberId. In Zyphr, a subscriber is a unified profile that maps a user’s email, phone number, and device tokens to a single ID—usually your internal user_id from your primary database.
async function sendWelcomeEmail(userId: string, name: string) {
try {
const { data, error } = await zyphr.emails.send({
subscriberId: userId,
template: 'welcome-email',
variables: {
firstName: name,
loginUrl: 'https://myapp.com/login',
},
});
if (error) throw new Error(error.message);
console.log(`Email dispatched: ${data.message_id}`);
} catch (err) {
// Zyphr throws typed errors for common issues
console.error('Failed to send email:', err);
}
}
By passing dynamic variables directly into the send request, you keep your business logic clean. The SDK handles the rendering on our side, so your server doesn't waste CPU cycles processing complex strings. If your marketing team wants to change the "Welcome" copy or adjust the brand colors, they can do it in the dashboard without you ever touching the code or triggering a new deployment. For more complex use cases, check out the full SDK reference to see how to handle attachments, custom headers, and CC/BCC logic.
SMS is the "break glass" channel. It’s for one-time passwords (OTPs), security alerts, and high-urgency notifications. The problem with traditional SMS providers is the overhead of global routing. You shouldn't have to care about the difference between a long-code in the US, a short-code in the UK, or an Alphanumeric Sender ID in Germany. The platform should handle that automatically.
Since we’ve already initialized the Zyphr SDK, sending an SMS is just a matter of switching namespaces. We don't need a new library. We don't need to configure a new transport layer.
const sendOtp = async (userId: string, phoneNumber: string, code: string) => {
await zyphr.sms.send({
subscriberId: userId,
to: phoneNumber, // Can be omitted if the number is already on the profile
body: `Your verification code is ${code}. It expires in 5 minutes.`,
});
};
Zyphr automatically handles the routing and delivery tracking. If you’ve already associated a phone number with the subscriberId during the registration phase, you can even omit the to field entirely. The platform knows where to send it based on the subscriber’s profile. This level of abstraction—treating the "destination" as a property of the user rather than a parameter of the message—is what prevents the typical "state-sync" bugs found in multi-vendor stacks.
One major pain point with SMS is 10DLC (10-Digit Long Code) registration and compliance. Zyphr provides a simplified interface to manage these registrations. Instead of filling out spreadsheets for Twilio, you provide your brand details once in the Zyphr console, and we apply those settings across all your SMS traffic. This ensures high deliverability rates without the manual labor of carrier vetting.
Push notifications are notoriously difficult to implement correctly. You usually have to manage APNs certificates for Apple and FCM server keys for Google. Then, you have to handle token expiration, device registration, and the inevitable "token mismatch" errors that occur when a user re-installs an app.
Zyphr abstracts this provider logic. When a user logs into your mobile or web app, you register their device token once via the SDK. From that point on, you target the subscriberId, and Zyphr determines if it needs to talk to APNs or FCM.
await zyphr.push.send({
subscriberId: 'user_123',
title: 'Project Update',
body: 'Sarah just left a comment on your design.',
data: {
projectId: 'proj_abc',
type: 'comment',
clickAction: '/projects/proj_abc'
},
priority: 'high'
});
You can send a single payload, and we ensure it arrives on every registered device for that user. We also handle the "silent push" scenarios where you might need to sync data in the background without alerting the user. By centralizing this, you avoid the nightmare of maintaining two different notification logic branches in your backend. You can explore all multi-channel platform features to see how we handle topic-based subscriptions, device groups, and push delivery retries.
The platform also handles "token scrubbing" automatically. If FCM returns a "NotRegistered" error, Zyphr marks that token as invalid in our database so you don't keep attempting to send to dead devices. This keeps your delivery metrics clean and prevents you from being rate-limited by upstream providers.
In a traditional stack, if a user complains they didn't get a notification, the debugging process is a slog. You check the SendGrid logs for the email. Then you hop over to Twilio to see if the SMS was dropped by a carrier. Then you dig through Firebase to see if the push token was invalidated. This siloed approach is a massive time sink for support and engineering teams.
Zyphr replaces this with a unified delivery dashboard. Every message—regardless of channel—is logged in a single timeline associated with the subscriber. You can see the exact moment an email was delivered, when the SMS was received by the handset, and if the user actually clicked the push notification.
If you need to query this data programmatically—perhaps to show a delivery status in your own admin panel or a "message history" page for the user—it’s a simple API call.
const { data, error } = await zyphr.messages.getLogs({
subscriberId: 'user_123',
limit: 20
});
// Returns a unified array of email, sms, and push events
data.forEach(log => {
console.log(`${log.channel}: ${log.status} at ${log.createdAt}`);
});
Beyond simple observability, you can use Zyphr’s built-in webhooks to trigger application logic. When a user clicks a "Verify Email" link in a template, Zyphr can fire a webhook to your API with a signed HMAC-SHA256 payload. You can then mark that user as verified in your database without writing a single line of email-parsing code. This creates a functional feedback loop where the notification layer actively updates your application state.
The most powerful aspect of a unified multi-channel notification api is the ability to change delivery logic without redeploying your application. This is handled through "Workflows" in the Zyphr dashboard.
Imagine you want to change your "Welcome" flow. Instead of just sending an email, you want to:
In a hardcoded system, this requires a cron job, a state table in your database, and complex logic. In Zyphr, you define this logic in the dashboard. Your code remains a single line:
await zyphr.workflows.trigger('welcome-flow', { subscriberId: 'user_123' });
The infrastructure handles the state management, the timing, and the channel selection. If you decide next week that SMS is more effective than email for the follow-up, you change it in the dashboard. Your backend code doesn't change. This separation of concerns allows developers to focus on core product features while the communication strategy evolves independently.
As your application grows, the volume of notifications can become a bottleneck. Sending 10,000 emails in a single loop will timeout most serverless functions and potentially trigger rate limits on traditional APIs. Zyphr is built on a distributed queue system designed to handle massive bursts of traffic.
We handle the queuing, the rate-limiting of upstream providers, and the back-off logic. If a specific provider is experiencing downtime, Zyphr can automatically route messages through an alternative path or queue them until the service recovers. This level of resilience is difficult to build and maintain in-house.
Furthermore, we offer a Subscriber Preference Center API. Instead of you building a complex settings page with toggles for "Email" vs "SMS," your users can manage their own preferences via our hosted UI or a simple API call. If a user decides they want "Security Alerts" via SMS but "Marketing Updates" via Email only, Zyphr respects those rules automatically. You just call .send(), and the platform handles the filtering based on the user's stored preferences.
We’ve just implemented a complete multi-channel notification system that is easier to maintain and more reliable than a manual integration. By moving from a multi-vendor "spaghetti" architecture to a unified layer, you’ve eliminated multiple potential points of failure and simplified your billing into a single invoice.
The real value of this approach starts to show as your product evolves. You've future-proofed your communication stack. Whether you need to add WhatsApp support next month or migrate from FCM to another push provider, the work is already done at the SDK level.
Your next step is simple: log into your Zyphr dashboard, create a "Password Reset" template, and try to trigger it via the SDK. You'll likely have it running in under 5 minutes.
Stop gluing APIs together and start building your product. Sign up for the Zyphr Free tier and get your first 10,000 messages on us. If you're currently using multiple providers, check our pricing tiers to see how much overhead you can eliminate by consolidating today.