Regulated transactional mail
Reviewed August 2026. This is the public product thesis — not a dated roadmap and not legal advice.
Werkmail is for European practices and other regulated senders who need appointment, recall, and transactional mail to land, with evidence a DPO can read — plus a modest newsletter that cannot steal that reputation.
We are not trying to become Brevo, ActiveCampaign, or a generic send API with a prettier dashboard.
The moat (what we will keep sharpening)
The hard thing to copy is not another REST POST /emails. It is enforced behaviour in a European, vertical context:
| Primitive | Why it is a moat |
|---|---|
| One sending tenant per workspace | A neighbour’s complaints are not your problem |
outgoing ≠ broadcast |
Marketing cannot hitch a ride on Termin |
| Consent ledger | Wording, IP, time, channel — not a checkbox screenshot |
| Message kinds | termin / recall / doi change tracking, footers, and checks |
| Inbox-risk gate | The same hard block on GUI, batch, and API |
| Reputation pause | Bounce ≥5% / complaint ≥0.1% (min 20) can stop the tenant |
| Audit + DSAR | Who changed what; export and erase for a real request |
Those get more valuable as fines, patient sensitivity, and procurement questionnaires get stricter. Feature parity with a cheap sending API gets less valuable.
Who this is for
- Practices, clinic groups, and vendors who send Termin / Recall / DOI and maybe a newsletter
- EU operators who must show isolation and consent, not only “we have a DPA”
- Developers wiring a PVS or n8n flow who will accept a slightly stricter API in exchange for the same gate the GUI uses
Who should pick something else
- Pure transactional SaaS that wants SMTP, official SDKs, and PAYG cents — see EU transactional APIs, AhaSend, EUSend
- Marketers who live in pop-ups, SMS, and a visual automation canvas — see MailerLite, Brevo
- Teams that will staff their own mail platform — see raw outbound API
What we will build (in this order)
- Sharper regulated primitives — kinds, compliance checks, audit CSV, retention, legal-basis hints. Make the existing isolation louder in the product, not hide it.
- Developer experience that is good enough to leave small-practice-only — idempotency, scoped project tokens, OpenAPI, inbound send hooks, batch/bulk, stable error codes. Official SDKs only when they wrap the same gate, not a second send path.
- Volume plans that match the job — Termin (5k, transactional only), Praxis (20k, broadcast allowed, marketing pauses at cap), Gruppe (100k, custom caps). Transactional must keep moving when a newsletter hits the ceiling.
- Marketing automation that stays “good enough” — block editor, subject A/B, segments, linear journeys (Termin → Recall). No SMS, no chat, no 40-step visual canvas.
What we will not build
- Feature parity with generic outbound sending APIs (dedicated IP markets, partner SMTP resale, global regions)
- A marketing cloud: landing-page builders, ecommerce pop-ups, omnichannel
- Relaxing gates for “just this send” — that would dissolve the moat
Volume and DX (so we are not stuck at 200-message tenants)
Test (200) and Supporter (€5 / 1,000) exist so operators can evaluate the full product. They are not the destination for a clinic group.
| Plan | Cap | Broadcast | At 100% of cap |
|---|---|---|---|
| Test | 200 | yes | All sends pause |
| Supporter | 1,000 | yes | All sends pause |
| Termin | 5,000 | no | Transactional continues (broadcast already blocked) |
| Praxis | 20,000 | yes | Marketing pauses; transactional continues |
| Gruppe | 100,000 | yes | Marketing pauses; transactional continues; custom caps by agreement |
API path for volume: Send (single, batch 500, bulk), webhooks, inbound send hook. Idempotency-Key on writes. Project tokens (wm_proj_…) cannot administer the workspace.
Campaigns: good enough on purpose
See Campaigns and Journeys. If you need a full automation cloud, stay on that cloud and send Werkmail only for regulated transactional — or do not switch.
Start sending from https://werkmail.eu/login. Honest vendor notes: Compare.