Broadcasts
Send campaigns through your own SES
Pick an audience — a list or a live segment — pick a template, and send. Consent filtering, test sends, and per-campaign results are built in. Every broadcast goes out through your own SES account: your domains, your reputation, Amazon's delivery rates.
The problem
SES lets you send bulk email. It doesn't give you a campaign.
SES has SendBulkEmail and not much else. There's no audience selection — you bring your own list of addresses. There's no consent handling — suppressions, unsubscribes, and topic preferences are your problem. There's no results view — you get a message ID per recipient and good luck.
So teams do one of two things. They script it — a cron job, a CSV, a for-loop over batches of fifty — and pray nothing on the do-not-mail list slips through. Or they give up and pay an ESP that charges per email and per contact, for infrastructure they already have.
SendOps is the third option: the campaign layer on top of the SES account you already own. SES stays at $0.10 per 1,000 emails. Your contacts stay free.
How it works
From audience to results in six steps
A broadcast is a one-time send: one template, one audience, one moment. Everything between "send" and "sent" is handled.
Choose your audience
Pick a List for a fixed set of contacts, or a Segment that evaluates live against contact attributes. Segments resolve at the moment the send fires — not when you schedule it — so you always mail who matches now.
Bind a template
The broadcast pins a specific template version. Variables resolve from each contact's attributes, and a coverage preview shows exactly which contacts are missing data for each variable — before you send, not after.
Consent filter applies automatically
Suppressed and unsubscribed contacts are dropped from every send. If the broadcast has a topic, contacts who opted out of that topic are dropped too. You never have to clean the list yourself.
Test send to yourself
Send the real rendered email to addresses you choose, through the same pipeline as the production send. Check it in an actual inbox. Test sends never touch your broadcast's results.
Send through your SES
The broadcast fans out through your own SES account, batched and paced within your sending quotas. Your domains, your reputation, Amazon's delivery rates — never shared infrastructure.
See the results
Deliveries, bounces, opens, and clicks per broadcast, plus a per-recipient outcome for every contact in the audience — including who was filtered out and why.
Consent & unsubscribe
Unsubscribe handling you don't have to build
Consent is the part of bulk email that gets teams in trouble. SendOps enforces it on every broadcast, automatically: suppressed and unsubscribed contacts never receive a send, and topic opt-outs are honored before a single email leaves your account.
Assign each broadcast a topic — newsletter, product updates, promotions — and recipients manage their preferences per topic instead of a single all-or-nothing switch.
Topics with per-topic consent — a recipient can leave your newsletter and keep getting product updates
RFC-compliant one-click List-Unsubscribe headers with signed, per-recipient tokens
A custom unsubscribe page on your branding — not a generic third-party form
Opt-outs enforced automatically on every future send
Confidence
Know what you're sending before you send it
Bulk email is unforgiving — there's no unsend. So the checks happen up front, and the record afterwards is complete.
Audience coverage preview
Before you send, see how each template variable resolves across the audience: which contacts have the attribute, which fall back to a default, and which would render blank. No surprises in the inbox.
Test sends
Send the real email — real template, real merge data, real headers — to yourself or your team before committing. Test sends go through the production path but never count toward results.
Paced within your SES quotas
Sends are batched and paced to stay inside your SES rate limits. A big broadcast doesn't starve your transactional email or trip your account's throttles.
Per-broadcast results & reconciliation
Every recipient gets a recorded outcome: sent, failed, or filtered — and why. If the audience was 10,000 and 9,400 got the email, you can see exactly where the other 600 went.
API
Broadcasts from code
Everything the dashboard does, the REST API does. Create a broadcast by referencing a template by its slug and a topic by name — or supply the content inline — set the subject and audience, and fire it. A dedicated test-send endpoint delivers the rendered email to addresses you specify, so a human can check the real thing before the real thing goes out.
Composing and sending are separate permissions. Your release pipeline can draft the changelog broadcast on every deploy, and a person presses send — or the other way around.
One send path, three kinds of sender
The same broadcast pipeline works whether it's driven from the dashboard, the API, or a deploy script.
For Marketers
Pick an audience, pick a template, preview the coverage, send. No engineering ticket, no CSV exports, no AWS console. The consent filter and unsubscribe handling are already done.
For Developers
Create and fire broadcasts from CI or your own app via the API. Sending is a separate permission from composing, so you control exactly who — or what — can pull the trigger.
For Founders
Ship a product-update blast to every customer without renting Mailchimp. It sends from your own domain, through your own SES, at SES prices — no per-contact fee for people you already have.
Send your next campaign from your own infrastructure
Free plan available. Connects to your SES account in two minutes.