One account and event boundary across communication channels

DewEngine is designing a common contract for messaging, mailbox, and calendar workflows while keeping every provider's authorization model, identifiers, and release state visible.

Decision gate closed. This access path is neither approved nor implemented; no provider action is available.

Talk to us ↗Read technical guides →

Capability boundary

A mixed roadmap, not a released universal API

The control plane and one Google Calendar create path are development work. Mail and most official-provider connectors remain planned or in research, while account-session access for LinkedIn, WhatsApp App, and broader Instagram use is decision-gated.

Catalog status and access: Gmail — planned, official api; Outlook mail — planned, official api; IMAP and SMTP — planned, open protocol; Google Calendar — development, official api; Outlook Calendar — planned, official api; Telegram user accounts — planned, official account api; WhatsApp Business Platform — research, official api; WhatsApp App accounts — decision gated, non official session; LinkedIn account products — decision gated, non official session; Instagram professional accounts — planned, official api; Broader Instagram account access — decision gated, non official session; X — research, undecided; Messenger — research, undecided; SMS — research, undecided
Authentication: Authentication remains provider-specific: OAuth for Google, Microsoft, and official Meta paths; application credentials and encrypted sessions for Telegram; negotiated credentials or OAuth for IMAP/SMTP; and no account-session connector before its policy gate is cleared.
Resources: mailboxes, threads, emails, drafts, folders, attachments, contacts, calendars, events, attendees, availability, chats, messages, groups, profiles, companies, relations, invitations, posts, search, jobs, conversations, media, business_conversations, templates
Target actions: email.list, email.get, email.send, draft.create, folder.list, calendar.event.create, chat.list, chat.get, message.list, message.get, message.send, profile.get, company.get, search.perform
Target events: email.received, email.updated, email.deleted, calendar.event.created, message.received, message.sent, account.status
Implemented development slice: calendar.event.create, calendar_event.list, calendar_event.get, calendar.event.created
Limitations and failures: No production provider connector is released; Provider schemas and consent rules do not collapse into one lowest-common-denominator contract; Decision-gated access paths require approval before implementation or sale
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; Outlook mail — Microsoft application registration, tenant consent, and production verification; IMAP and SMTP — TLS-only credential handling and provider capability negotiation; Google Calendar — Isolated development only: Google OAuth verification, subject-by-project grant ownership, managed KMS, whole-grant upstream revocation/deletion, quota and provider-failure testing, and consented real-account conformance remain open; Outlook Calendar — Microsoft application registration, tenant consent, and subscription renewal; Telegram user accounts — Telegram application credentials, encrypted sessions, and flood-wait enforcement; WhatsApp Business Platform — Meta business verification, application review, opt-in, templates, and quality enforcement; WhatsApp App accounts — Qualified legal review and explicit product-risk approval are required before implementation or sale; LinkedIn account products — Qualified legal review and provider/product authorization are required before implementation or sale; Instagram professional accounts — Meta application review and professional-account eligibility; Broader Instagram account access — Qualified legal review and explicit product-risk approval are required before implementation or sale; X — Select an authorized provider contract before defining capability; Messenger — Select an authorized provider contract before defining capability; SMS — Select a carrier or communications API contract before defining capability

Account model

Make the connected account the unit of authority

A workspace may eventually hold several provider accounts, but every command and event must retain the exact account that authorized it. Product permissions sit above that boundary; a shared contact record never grants access to another user's mailbox or messaging session.

Resource design

Normalize the common path without erasing provider truth

Stable account, message, email, calendar, attendee, and attachment identifiers can simplify product code. Provider identifiers and extensions still need to travel beside them so reconciliation, support, and channel-specific actions remain possible.

Command lifecycle

Separate acceptance from the final outcome

A write should move through durable command and provider-attempt states. A provider acknowledgement can confirm that an operation was accepted or created; it does not by itself prove recipient delivery, engagement, or a durable synchronization result.

Events

Use notifications to advance work, then reconcile

The target event envelope identifies the workspace, account, provider, event type, and resource. Consumers must deduplicate deliveries and use provider reads or connector checkpoints where notifications are hints rather than the authoritative record.

Adoption

Choose one evidenced connector before expanding

A team should select the account type and smallest workflow it actually needs, review the applicable release gate, and test that slice with real provider accounts before relying on another channel. A route in this site is a design brief, not proof that the connector exists.

Decision-gated contract

Review the policy boundary before implementation.

This shape documents a blocked product boundary. Legal, provider, and product-risk gates must clear before implementation or sale; it is not callable.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapeDecision-gated · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No approved connector · no provider request

Questions

Before you build.

Is the complete communication API available today?+

No. The repository contains development control-plane work and a narrow Google Calendar create path. Every other provider surface remains planned, research, or decision-gated as shown in the capability boundary.

Does one schema make provider behavior identical?+

No. The common contract covers shared concepts, while provider extensions, native identifiers, access rules, and failure details remain visible.

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 ↗