This page is optional. You don't need to understand the architecture to use SendOps.


SendOps works by observing the events that Amazon SES already produces. It does not sit in the sending path for your application's own email — your application sends email exactly the way it does today, and SendOps captures what happens after. A few SendOps features go a step further and act on your SES account for you — sending Broadcasts and provisioning contact lists — always through your own SES, never through SendOps' mail servers.


  Your application sends email through AWS SES using the AWS SDK, exactly as before, and SendOps observes the resulting events. SendOps connects to your AWS account via a cross-account IAM role, listens for SES events through EventBridge, and presents everything in the dashboard. Where a feature like Broadcasts does send mail, it does so through your own SES account using the access you grant during setup.


## The event flow

Here is the end-to-end path of an email event, from your application to the SendOps dashboard:



### Step by step

1. **Your application sends an email** using the AWS SDK (SES v2 API, SMTP, or any supported method). Nothing changes here.

2. **SES processes the email** and generates lifecycle events — `Send`, `Delivery`, `Bounce`, `Complaint`, `Open`, `Click`, and more — based on what happens with the message.

3. **A Configuration Set** is attached to your sending calls (or set as the account-level default). In SendOps, each Channel maps to an SES Configuration Set. The configuration set publishes events to Amazon EventBridge.

4. **An EventBridge rule in your AWS account** matches those events and forwards them to the SendOps webhook endpoint at `api.sendops.dev`.

5. **SendOps ingests the event**, enriches it with metadata (domain, channel, template), and writes it to a high-performance analytics engine built for fast aggregation over large volumes of event data.

6. **The SendOps dashboard** at `app.sendops.dev` queries the analytics engine in real time to power dashboards, reports, message tracing, and alerting.

## Connecting your AWS account

SendOps uses **cross-account IAM role assumption** to interact with your AWS account. This is the same pattern AWS recommends for granting third-party access — no long-lived API keys are stored.

During setup, you can connect your AWS account using one of two methods:

- **Automated (CloudFormation)** — a one-click stack deployment that creates all required resources.
- **Manual** — step-by-step IAM role creation for organizations that require manual provisioning.

Either method creates:

| Resource | Purpose |
|---|---|
| **IAM Role** | A role in your account that SendOps assumes. Scoped to the specific SES actions SendOps needs — mostly read-only, plus the write actions required by features like Broadcasts (bulk send) and contact-list provisioning. |
| **EventBridge Rule** | Routes SES events from the configuration set to the SendOps webhook. |
| **Webhook Target** | The EventBridge API destination that delivers events to `api.sendops.dev`. |
| **SES Configuration Set** | Captures event types and publishes them to EventBridge. |


  The IAM role follows the principle of least privilege. SendOps only requests the permissions it needs — reading SES configuration, receiving events, and the specific write actions used by features you choose to use, such as sending Broadcasts and provisioning contact lists. It never sends your application's transactional mail on your behalf. See [IAM Permissions Explained](/aws-setup/iam-permissions) for the full policy breakdown.


### Why IAM roles instead of API keys?

- **No secrets to rotate.** There are no access keys stored in SendOps. The role is assumed on demand using AWS STS.
- **Revocable at any time.** Delete the CloudFormation stack and access is immediately revoked.
- **Auditable.** Every assumption is logged in AWS CloudTrail.

## Continuous AWS sync

Once connected, SendOps regularly syncs with your AWS SES account to discover new domains, email identities, and configuration sets. If something is added or removed in SES, SendOps detects it automatically and updates your dashboard. See [AWS Account Sync](/aws-setup/account-sync) for details.

## Templates

SendOps manages email templates through **GitHub integration**. Connect a GitHub repository, and SendOps syncs your templates automatically. Changes pushed to the repository are reflected in SendOps, keeping your templates version-controlled and aligned with your development workflow.

If you already have email templates in SES, SendOps can [export them as Git-ready files](/templates/importing-from-ses) so you can commit them to a repository and start managing them through SendOps right away.

## What SendOps stores

SendOps stores **SES event data** — delivery status, bounce details, complaint feedback, open/click tracking — in its analytics engine. It also stores metadata you configure in the dashboard: domains, channels, templates, team members, and notification rules.

SendOps does **not** store email content or message bodies. The events SES publishes contain headers, timestamps, and delivery metadata, but not the full message payload.

## Programmatic access

Everything the dashboard shows is also available through the [SendOps Public API](https://developers.sendops.dev) — a REST API at `api.sendops.dev` for messages, reports, suppressions, channels, templates, identities, and account state. Most resources are **read-only**, but you can also **write your contact roster** — create, update, delete, and bulk-import contacts, and manage their static-List membership — via the [Contacts API](https://developers.sendops.dev/api-reference/contacts), manage your [attribute definitions](https://developers.sendops.dev/api-reference/lists-segments#managing-attribute-definitions), and **create and send Broadcasts** programmatically. Authentication is via bearer API keys you create in your account settings. The API is server-to-server only (no browser-origin calls); where it does send — for example firing a Broadcast — the mail goes out through your own AWS SES account, never through SendOps' mail servers.

## Infrastructure at a glance

| Component | Technology | Role |
|---|---|---|
| Dashboard | `app.sendops.dev` | Web application — observability, templates, team management |
| API | `api.sendops.dev` | Receives webhook events, serves the dashboard |
| Analytics storage | SendOps Analytics Engine | High-speed event aggregation and querying |
| Event transport | Amazon EventBridge | Routes SES events from your account to SendOps |
| Auth to your AWS | IAM cross-account role | Secure, keyless access via STS |

## What's next?

Now that you understand how the pieces fit together:

- [Create your SendOps account](/getting-started/creating-your-account) to get started.
- [Connect your AWS account](/aws-setup/connecting-aws) to deploy the CloudFormation stack.
- [Learn about IAM permissions](/aws-setup/iam-permissions) to review exactly what access SendOps requests.