Gmail message retrieval is a two-stage operation: list IDs for a bounded query, then fetch only the metadata, parsed payload, or raw MIME that the product needs.
Filter by Gmail search query and label IDs, respect page tokens, and keep the result order separate from synchronization correctness. A list response is intentionally lightweight and does not include every message field.
Use metadata for headers, full for parsed MIME structure, raw when the original RFC message is required, and minimal for identifiers and labels. Cache only the representation the feature and retention policy justify.
Walk nested parts, distinguish text and HTML alternatives, decode transfer encodings, validate content type and filename, and fetch attachment data by attachment ID when it is not inline in the payload.
After a baseline, use Gmail history records and watches to discover updates. Retain message and thread IDs, apply label changes and deletes, and full-sync again when the history cursor is no longer valid.
No. It primarily returns message identifiers. Fetch each selected message with messages.get in the format the feature requires.
No. Gmail's resource ID is provider-specific. Preserve it alongside the Internet Message-ID header when both are needed.
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.