Connect
Hosted Google OAuth is in development. Other connection methods remain planned.
Communication infrastructure
One engine for
every conversation.
Build against one account, resource, command, and event model. In local development, the repository proves only its control plane, hosted Google authorization, signed webhook delivery, and one Google Calendar create method. No production or real-provider conformance is claimed; the broader channel runtime remains planned.
Designed forCRMATSOutreachAgentsiPaaS
LinkedInDecision-gated
WhatsAppDecision-gated
EmailPlanned
Calendar1 dev method
DewEngineModel · Route · Prove
Evidence surfaceNot production
calendar.event.createGOOGLE CALENDAR · DEVELOPMENT
{
"evidence": "google_calendar",
"state": "provider_confirmed",
"release": "development"
}Local proof · release gates open
01 Hosted Google OAuth02 Calendar create proof03 Broader runtime planned
The integration tax
Communication products should not need six architectures.
Every channel brings its own authentication, identifiers, payloads, limits, and failure modes. That work compounds before a customer sees one useful feature.
DewEngine turns those differences into a shared account, resource, command, and event model—without hiding the provider context your engineers still need.
Model
The target contract covers chats, messages, mail, calendars, attendees, and attachments.
Operate
Durable commands and provider attempts cover the narrow Calendar proof; broader operations remain planned.
Deliver
Signed webhook delivery is locally tested. Provider-originated channel events remain planned.
Channels
One resource model.
The channels people actually use.
Start with one connector and add the next without rebuilding your product boundary. Each channel page shows its current release or decision-gate state; DewEngine is not yet a production service.
Decision-gated: target profiles, conversations, invitations, and professional context
Decision-gated: target chats, groups, media, replies, and connection state
Planned: direct messages, profiles, media, and engagement context
Telegram
Planned: user-account messaging, groups, files, and events
Planned: Gmail, Outlook, and IMAP behind one mailbox model
Calendar
Development: one Google create method; the broader calendar model is planned
Built for developers
The common path stays small. The details stay available.
The development control plane already uses consistent authentication, errors, identifiers, command state, and webhook envelopes. Provider-specific methods are exposed only after their evidence and release gates are explicit.
- Server-side REST API and source TypeScript SDK
- Hosted Google authorization in development
- Idempotent commands and locally tested signed delivery
- Broader provider and MCP surfaces remain planned
Implemented development APITypeScript
const accounts = await dew.connectedAccounts.list();
const active = accounts.filter(
(account) => account.status === "ACTIVE"
); Tenant-scoped records · lifecycle metadata only
Built around the work
Communication belongs inside the system of record.
01
CRM
Keep the entire contact conversation attached to the customer record.
Explore →02Recruiting
Move from professional context to candidate conversation and scheduling.
Explore →03AI agents
Give an agent scoped communication tools with an auditable account boundary.
Explore →04Automation
Turn real replies and account events into workflow decisions.
Explore →Early access
Help shape the communication layer you wish existed.
Tell us which product you are building and which accounts must work first.