Course B · Module B1 Production · Lesson 7 of 18

Send Emails

Make your app send the right email at the right moment, on its own — without you lifting a finger.

~12 min · Have your app open · Prereq: B5 API Keys & Secrets

Every production app sends emails: a receipt after purchase, a password-reset link, a notification when something important happens. Done manually, these eat hours. Done wrong, they land in spam. Done right, they run invisibly in the background and make your product feel polished. Your single win: by the end you'll know the difference between the two kinds of email, understand why Gmail won't cut it, and be ready to wire an email API into your app in an afternoon.

Transactional vs marketing email — two completely different jobs

Transactional email

Triggered by something the user did. Order confirmation, password reset, welcome on sign-up, payment receipt, "your file is ready" notification. The user expects it immediately. This is what you build with an email API.

Marketing email

You decide when it goes out — newsletters, promotions, drip sequences. The user may or may not want it. Requires an unsubscribe link by law in most countries. Use a dedicated tool (Mailchimp, Kit, Loops) — not the same API.

Mixing them up creates legal and deliverability problems. Keep them separate: email API for triggered messages your app sends, dedicated marketing tool for broadcasts you send.

Why you can't just send from Gmail

Imagine you wanted to ship 500 packages a day. You could carry them in your car — technically possible, totally impractical, and the post office would flag you pretty fast. Gmail is your car. An email API is a courier company with a loading dock, a delivery guarantee, and a tracking number for every package.

The technical reality behind the analogy comes down to three things:

DeliverabilityGmail accounts sending app-generated email get throttled or blacklisted. Dedicated providers have pre-warmed IP addresses with established reputations — your emails reach inboxes instead of spam.

Sending domainEmails should come from noreply@yourbusiness.com, not a personal Gmail. Email APIs let you send from your own domain once you verify it.

SPF & DKIMTwo short DNS records you add to your domain. They tell receiving mail servers "yes, this provider is allowed to send on my behalf" — cutting spam-folder risk dramatically. Your email provider gives you the exact records to copy-paste.

Pick a provider and connect it like any other API key

Three providers are dominant for transactional email. All three have a free tier good enough to start with:

ResendCleanest developer experience, built for modern frameworks (React email templates), generous free tier. Best starting point for new apps.

PostmarkBest deliverability reputation, strong analytics, slightly higher price. Good when email reliability is critical (receipts, legal notices).

SendGridOlder, full-featured, handles transactional and marketing. Steeper learning curve but massive ecosystem.

The integration pattern is the same as any API (B5): you get an API key from the provider's dashboard, store it in your environment variables (never hardcoded), and call the provider's library with the recipient, subject, and body. Your AI assistant can generate the full sending function from the provider's quickstart — just paste the URL and ask.

Templates: write once, reuse everywhere. Most email providers let you create reusable templates — design the receipt email once, then your code just fills in the blanks ({{order_id}}, {{amount}}) at send time. Your AI can generate both the template HTML and the code that fills it in. This is far cleaner than building email HTML inside your application code.

The event-to-email pattern

Every transactional email follows the same shape: something happens in your app → your code calls the email API → user gets an email. The "something happens" is the trigger you learned about in Course A automations — a new user signs up, a payment succeeds, a file finishes processing. Map these out before you build:

List your triggers. What events in your app should send an email? (Sign-up, purchase, password reset are the must-haves.)
Write the email first. What should it say? Keep it short, clear, and actionable.
Build the template in your email provider's dashboard.
Add the API call to your app at the trigger point, passing in the user's address and any dynamic values.
Test with a real address before going live — check both inbox and spam, on desktop and mobile.

Check yourself

Answer before opening — recalling it is what makes it stick.

A user hits "forgot password" and your app sends a reset link. Transactional or marketing email?

Transactional. It was triggered by the user's action, expected immediately, and contains information they specifically requested. Build it with an email API like Resend or Postmark — not your marketing tool.

Your app sends from your Gmail and the emails keep landing in spam. What's the root cause?

Gmail wasn't built for app-generated bulk sending. It lacks a warmed sending reputation for this use, and you're missing the SPF and DKIM DNS records that tell receiving servers your email is legitimate. Switch to a dedicated email API and verify your domain.

What is an email template and why does it make your code cleaner?

A template is pre-written email HTML with placeholders for dynamic values like names or order numbers. Your code just fills in the blanks at send time instead of building email HTML inline. This separates the email's design from your app logic and makes both easier to update.