For Developers
You chose SES for a reason. SendOps makes sure you don't regret it.
SES gives you the cheapest, most reliable email delivery on the market. But everything around it — observability, template management, infrastructure provisioning — is either missing, locked behind CloudWatch, or something you built yourself at 2am. And it has no audience layer at all: no lists, no segments, no campaigns. SendOps adds the operational layer and the marketing layer without changing how you send email.
Everything you'd build yourself, already built
You've probably already written some of this: a script that deploys templates, a Lambda that processes bounce events, a Slack bot that alerts on complaint spikes. It works, mostly — until someone else needs to maintain it, or you need it to do something it wasn't designed for.
SendOps replaces the homegrown plumbing. Observability, templates, alerting, infrastructure management — all built specifically for SES, all accessible through a dashboard your whole team can use, and none of it requires changing a single line in your application.
Your code stays the same
Zero changes to your sending path
Your application sends via SES the same way it does today. Same API calls, same SMTP, same SDK. SendOps never sits between your app and SES.
No SDK to install. SendOps connects to SES via EventBridge and CloudFormation — not through your application code.
No new endpoints to call. Your sending code is untouched. SendOps reads events that SES is already producing.
No vendor lock-in. Remove the CloudFormation stack and SendOps disconnects cleanly. Your SES setup keeps running.
What you get
The operational layer SES is missing
Observability without CloudWatch
Real-time delivery metrics, bounce rates, complaint rates — across every domain and configuration set. Search any email by recipient, message ID, or status. See the full event timeline for every message. No CloudWatch dashboards to build, no Athena queries to write.
→ Learn moreGit-based template management
Templates live in your repository. Edit in your IDE, open a pull request, get automatic validation and rendered previews. Merge to main and SendOps deploys to SES. No console edits, no deployment scripts, no aws ses update-template commands.
Infrastructure provisioned by CloudFormation
One CloudFormation template sets up everything: domain identities, configuration sets, tracking domains, EventBridge rules, IAM roles. Review it like any other infrastructure change. Deploy it the same way you deploy everything else.
→ Learn moreAlerting that reaches your tools
Bounce rate crosses 5%? Complaint rate spikes? Sending quota running low? Alerts go to Slack, email, or webhooks. Trigger PagerDuty or OpsGenie via webhook payloads. No CloudWatch alarms to configure.
→ Learn moreEverything as code
Not just templates. Lists, segments (SendQL), topics, and drip workflows (SendFlow) are files in your repo — React Email TSX and plain-text definitions. Pull requests, reviews, CI, the works. Edits made in the app come back to you as PRs, so the repo stays the source of truth.
→ Learn moreAn API for the rest
Contacts, broadcasts, assets, and undeliverable data are all available over API v1. Push your product's events through the activity ingestion API to drive segments and workflows. Anything you'd rather script than click is scriptable.
→ Learn moreA day with SendOps
How it fits into your workflow
Scenario: Updating a transactional template — and the workflow that follows it
Edit the template in your IDE.
Open emails/order-confirmation.tsx in VS Code. It's a React Email component — update the shipping section copy. Commit to a feature branch.
Tweak the post-purchase workflow in the same branch.
Wholesale orders shouldn't get the review-request follow-up. That's one condition in workflows/post-purchase.flow — a SendFlow file in the same repo. Same branch, same commit history.
Open a pull request.
SendOps validates both changes automatically — template syntax, variable verification, rendered preview, and the workflow change checked against the SendFlow schema. Reviewers see exactly what will change.
Merge and deploy.
PR merges to main. SendOps syncs the updated template and workflow within 30 seconds. No scripts, no manual steps.
Monitor the rollout.
Open the SendOps dashboard. See delivery rates for the updated template in real time. Filter by the transactional channel to isolate it from other email types.
Something looks off? You'll know.
Bounce rate ticks up? SendOps alerts your Slack channel. Click through to the message search, find the bounced emails, see the full event timeline. Roll back with a Git revert if needed.
Agents
Your coding agent can own lifecycle email
Because templates, segments, and workflows are plain text — TSX, SendQL, SendFlow — in your repository, they're already in the format coding agents work in. Ask Claude Code or Cursor to add an abandoned-cart step, adjust a segment, or restyle a template, and it edits files on a branch like any other change.
The guardrails are the ones you already trust: the agent opens a pull request, SendOps validates the changes, and a human merges. Nothing reaches your subscribers because an agent decided it should.
Configuration
Git integration works without any config file.
Connect your repository and SendOps picks up your templates automatically — no config file needed. It detects your React Email components, validates them on every push, and compiles them to SES-native Handlebars on merge.
If you want to go further, add a sendops.json to your repo root. It's purely optional metadata — use it to give templates logical names, link them to test data files in your repo, or both. Test data can also be added directly in the dashboard without touching the repo.
path
Repo-relative path to the template component. Use this to give a template a logical name that's independent of its filename or location in the repo.
testdata
A directory of JSON files (trailing /) or a single JSON file. Each file becomes a test data profile — used for rendered previews in pull requests, test sends, and variable validation. Profiles can also be created in the dashboard if you'd rather keep test data out of the repo.
{
"templates": {
"welcome": {
"path": "emails/welcome.tsx",
"testdata": "fixtures/emails/welcome/"
},
"order-confirmation": {
"path": "emails/order-confirmation.tsx",
"testdata": "fixtures/emails/order-confirmation.json"
},
"password-reset": {
"path": "emails/password-reset.tsx"
}
}
}{
"name": "Alice Chen",
"company": "Acme Corp",
"action_url": "https://app.acme.com/onboard"
}Common questions from developers
Does SendOps see my email content?
The email your application sends never passes through SendOps — we process SES event metadata: delivery timestamps, bounce notifications, engagement signals. What SendOps stores is what you put in it — templates, contacts, lists, assets — scoped to your organization, exportable, and deleted with your account.
What permissions does SendOps need?
The CloudFormation template creates least-privilege IAM roles scoped to SES event reading, configuration set management, and template operations. No broad admin access. The template is reviewable before deployment.
What happens if I remove SendOps?
Delete the CloudFormation stack. Your SES account, domains, configuration sets, and sending reputation remain untouched. SendOps disconnects cleanly — it's additive, not a dependency.
Does it affect my sending latency?
No. SendOps never sits in the delivery path. Your application sends to SES directly. SendOps reads events asynchronously via EventBridge after delivery.
Can I use it with multiple AWS regions?
Yes. SendOps supports multi-region SES deployments.
Can our coding agents use SendOps?
Yes. Everything material — templates (TSX), segments (SendQL), workflows (SendFlow) — is plain text in your repo, and the rest is covered by the public API. An agent's changes go through the same PR validation as any engineer's: rendered previews, syntax and variable checks, human review before merge.
Keep SES. Lose the plumbing.
Free plan available. Two-minute setup. No SDK, no code changes.