Email Hub
Inspiration
Managing multiple email accounts is surprisingly inconvenient, especially when the only thing you need is a verification code or activation link.
Many people use several providers at the same time, such as Gmail, Outlook, QQ Mail, 126 Mail, and 163 Mail. Verification emails are scattered across different inboxes, each provider has a different authentication method, and repeatedly switching between accounts interrupts automated workflows.
Email Hub was created to provide one secure and programmable entry point for multiple email accounts. Instead of acting as another traditional email client, it focuses on real-time email events, verification-code extraction, activation-link detection, and API-based access.
What It Does
Email Hub connects multiple email accounts through a unified service and provides:
- Unified access to Gmail, Outlook, QQ Mail, 126 Mail, and 163 Mail
- Real-time detection of newly received emails
- Automatic extraction of one-time passwords and verification codes
- Detection of activation, confirmation, and password-reset links
- REST APIs for querying or waiting for verification codes
- Webhook notifications for downstream applications
- Optional forwarding of important events to services such as Feishu, Telegram, or other notification channels
- Filtering rules that reduce irrelevant email exposure
Example API workflows include:
GET /api/otp/latest
GET /api/otp/wait
An automated application can request the latest verification code or wait until a matching email arrives, without directly implementing the authentication and synchronization logic of every email provider.
How We Built It
Email Hub uses a provider-adapter architecture.
Traditional providers such as QQ Mail, 126 Mail, and 163 Mail can be connected through IMAP using provider-specific authorization codes. Gmail can be integrated through OAuth 2.0 and the Gmail API, while Microsoft accounts can use OAuth 2.0 and Microsoft Graph.
Each provider adapter converts incoming messages into a normalized internal event format. The processing pipeline then:
- Receives or polls for new email events.
- Normalizes sender, recipient, subject, body, and timestamp information.
- Applies configurable filtering rules.
- Detects whether the message contains a verification code or actionable link.
- Extracts structured data using pattern matching and provider-aware parsing.
- Stores only the information required by the configured workflow.
- Exposes the result through REST APIs and webhooks.
The system is designed as an email-access middleware rather than a full mailbox replacement. This keeps the project focused, lightweight, and suitable for automation.
Challenges
The largest challenge was that email providers do not expose a consistent integration model.
Some providers support modern OAuth-based APIs, while others rely on IMAP and application-specific passwords. Their push-notification capabilities, rate limits, message formats, HTML structures, and authentication requirements are also different.
Verification-code extraction introduced another challenge. A numeric sequence inside an email is not necessarily a verification code. It may be an order number, date, amount, phone number, or account identifier. Email Hub therefore combines contextual keywords, sender rules, subject analysis, expiration language, HTML parsing, and configurable patterns instead of relying on a single regular expression.
Security was equally important. Email content may contain private information, so the project follows a least-privilege approach:
- Prefer OAuth tokens or provider authorization codes instead of account passwords
- Encrypt credentials and tokens at rest
- Avoid exposing complete email bodies through public APIs
- Return only the minimum structured information required
- Restrict API and webhook access through authentication
- Support configurable retention and automatic deletion policies
- Redact sensitive information from logs
Another challenge was real-time behavior. IMAP IDLE, scheduled polling, Gmail notifications, and Microsoft Graph subscriptions behave differently. The event layer abstracts these differences so downstream applications can use the same API regardless of the original provider.
What We Learned
Building Email Hub demonstrated that unifying email is not simply a protocol-conversion problem. A reliable solution also requires identity management, event normalization, provider-specific error handling, secure credential storage, message classification, and lifecycle management for expiring OAuth tokens and webhook subscriptions.
We also learned that a narrowly focused email service can be more useful than a complete email client. By concentrating on verification codes, activation links, notifications, and automation APIs, Email Hub can remain simpler while solving a clear operational problem.
What’s Next
Future development will focus on:
- More accurate verification-code and activation-link classification
- Provider-specific parsing templates
- A web dashboard for account, rule, and event management
- SDKs for common programming languages
- Fine-grained access control for teams and applications
- Audit logs and configurable data-retention policies
- Additional notification and automation integrations
- Health monitoring and automatic recovery for disconnected accounts
Our goal is to make Email Hub a secure, self-hosted, and programmable email middleware that allows applications and users to work with multiple inboxes through one consistent interface.
Log in or sign up for Devpost to join the conversation.