Plan Gmail around consent, history state, and recoverable sends

The target Gmail connector covers mailbox resources and provider-backed received, updated, and deleted events. Hosted Gmail authorization, mailbox methods, synchronization, and production evidence are not available today.

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

Talk to us ↗Read technical guides →

Capability boundary

Gmail is a planned official-API connector

The catalog defines target mailbox resources and methods but no implemented provider operation. Google grant ownership, production verification, and any restricted-scope assessment remain open before release.

Catalog status and access: Gmail — planned, official api
Authentication: A customer-controlled Google OAuth application must request the least Gmail scopes needed, bind the callback to the initiating tenant, and keep delegated tokens server-side. Hosted Gmail authorization is not exposed.
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 Gmail provider method is implemented; No hosted Gmail authorization or mailbox sync; Delivery, open, click, and reply events are not declared
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

Grant boundary

Model the Google user and API project together

Google can combine a user's granted scopes at the API-project boundary across clients. DewEngine must keep Gmail and Calendar product accounts beneath that shared grant and distinguish local product unlink from whole-grant upstream revocation.

Baseline

Build a bounded mailbox view before consuming changes

A future connector should list the selected window, retrieve required message fields, preserve Gmail message and thread identifiers, page to completion, and commit a starting history position only with the local baseline.

Incremental sync

Advance history state transactionally

Mailbox notifications should wake a worker, not replace provider reads. The worker applies additions, deletions, and label changes, commits them with the next history position, and enters a controlled full-resync path when the provider no longer accepts the saved state.

Drafts and sends

Preserve MIME, sender identity, and idempotent intent

The target send path needs validated recipients, MIME alternatives, attachments, reply headers, and a stable application command key. A Gmail message ID records the provider result; it does not prove final delivery, opening, clicking, or a human reply.

Operations

Expose quota, consent, watch, and reconnect failures

Expired watches, revoked grants, invalid history state, quota responses, malformed content, and missing messages require different recovery. Production release needs real-account tests for each state and managed credential encryption.

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.

Is Gmail mailbox access available?+

No. Gmail remains planned, with hosted authorization, provider methods, sync, verification, and real-account conformance still open.

Will Gmail sends produce open or click events?+

Not through the declared Gmail connector. The catalog includes received, updated, and deleted mailbox events only.

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 ↗