"What should we use for email" is usually two separate questions bundled together: how do we send transactional/marketing mail reliably at scale, and how do we process, route and act on mail our business receives and generates internally. Metered SaaS sending APIs (SendGrid, Postmark, Mailgun and similar) are built for the first question and are usually the right answer to it — deliverability infrastructure at scale is genuinely hard to replicate yourself.
The second question — routing support mail, tagging it, blocking things for review, connecting mail events into your own product or CRM — is a different job, and one where a self-hosted, programmable mail gateway is often a better fit than trying to bolt automation onto a sending API that was never designed for it.
A per-message or per-API-call pricing model makes sense when usage is small and unpredictable. It becomes a real line item once a product depends on frequent internal API calls (checking mailbox state, polling for stats, pulling logs) rather than occasional message sends — that usage pattern was not what metered pricing was designed around, and it is where a flat, one-time licence with unmetered API access changes the calculation.
Self-hosting also removes a third party from the data path for anything with confidentiality or GDPR sensitivity — relevant if the mail you are processing is customer support content, not just marketing sends, since that is usually more sensitive data than a promotional email.
A startup or SME with a handful of engineers rarely wants to build a mail processing platform from scratch. The pattern that works is: install the gateway once, configure rules through the admin console for the stable parts of the workflow, and use the API/webhooks only for the parts that genuinely need to talk to your own systems. Concretely:
- Support triage — tag and route by category/language using the Router module (tagging guide, language routing guide), then push into your CRM via webhook.
- Sensitive outbound review — hold specific outgoing mail for approval using the Blocker module (review workflow guide) without building a bespoke approval system.
- Operational visibility — feed queue and quarantine stats into your existing monitoring instead of a separate mail-specific dashboard (stats/logs guide).
- Event-driven glue — connect any of the above into your own product using webhooks plus the REST API rather than polling or scraping mailboxes (event-driven workflows guide).
Being balanced about this: if the actual requirement is "send millions of transactional or marketing emails per month with best-in-class deliverability engineering behind it," a dedicated sending API is doing genuinely hard, ongoing work (IP reputation management across thousands of customers, feedback-loop relationships with mailbox providers, deliverability specialists) that a small team running their own SMTP infrastructure will not casually replicate. Self-hosting outbound at volume also puts you back on the hook for everything in the email deliverability guide — which is a real, ongoing job, not a one-time setup task.
A sensible split many startups land on: keep a metered sending API for high-volume transactional/marketing mail, and use a self-hosted, programmable gateway for the mail the business receives and processes internally, where API/webhook access is used constantly rather than occasionally.
Hexamail Nexus and Hexamail Guard combine the Router, Blocker, Reports and Developer modules on a single perpetual, unmetered licence — REST API and webhook access included, with no per-call charge to plan around as your integration grows. This fits the "process and act on the mail our business receives" half of the problem well; for high-volume outbound sending with deliverability engineering behind it, pair it with a dedicated sending provider rather than replacing that half entirely.