Email Hub

What this Email Hub covers

Email Hub is more than a single provider form. In the current OrcaPulse project, it acts as the control center for outbound email infrastructure, giving teams multiple connection models depending on how they want email to be sent.

That includes mailbox-style OAuth connections, transactional provider API keys, and direct SMTP configuration. Once connected, those resources power templates and workflow steps throughout the product.

Provider types and connection models

The current Email Hub supports several families of providers instead of forcing one delivery model on every team. Some setups are easiest through OAuth, others are best through API keys, and some teams still need SMTP-level control.

• OAuth connections: Gmail, Outlook, Zoho Mail, and Yahoo can connect through account authorization flows.
• API-key providers: Resend, SendGrid, Brevo, Mailgun, Postmark, ZeptoMail, SparkPost, Amazon SES, Proton, Fastmail, and iCloud are already represented in the UI registry.
• SMTP configuration: SMTP exists as a separate operational path for custom or direct mail transport control.
• Unified surface: all of these options are exposed through the same Email Hub experience instead of fragmented setup pages.

OAuth, API keys, and SMTP setup

Each provider path has its own setup behavior in the project. OAuth flows are account authorization based. API-key providers ask for sending identity plus provider-specific credentials. SMTP asks for the classic server, port, security, username, and password fields, then verifies the setup before marking it active.

This structure matters because Email Hub is built for real sending, not only for collecting credentials. The product validates providers and preserves the active sender identity that workflows will later rely on.

• OAuth setup: mailbox accounts connect through dedicated auth flows and become reusable sending resources.
• API-key setup: provider-specific credentials are stored with the selected sender email and sender name.
• Provider-specific fields: some providers need extra data like Mailgun domain or AWS region and secret key.
• SMTP verification: SMTP config includes a verification and test path before it should be trusted in workflows.

Templates and sending flow

Email Hub does not live in isolation. It works alongside the Email Templates system so teams can connect infrastructure first, then send structured messages through workflows or direct operational flows.

Once a provider is connected, workflows can use the active provider to send email steps. The templates layer handles subject and body content, while Email Hub handles the sending account and delivery transport.

• Separated concerns: templates define content, Email Hub defines how the content is sent.
• Reusable sender identity: connected providers expose `from` email and `from` name for future sends.
• Workflow dependency: email steps need a connected provider before they can operate reliably.
• Operational consistency: the same provider can be reused across multiple automations instead of being re-entered every time.

Testing and operational checks

Reliable email setup is operational work, not just configuration work. The project already includes controller support for testing and validating providers, especially around SMTP and API-key flows, so teams can catch bad credentials before a workflow fails at send time.

This also means Email Hub should be treated like core infrastructure. If email is part of a qualification or follow-up flow, the provider status matters just as much as templates, phone numbers, or social connections.

• Credential validation: provider setup checks whether keys or transport settings actually work.
• SMTP testing: SMTP config has explicit test and verification endpoints in the backend.
• Active-provider model: the system tracks whether a connected provider is active before using it for sends.
• Workflow readiness: teams should confirm provider status before relying on email steps in production automations.

How to launch email well

The best first Email Hub launch is usually simple: connect one provider, verify it, test a real send, and make sure one template-driven workflow can complete end to end. After that, expand into multiple providers or fallback paths only if the operating model really needs them.

Email becomes valuable when the system is predictable. Clear sender identity, verified credentials, and known template behavior matter more than connecting every possible provider on day one.

• Start with one provider: prove one stable sending path before adding multiple transport options.
• Verify deliverability basics: test a real send instead of assuming credentials are correct.
• Pair with one template: validate content plus delivery together in a small workflow.
• Keep fallback intentional: only add SMTP or extra providers when the team truly needs redundancy or provider-specific features.

Next steps

After Email Hub, the most useful next pages are usually Workflow Setup and Follow-up Automation, because those show how connected email infrastructure gets used in actual delivery and execution flows.