Microsoft Graph provides the official Outlook mail surface, but a durable integration still needs correct consent, per-folder delta state, subscription renewal, and provider-specific message behavior.
For a user-connected inbox, delegated permissions usually match the product boundary. App-only permissions are intended for background organizational access and normally require administrator consent; they should be a separate enterprise mode.
Model messages, attachments, drafts, folders, and sending through common resources, but retain Graph IDs, parentFolderId, conversationId, internetMessageId, categories, and change metadata for provider-specific operations.
Microsoft Graph message delta is a per-folder operation. Follow every @odata.nextLink until the round returns @odata.deltaLink, store that opaque URL, and track each folder independently rather than inventing one mailbox-wide cursor.
Graph change-notification subscriptions expire and must be renewed. Validate the notification endpoint, deduplicate events, handle lifecycle notices, and use delta to reconcile the authoritative state instead of trusting a notification as the full message record.
No. New implementations should use Microsoft Graph, Microsoft's current unified API surface for Outlook mail and calendar data.
No. Message delta is scoped to a folder, so each synchronized folder needs its own state and processing round.
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.