Skip to main content
Transactional emails in Brew

​
What are Transactional Emails?

Transactional emails are automated messages sent to individual users based on specific actions they take - like password resets, order confirmations, or account notifications. Unlike marketing emails, they contain essential information users need regardless of their subscription preferences. Key characteristics:
  • Triggered by user actions (not promotional campaigns)
  • Always delivered, even to unsubscribed contacts
  • Don’t require unsubscribe links (CAN-SPAM compliant)
  • Focus on functionality, not marketing
When contacts unsubscribe from your marketing emails, Brew automatically skips them for campaigns and automations but still delivers transactional emails since they contain essential information needed for using your service. This approach complies with CAN-SPAM regulations, which distinguish between marketing and transactional content.

​
When Should I Use Transactional Emails?

Essential for user account management:
  • Password reset emails
  • Email verification
  • Login notifications
  • Two-factor authentication codes
  • Security alerts
Always transactional - users need these to use your service.

​
Quick Decision Guide

Ask yourself: “Can the user complete essential tasks without this email?”
  • No → Transactional (password reset, order receipt)
  • Yes → Marketing email (newsletter, product updates)
Legal requirement: If your email contains ANY promotional content, it must follow marketing email regulations including unsubscribe links per CAN-SPAM, GDPR, and CASL.

​
How to Create and Send Transactional Emails

1

Create your email with AI

In the Create page, select the Transactional tab above the prompt box, then describe what you need. Brew generates an on-brand transactional email with proper variables and responsive design.
2

Edit your email

Refine your email using the chat or by clicking directly on any text, link, or image to edit it manually. After each manual edit, click Save - this saves a new version and ensures the AI takes your changes into consideration for future edits.
3

Add variables

Insert dynamic content like names, URLs, or order details using triple curly brace syntax: {{{variableName}}}.
4

Save or publish your email

Save the email in Brew so you can use its emailId in the public API flow.
5

Send via API

Use Brew Public API v1 to choose a verified domain and start a send.

​
Add Variables

Variables insert personalized content into each email. The syntax uses triple curly braces: Common variables:
  • {{{firstName}}} - Recipient’s name
  • {{{resetUrl}}} - Password reset link
  • {{{orderNumber}}} - Order confirmation
  • {{{verificationLink}}} - Account verification URL
Fallback values: You can provide a fallback value that renders if the variable is missing, using a pipe:
  • {{{firstName | there}}} - Renders “there” if firstName is not provided
Adding variables:
  1. Type them directly in the editor: {{{variableName}}}
  2. Add to text, links, buttons, or subject lines
  3. Brew’s AI will often insert variables automatically based on your prompt
Important requirements:
  • Variable names are case-sensitive (firstName ≠ FirstName)
  • Use only letters, numbers, underscores, and dashes
  • All required variables must be included in API calls
  • Values can be strings, numbers, or booleans

​
Publish and Send

  1. Review your email - Check variables and content
  2. Save or publish the email - You will use its emailId
  3. Choose a verified domain - Use a domainId from GET /v1/domains
  4. Start the send - Call POST /v1/sends

​
Common Issues

Error: Missing required fields: resetUrlFix: Include all required variables in your API call:
"variables": {
  "resetUrl": "https://example.com/reset",
  "firstName": "John"
}
Error: EMAIL_NOT_FOUNDCheck:
  • Is your emailId correct?
  • Is the saved email available in your org?
  • Hasn’t been deleted?
Error: Domain not verifiedFix: Verify your sending domain in Brew settings before sending emails

​
Best Practices

​
Content Guidelines

  • Be clear and direct - Users expect immediate, actionable information
  • Include your branding - Build trust with consistent design
  • Explain the trigger - “You’re receiving this because you requested a password reset”
  • Provide support contact - Never use “no-reply” addresses

​
Technical Best Practices

Use a dedicated subdomain for transactional emails:
  • notifications.yourdomain.com or auth.yourdomain.com
  • Isolates reputation from marketing emails
  • Signals purpose to email providers
Reputation isolation benefits:
  • Protects critical transactional emails if marketing campaigns face deliverability issues
  • Creates a “safety zone” for essential communications like password resets and account verifications
  • Allows faster recovery if problems occur with either transactional or marketing emails
  • Enables separate monitoring of deliverability metrics for each type of communication
Ensure proper authentication:
  • Verify domain in Brew settings
  • Set up DMARC for security
  • Match email URLs to your sending domain when possible
For sensitive emails (password resets, verification):
  • Keep content focused and minimal
  • Ensure immediate delivery expectations
  • Consider disabling click tracking for security
General best practices:
  • Limit email size (Gmail clips at 102KB)
  • Include plain text versions
  • Avoid excessive images
  • Use professional language

​
Monitoring

Track key metrics in your Transactional dashboard:
  • Sends - Total emails sent
  • Delivered - Successfully delivered emails
  • Bounces - Failed deliveries
  • Spam complaints - Recipients marking as spam
Consider disabling open and click tracking for sensitive transactional emails like password resets to improve deliverability. Tracking pixels and link wrapping can sometimes trigger spam filters for security-critical emails.

​
Public API Reference

​
Current Public v1 Flow

For the current public API, transactional-style sends use this flow:
  1. POST /v1/emails to generate a saved email.
  2. GET /v1/domains to choose a verified sender domain.
  3. POST /v1/sends to start delivery.

​
Authentication

The API accepts either of these authentication headers: 
X-API-Key: brew_YOUR_API_KEY

Authorization: Bearer brew_YOUR_API_KEY

​
Send Request Shape

ParameterTypeRequiredDescription
emailIdstringYesThe saved Brew email to send
domainIdstringYesA verified sending domain
subjectstringYesSubject line for the send
previewTextstringNoPreview text shown in inbox clients
replyTostringNoReply-to override
audienceIdstringNoSaved audience recipient mode
emailsstring arrayNoManual recipient mode
scheduledAtISO datetimeNoSchedule the send for later
Use exactly one recipient mode:
  • audienceId
  • emails

​
Example Send Request

curl -X POST "https://brew.new/api/v1/sends" \
  -H "Authorization: Bearer brew_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: send-001" \
  -d '{
    "emailId": "email_123",
    "domainId": "domain_123",
    "subject": "Reset your password",
    "emails": ["user@example.com"]
  }'
For the full current contract, use the API Introduction and generated Public API v1 endpoint pages in the API Reference tab.

​
Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you:

Search Documentation

Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.

ChatGPT/Claude Integration

Click “Open in ChatGPT” at the top right of any page to analyze documentation with ChatGPT or Claude for deeper insights.