A useful unified layer keeps account, message, draft, attachment, and event workflows stable while making provider-only fields and constraints explicit rather than pretending all mailboxes behave alike.
Use consistent account, address, thread, message, draft, attachment, and container shapes. Identify every object with a DewEngine ID and retain its provider ID for support, migrations, and native operations.
Gmail labels can overlap, Graph delta is per folder, and IMAP capabilities vary by server. Put provider extensions and capability discovery beside the common fields rather than dropping data into an undocumented lowest common denominator.
The interface can be shared, but Google verification, Microsoft consent, and IMAP/SMTP credential or OAuth setup remain provider-specific. Return a stable account ID and a precise connection state after each flow.
Offer exportable identifiers and data, documented event versions, raw diagnostic codes, and account deletion. A customer should understand which provider feature is unavailable without reverse-engineering the normalization layer.
The common contract can be consistent, but provider capabilities, consent, limits, and synchronization semantics still differ. The API should report those differences, not conceal them.
Capability discovery should mark it unsupported before execution, and the API should return a stable unsupported-capability error rather than a false success or silent approximation.
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.