How Does Notify Work for Sending Transactional Email from an Application?

Here's the actual flow, step by step, the way I've wired it into a couple of projects now. Notify is an API your backend calls to send a single email — that's the whole mental model, and it's worth walking through exactly what happens at each step, because Notify works a little differently than some of the templated notification services people assume it works like.

1. Your App Triggers an Event

Something happens in your application — a user signs up, a password reset is requested, an order is placed, a payment succeeds. Your backend decides an email needs to go out. This part is entirely your application logic; Notify has no opinion about it and isn't involved yet.

2. Your App Calls Notify's API — With the Content Already Built

This is the step where Notify actually differs from what people sometimes expect. There's no template ID to reference and no separate "personalization data" object that Notify fills in on its side — you build the final subject line and HTML yourself, in your own code, and send the whole thing in one request:

curl -X POST https://notify.cx/api/email/send \
  -H "Content-Type: application/json" \
  -H "x-api-key: $NOTIFY_API_KEY" \
  -d '{
    "to": "[e-mail]",
    "from": "[e-mail]",
    "subject": "Reset your password",
    "message": "<p>Hi Alex, click below to reset your password. This link expires in 1 hour.</p><p><a href=\"https://yourapp.com/reset?token=abc123\">Reset password</a></p>"
  }'

Notice "Alex" and the reset link are already interpolated into the HTML above — that happened in my app code before this request went out, not inside Notify. If you're used to a service where you pass a template ID plus a data object and the provider renders it, this is the one part of Notify's model worth adjusting your mental picture for: it's intentionally bring-your-own-HTML, with no template rendering step. For something like a password reset email that I write once and rarely touch, that's genuinely simpler in practice — one less system to learn — but if your team wants non-engineers editing copy through a visual builder, that's not what Notify does.

3. Notify Delivers the Email

Once the request lands, Notify takes over the actual delivery — queuing the message and attempting delivery through its own sending infrastructure, so your app isn't the thing responsible for IP reputation, DNS-level authentication, or talking to receiving mail servers directly. That's the part that used to be the tedious half of building this myself.

4. Your App Tracks What Happened

Notify keeps delivery logs you can check directly, and if you want your app to react automatically instead of checking a dashboard, webhooks let you subscribe to events like Delivery, Bounce, Open, and Click:

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"
  }'

That's what turns "did the email actually go out" from a support ticket into something your app already knows. If you want the full event list and payload shape before setting this up, the docs lay it out in a few minutes.

Why This Shape Works for Transactional Email

A few things fall out of Notify working this way:

• Security — your app authenticates with an API key from the backend; there's no SMTP credential sitting in client-side code or a config file that could leak.
• Observability — logs and webhooks mean you find out about delivery problems from Notify, not from a user.
• Separation of concerns — your app owns the business logic (when to send, what it says); Notify owns getting it delivered.
• No hidden rendering step — since there's no template engine in the middle, what you send is exactly what gets sent. Easier to debug, since there's one less system that could be the reason an email looks wrong.

What the Full Architecture Looks Like

1. User action happens in your app (signup, password reset request, order placed)
2. Your backend builds the final HTML and calls Notify's API
3. Notify verifies the sending domain is authenticated and delivers the message
4. The user receives the email
5. Your app checks logs or receives a webhook event, and reacts if something failed

Where This Fits

The same flow covers most single-recipient, triggered emails: account verification, password resets, two-factor codes, receipts, shipping notifications, security alerts. What it's not built for is anything sent to a list, or anything where you want the email's content decided by something other than your own application code.

I've found the free tier is enough to build and test this entire flow — signup through webhook handling — before paying anything, which made it an easy first piece of infrastructure to wire up on a new project.

Frequently Asked Questions

What is Notify?

Notify is a lightweight transactional email API for developers — your app sends a single HTTP request with the fully-built email content, and Notify handles delivery, domain verification, logs, and webhooks.

Does Notify render email templates for me?

No. Notify doesn't have a template engine or template IDs — you build the final HTML in your own application code and send it as-is. This is a deliberate difference from notification services that do server-side template rendering.

How does my app know if a Notify email failed to send?

Through delivery logs you can check directly, or webhooks subscribed to events like Bounce and Delivery, so your app finds out automatically instead of relying on a user to report it.

Is Notify secure for handling things like password resets?

Authentication happens via an API key sent from your backend, so SMTP credentials or provider secrets are never exposed in client-side code. The email content itself (like a reset link) is whatever you put in the request — Notify doesn't add anything to it.

What kinds of emails is Notify meant for?

Single-recipient, backend-triggered transactional email — password resets, account verification, receipts, shipping updates, security alerts. It's not built for marketing sends or list-based email.