The wedge
Most products glue an email provider per use case — Stripe for invoices, SendGrid for marketing, the platform's own SMTP for transactional. Odexy collapses this to one outbound path. Every module — CRM, Sales, Support, HRM, Recruitment, Payroll — emits the same email.outbound.send action. One suppression list. One template registry. One audit row.
What ships today
- Outbound sending —
email.outbound.sendaction: provider-agnostic, idempotent, audit-logged. - Template registry — versioned MJML templates per event class (e.g.
recruitment.offer.send,sales.invoice.send). Operator-customizable. - Suppression list — bounces + complaints + manual unsubscribes feed one list shared across the org.
- DKIM-branded sends — per-tenant custom domain + DKIM key; emails appear from
yourcompany.com, not Odexy. - Inbound webhooks — provider events (delivered, bounced, complained, opened, clicked) write to
email_messages_outbound.events. - Multi-provider — Postmark, SES, Resend, Mailgun — switchable per tenant. No vendor lock-in.
- Diagnostics — per-flow metrics, deliverability dashboard, "why stuck" log inspector.
How it integrates
Every other module calls Email — never directly imports a provider SDK:
- Recruitment — offer / interview / rejection emails.
- HRM — joining packs, leave decisions, time-tracking digests.
- Sales — quotation / invoice / dunning emails.
- Support — ticket replies + agent notifications.
- CRM — outbound campaigns + lead routing notifications.
- Payroll — payslip delivery.
Every module sends mail the same way, through one place, so templates, sending domains, bounce handling and suppression lists are configured once rather than per module.
How the AI helps
- "Send the invoice reminder to anyone overdue >14 days, polite-first-reminder template."
- "Why is the recruitment.offer.send rate dropping this week?"
- "Show me bounces in the last 24 hours and propose a suppression action."
- "Draft a one-line subject for the upcoming joining-pack template."
Send-actions are gated by the calling module's dangerous: true flag where appropriate.
Built for scale
- Idempotency keys — required on every send. Format:
<module>.<entity>.<verb>.<id>[.<discriminator>]. Duplicates within 24h return the existing row. - Rate limiting — per-org cap (default 10000/hour); per-permission
email:outbound:bypass_rate_limitfor known high-volume flows. - Message-ID uniqueness — DB unique-indexed; no double-sends.
- Audit log — every send with the originating event, the actor, the template, the recipient.
- Compliance — DPA-friendly: deletion + export include email history.
Odexy Email vs. the category
| | Odexy Email | Postmark | Customer.io |
|---|---|---|---|
| One outbound path across your whole stack | ✓ | — | partial |
| Joined to every entity in one schema | ✓ | — | — |
| Per-org pricing | ✓ | per-send | per-contact |
| AI sees deliverability + drafts copy | ✓ | — | — |
Postmark is the gold standard for transactional infrastructure; Customer.io for lifecycle. Both are providers — you still write the integration. Odexy Email is the integration, with Postmark / SES / Resend / Mailgun behind it.
Design-partner take
> "We had four different sending integrations across the company. Odexy collapsed them. One suppression list means a customer who unsubscribes never gets re-emailed by a different feature." — Design partner, 30-person SaaS