Transactional Emails

Transactional emails are messages triggered by a specific action or event – password resets, order confirmations, one-time passcodes, account notifications, and similar communications that your users expect to receive. Broadcast lets you send these through the same platform you use for marketing, so all your email activity lives in one place.

Transactional vs. Marketing Emails

Understanding the difference matters because the two types follow different rules:

Because transactional emails are service-related, they bypass the normal unsubscribe check. A subscriber who opted out of your newsletter will still receive their password reset email or purchase receipt.

Setting Up Transactional Emails

To send transactional emails, you need an Access Token with transactional permissions.

Access Tokens

When you create a new broadcast channel, an access token is automatically generated for it. You can view and manage your tokens at:

Settings > Access Tokens

The access tokens page shows each token’s:

• Name - A descriptive label you assign
• Masked token - The token value with most characters hidden for security
• Permissions - Which capabilities the token has (subscribers, broadcasts, transactional, etc.)

Make sure your token has the Transactional permission enabled. You can edit token permissions from this page if needed.

Important: Copy your token when it is first created or refreshed. For security, the full token value is only shown once.

Sending a Test Email

The quickest way to verify your setup is to use the built-in test tool:

1. Navigate to Transactional in the main menu
2. Find the Try it now card on the page
3. Enter a recipient email address, subject, and body content
4. Click Send

This card also displays a ready-to-use cURL command pre-filled with your API token and channel details. You can copy it and run it directly from your terminal to test the API integration.

Sending via API

To send a transactional email programmatically, make a POST request to the transactional endpoint:

curl -X POST "https://app.sendbroadcast.com/api/v1/transactionals.json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "transactional": {
      "to": "[email protected]",
      "subject": "Your password reset link",
      "body": "<p>Click the link below to reset your password.</p><p><a href=\"https://example.com/reset?token=abc123\">Reset Password</a></p>",
      "from_name": "Your App",
      "from_email": "[email protected]"
    }
  }'

The API responds with a JSON object containing the transactional email’s ID and status, which you can use to track delivery.

Required Fields

Optional Fields

Viewing Transactional Emails

Navigate to Transactional to see a list of all transactional emails sent from your account. The list view includes:

• Recipient email address
• Subject line
• Status indicator
• Sent at timestamp

Filtering

Use the filters at the top of the list to narrow results:

• Email - Search by recipient email address
• Status - Filter by delivery status

A live indicator shows when new transactional emails are being sent in real time, so you can monitor activity as it happens.

Detail View

Click on any transactional email to see its full details:

• Timeline - A step-by-step record of the email’s journey: when it was created, queued, sent, and any delivery events reported by your ESP
• Preview - A rendered view of the email content as the recipient saw it
• Metadata - Recipient, sender, subject, and other header information

Email Statuses

Each transactional email moves through the following statuses:

If you have ESP webhooks configured, additional delivery events (delivered, bounced, etc.) will appear in the email’s timeline as they are reported by your provider.

Resending Emails

If an email failed or you need to send it again, you can resend directly from the detail view:

1. Open the transactional email’s detail page
2. Click Resend
3. Confirm the action

This creates a new transactional email with the same content and sends it to the same recipient. The original email’s record is preserved, so you have a complete audit trail.

Unsubscribe Behavior

Transactional emails follow different delivery rules than marketing emails:

• Unsubscribed subscribers still receive transactional emails. If someone opted out of your newsletter, they will still get their password reset or order receipt.
• Redacted subscribers do not receive transactional emails. If a subscriber has been redacted (their data removed for privacy compliance), the email cannot be delivered because the address is no longer stored.
• Global suppression list entries block all email, including transactional. If an email address is on the suppression list (due to hard bounces or spam complaints), transactional emails to that address are also blocked to protect your sender reputation.

This design ensures that important service emails reach your users while still respecting hard delivery boundaries that exist for technical or legal reasons.

API Reference

The transactional endpoint supports creating and listing transactional emails. For the complete API reference including response formats, pagination, error codes, and advanced options, see the API documentation.

Key endpoints:

• POST /api/v1/transactionals.json - Send a transactional email
• GET /api/v1/transactionals.json - List transactional emails
• GET /api/v1/transactionals/:id.json - Get a specific transactional email

Best Practices

1. Use a dedicated sender address - Send transactional emails from an address like [email protected] or [email protected] to distinguish them from marketing emails in your subscribers’ inboxes
2. Keep content focused - Transactional emails should contain only the information the user needs. Do not include promotional content, as this can cause spam filters to treat them as marketing emails
3. Send immediately - Transactional emails are time-sensitive. Password resets and OTPs lose value after a few minutes. Make your API call as soon as the triggering event occurs
4. Monitor failures - Check the Transactional list regularly for failed sends. A pattern of failures may indicate an email server misconfiguration or a problem with your sending domain
5. Set up ESP webhooks - Webhook integration gives you delivery confirmation and bounce data for transactional emails, not just marketing campaigns
6. Test before going live - Use the Try it now card or a cURL command to send test emails during development. Verify that your subject, body, and sender information look correct before integrating into your application
7. Handle API errors gracefully - Your application should check the API response status and retry or alert on failures. Do not assume every send succeeds on the first attempt

Want to manage transactional emails alongside your marketing campaigns? Learn about Creating Your First Broadcast to get started with email campaigns.