One mailbox contract with provider-native synchronization

DewEngine plans a shared email resource model for Gmail, Microsoft Graph, and IMAP/SMTP while preserving their different consent, cursor, folder, label, notification, and sending semantics.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Capability boundary

Mailbox connectors remain planned

The catalog describes target Gmail, Outlook, and IMAP/SMTP resources. Hosted mailbox authorization, provider methods, real-account synchronization, and production recovery evidence are not available today.

Catalog status and access: Gmail — planned, official api; Outlook mail — planned, official api; IMAP and SMTP — planned, open protocol
Authentication: Gmail requires a verified Google OAuth application for production scopes, Outlook uses Microsoft identity and tenant consent, and IMAP/SMTP requires a provider-supported secure credential or OAuth configuration.
Resources: mailboxes, threads, emails, drafts, folders, attachments, contacts
Target actions: email.list, email.get, email.send, email.update, email.delete, draft.create, folder.list
Target events: email.received, email.updated, email.deleted
Limitations and failures: No production mailbox read, sync, or send path is released; Gmail, Graph, and IMAP use different incremental state; Provider acceptance does not prove delivery, opening, clicking, or a human reply
Release gates: Gmail — Unavailable: hosted Gmail authorization, provider methods, Google subject-by-project grant ownership, production OAuth verification, and any required restricted-scope security assessment remain open; Outlook mail — Microsoft application registration, tenant consent, and production verification; IMAP and SMTP — TLS-only credential handling and provider capability negotiation

Mailbox model

Share resources without inventing identical mailboxes

The target contract uses accounts, messages, threads, containers, drafts, and attachments. Gmail labels, Graph folders and categories, and IMAP flags remain provider extensions because flattening them would make synchronization and support less reliable.

Connection

Bind authorization to the user and workspace

A connection intent should name the initiating tenant, validate callback state, and return a stable account identifier. Long-lived provider credentials stay in the connector boundary, never in browser storage or ordinary CRM records.

Synchronization

Persist provider-native checkpoints

Gmail history positions, Graph delta links, and IMAP mailbox state are not interchangeable. Each connector needs its own baseline, incremental transaction, expired-state recovery, deletion handling, and periodic reconciliation.

Sending

Model drafts, replies, and submission outcomes separately

Composition must preserve recipients, MIME content, attachments, sender identity, and reply context. A returned provider message identifier records submission or creation; later delivery or engagement claims need separate evidence and are not part of the current catalog.

Operations

Expose throttling, consent loss, and stale synchronization

Mailbox integrations fail over time through revoked grants, tenant policy, expired notification subscriptions, invalid cursors, protocol variation, or quota responses. The account state should tell the product whether to retry, resynchronize, reconnect, or ask an administrator.

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Can DewEngine synchronize a production mailbox today?+

No. Gmail, Outlook, and IMAP/SMTP are target connector contracts without released provider methods or real-account conformance.

Will DewEngine report opens and clicks from mailbox APIs?+

Not as a generic mailbox event. Such engagement states require separate, provider-supported evidence and are not declared in the current email capability catalog.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗