DEV Community

Cover image for Does Notify Replace SMTP Providers and Webhook Plumbing for Transactional Email?
sohom das
sohom das

Posted on

Does Notify Replace SMTP Providers and Webhook Plumbing for Transactional Email?

Short answer: yes, mostly — and that's honestly the reason I ended up using it for a side project that needed password resets and a couple of account notifications. I didn't want to spend an afternoon wiring up SMTP credentials and building a webhook receiver just to send a handful of emails a day.

What I Used to Have to Deal With

Before I found a lighter option, "add transactional email" meant a few hours I didn't love spending: get SMTP credentials from a provider, figure out where they go in whatever mailer library the framework uses, set up SPF/DKIM records and wait for DNS to propagate, and — if I actually wanted to know when something bounced — build a small worker to receive and parse webhook events myself. None of it was hard exactly, it was just a pile of setup that had nothing to do with the actual feature I was building.

What Notify Actually Replaces

SMTP credentials and server config

There's no SMTP host, port, or credential pair to manage. Notify is a plain HTTP API — you send a POST request with an API key in the header, and that's the entire "mail server" relationship:

curl -X POST https://notify.cx/api/email/send \
  -H "Content-Type: application/json" \
  -H "x-api-key: $NOTIFY_API_KEY" \
  -d '{
    "to": "user@example.com",
    "from": "noreply@your-verified-domain.com",
    "subject": "Reset your password",
    "message": "<p>Click below to reset your password.</p>"
  }'
Enter fullscreen mode Exit fullscreen mode

Domain verification is still DNS records you add once (SPF, DKIM, DMARC), but that's true of literally any provider — there's no way around proving you own the domain. What's gone is the mail server itself, IP reputation management, and retry/queue logic, since that all sits on Notify's side.

The webhook pipeline you'd otherwise build yourself

This was the part I actually didn't want to build again. Instead of standing up an endpoint to receive raw delivery events and writing logic to parse and act on them, Notify's webhooks are just a registration call:

curl -X POST https://notify.cx/api/webhooks \
  -H "Content-Type: application/json" \
  -H "x-api-key: $NOTIFY_API_KEY" \
  -d '{
    "webhookUrl": "https://yourapp.com/webhooks/email",
    "subscribedEvents": ["Delivery", "Bounce"],
    "domainId": "your-domain-id"
  }'
Enter fullscreen mode Exit fullscreen mode

I still have to write the endpoint that receives the callback, obviously — but the event pipeline (detecting a bounce, formatting it, delivering it reliably) isn't something I built. If you want to see the full shape of the request and response before wiring anything up, the docs walk through it in a few minutes — that's genuinely most of what there is to learn.

What It Doesn't Replace

To be straightforward about the limits, since I don't think "it replaces everything" is an honest answer:

  • When to send something is still your logic. Notify sends the email you tell it to; deciding that a password was just reset and a notification should go out is still application code.
  • Content and templates are still on you. Notify is bring-your-own-HTML — there's no visual template builder. For something like a password reset email that I write once and barely touch again, that's never actually bothered me, but if you want a WYSIWYG editor or non-engineers editing copy, that's not what this is.
  • Broader tracking/audit beyond delivery events isn't built in. You get logs and webhook events for what happened to a send; you don't get a CRM-style activity timeline.
  • It's email only. If you need SMS, push, or chat alongside email from one system, that's a different category of tool (multi-channel notification platforms), not this.

Self-Hosted SMTP vs. Notify vs. the Bigger Providers

Self-managed SMTP Notify SendGrid / Mailgun / Postmark
Server & credentials to manage Yes — mail server, IP reputation, retries No — single HTTP API call No — HTTP API call
Webhook/event pipeline Build it yourself Built in — subscribe an endpoint Built in — subscribe an endpoint
Domain verification Manual DNS + reputation warm-up Guided DNS records Guided DNS records
Template/content tooling N/A Bring your own HTML Usually includes a template builder
Cost to start Infrastructure + ops time Free up to 1,000/mo, then $10/mo $0–20/mo depending on provider

Was It Worth Switching?

For what I needed — a handful of transactional emails triggered by user actions, with enough visibility to know if one failed — yes. The free tier covered everything I needed to test the whole flow, webhooks included once I moved to the paid plan, before I'd spent any money deciding it was worth it. If your use case genuinely needs a lot more — visual templates, marketing sends, multi-channel delivery — this isn't that tool, and it's not trying to be.

Frequently Asked Questions

What is Notify?

Notify is a lightweight transactional email API for developers — one endpoint to send email, plus domain verification, delivery logs, and webhooks, instead of managing SMTP infrastructure directly.

Does Notify replace the need for SMTP credentials?

Yes. You send email through Notify's HTTP API using an API key, not SMTP host/port/credential configuration.

Does Notify handle bounce and delivery event webhooks for me?

It provides the event pipeline — you register a webhook URL and subscribe to events like Delivery and Bounce, and Notify handles detecting and delivering those events. You still write the endpoint that receives them.

Does Notify include email templates?

No — Notify is bring-your-own-HTML. There's no visual template builder, which for most transactional emails (password resets, notifications) that rarely change isn't usually a real limitation.

Can Notify send SMS or push notifications too?

No, Notify is email-only. For unified multi-channel notifications (email, SMS, push, in-app), you'd want a different category of tool.

Top comments (0)