The OAuth redirect is only the front door; a production Gmail connection also needs tenant ownership, verified scopes, token isolation, baseline sync, and an understandable reconnect state.
Configure a Google Cloud project, consent screen, exact redirect URI, and the smallest Gmail scopes required by the feature. Production use of sensitive or restricted scopes may require verification before broad customer access.
Create a short-lived connection intent that names the workspace and user, validate OAuth state at the callback, exchange the code on the server, and return only a DewEngine account ID to the browser.
Validate the mailbox identity, encrypt refresh material, run the chosen baseline synchronization, create the Gmail watch, and expose progress. A successful redirect alone does not prove background access will remain healthy.
Tokens can be revoked and watches expire. Before upstream revocation, identify every product account attached to the same Google user and API project: Google can invalidate the combined scopes and tokens across every client in that project. Surface that grant-wide blast radius and never silently fall back to stored credentials.
Do not copy one credential into several tenant rows. Google can combine a user's scopes across clients in one API project, so DewEngine needs one grant owner, tenant-fenced product attachments, and an explicit whole-grant revocation boundary. Independent tenant revocation requires separate approved Cloud projects.
In an encrypted server-side token store with strict tenant and service access controls, never in browser storage or ordinary application records.
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.