Mailbox products need more than a send endpoint: define account authorization, message and thread resources, provider synchronization, sending, events, security, and recovery as one system.
Mailbox APIs act inside a user's existing account. Transactional delivery APIs send application mail. Marketing platforms manage campaigns. A product may need several, but their identities, permissions, deliverability, and data models should remain explicit.
Use Gmail API for Google accounts and Microsoft Graph for Outlook. Add secure IMAP for other mailbox access and SMTP for submission, while preserving server capability differences and provider-native fields.
Connection, baseline sync, active, degraded, reconnecting, resyncing, and disconnected are normal lifecycle states. Commands and webhooks must be idempotent and every provider cursor must advance transactionally.
A connector is sellable only after send, read, reply, move, delete, attachment, sync, reconnect, quota, and revocation cases pass against the account types promised on the website.
No. SMTP submits outgoing mail. A mailbox API can also read, organize, draft, reply, synchronize, and expose account-specific resources and changes.
Usually the long-running lifecycle: consent, synchronization, cursor recovery, provider differences, reconnection, and protecting sensitive mailbox data.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.