Email API for privacy-sensitive products — one boundary, scoped by domain
Products that handle health, finance, legal, or any other regulated category usually have a hard requirement: email data must live in infrastructure with a nameable boundary. Most hosted ESPs meet that requirement with contractual language; Flowmails meets it with an architecture you can read. One shared mail worker holds every tenant's mail, and every row is scoped by `domain_id`, so a query for one customer cannot return another's data. The provider connection is an OAuth grant with a bounded lifetime rather than a stored API token, and the dashboard never echoes a secret back. Compliance reviews can verify the boundary by reading the code, not by reading a vendor's privacy addendum.
What hurts today
The privacy-sensitive products pain points
Hosted ESPs are a data-processor relationship — they hold your mail
Sub-processor disclosures multiply when an ESP uses sub-processors
Data residency audits get harder the more third parties touch the data
How Flowmails answers
What you get instead
Mail, attachments and route tables are scoped by `domain_id` — one tenant's query cannot read another's rows
Provider access is a short-lived OAuth grant, not a long-lived API token in a database
The dashboard is write-only for secrets — it pushes a config and reads back non-secret status
FAQ
Common questions from privacy-sensitive products
Other personas