# Werkmail vs a raw outbound API

Reviewed August 2026. Some teams skip an ESP and call a **cloud sending API** directly (any brand). That is the cheapest *transport*. It is not a product.

This page is for that choice. We describe **capabilities and region** (Frankfurt / **eu-central-1**), not infrastructure brand names.

## At a glance

| | Raw outbound API | Werkmail |
| --- | --- | --- |
| What you buy | Transport | Transport plus gates, consent, cockpit |
| Unit cost | Platform send price + your engineering | SaaS markup on top of transport |
| Isolation | You design tenants | One sending tenant per workspace |
| Suppression | Provider account lists are not enough | Own Postgres suppressions + pause |
| Rate / reputation | Account-wide caps are not a sole gate | Client limiter + bounce/complaint pause |
| Consent / DOI / Impressum | You write it | Productized |
| Operator UI | Console events | DNS wizard, inbox-risk, bounce reasons, BI CSV |

## They win

- **Unit cost at scale.** You pay the platform’s send price plus your engineering time — no SaaS markup.
- **Control.** Cloud credentials, event wiring, and IP strategy are yours.
- **Flexibility.** Any SDK, any region you configure, any custom MIME you accept the risk for.
- **No product opinions.** No Impressum gate, no kind enum, no pause — unless you build them.

## Werkmail wins

- **The work you would otherwise write.** Own Postgres suppression, client rate limits, reputation pause (bounce ≥5%, complaint ≥0.1%, min 20), content gate, List-Unsubscribe, legal footer, DOI, consent ledger, campaigns, journeys, cockpit.
- **Tenant isolation as a product.** Per-workspace sending profile — not one shared account for every customer.
- **Clinical vs marketing.** Provider account suppression and max-send-rate are **not** reliable sole gates. We learned that on a live sending API and productized the opposite.
- **Operator UI.** DNS wizard, inbox-risk dry-run, bounce reasons, BI CSV — not a console dump of events.
- **Same region, less assembly.** Sending still leaves from Frankfurt. You do not operate event queues and identity association by hand.

## Honest gaps on our side

- At millions of messages / month, raw transport plus an in-house platform can beat any ESP on price.
- If you already have a mature internal mail platform, Werkmail is a product — not a drop-in replacement for your access-control model.
- You cannot rename every line in View Source (platform DKIM / `Received` / `Feedback-ID`). We document that in [Raw source and branding](/raw-source-and-branding).

## Stay on a raw API if

You have staff to own events, suppression, consent, and abuse — and you want the lowest possible transport bill.

## Switch to Werkmail if

You want **Frankfurt sending** without staffing a mail platform: isolation, gates, practice kinds, and a cockpit your DPO can understand.

## If you migrate

Keep the same sending domain only after you understand warm-up and DNS ownership — two products signing the same domain will fight. Re-associate the **domain** identity with the Werkmail tenant (mailbox-only identities are not enough). Rebuild suppression and consent in Werkmail; do not treat the provider account list as the source of truth.

See also: [Compare hub](/compare) · [Concepts](/concepts) · [Deliverability](/deliverability)
