Werkmail vs EUSend

Reviewed August 2026. EUSend is a developer-first, EU-native transactional API: own mail transfer agent in Falkenstein, React Email in the SDK, scoped send keys. Werkmail is an operator platform: same gate on GUI and API, consent evidence, stream split, and practice kinds.

At a glance

	EUSend	Werkmail
Primary job	Thin EU transactional API	Regulated transactional + modest broadcast
Sovereignty story	Own MTA on European hardware; mail data not on a US cloud	Frankfurt / eu-central-1 sending and data; isolation per tenant
DX	Official SDKs, React Email rendered client-side	HTTP JSON, curl, OpenAPI, inbound send hook
Tracking	Org default; opens/clicks in the dashboard	Off by default for `termin` / `recall` / `doi`
Broadcast	List-Unsubscribe on bulk	Separate `broadcast` route, DOI, Impressum
Healthcare	Generic templates	First-class kinds + compliance check
Volume	Developer signup; verify current pricing on their site	Test → Supporter → Termin / Praxis / Gruppe

They win

Sovereignty narrative. They run their own MTA and say recipient data and message content stay on European machines they administer — not an “EU region” of a US cloud. That is a real architectural claim; judge it against their subprocessors page, not ours.
Time to first send for a Node/Python app. SDKs, React Email (JSX never sent over the wire), test keys that accept but do not deliver.
Scoped send keys pinable to a domain. Fine-grained “this key can only send.”
Focus. They do not pretend to be a practice cockpit or a marketing suite.

Werkmail wins

Productized compliance, not residency as the whole story. DOI ledger, channel prefs, DSAR, Impressum, List-Unsubscribe on every send including transactional.
Stream purity and practice kinds. Appointment mail cannot share a marketing pool. termin / recall / doi carry tracking and footer rules.
Operator cockpit. DNS wizard, inbox-risk hard block, bounce-reason rollup, content-score history, audit CSV.
GUI and API on one gate. A receptionist and an n8n workflow hit the same content and consent rules.

Honest gaps on our side

We do not operate a self-hosted MTA as the public product story; we send from Frankfurt and document what View Source still shows (raw source).
No React Email runtime and no official SDK packages.
If CLOUD Act exposure of the underlying cloud is your only purchase criterion, their architecture may fit better — do your own legal review.

Stay on EUSend if

You want a thin EU send API, you will keep consent and marketing elsewhere, and React Email / official SDKs are how your team ships.

Switch to Werkmail if

You need one system a clinic or DPO can audit: kinds, consent evidence, isolated tenants, and a newsletter that cannot ride appointment reputation.

If you migrate

Keep rendering HTML in your app. Swap the transport to Werkmail send (message_kind, route). Rework webhooks to Werkmail signatures. Re-verify the domain identity on the new tenant. Import suppressions; do not assume their list is yours.