Planned capability

Integration path

Add communication through one accountable system boundary

Plan an integration from workspace setup through account authorization, commands, normalized resources, and signed events. The intended benefit is not one magical endpoint; it is a stable ownership and failure model that remains understandable as an application adds carefully released providers.

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

Talk to us ↗Read technical guides →

Planned boundary

The end-to-end integration path is not released

The complete integration described here is planned and not callable. Local development components exist, yet there is no hosted customer environment or released cross-provider contract behind this page.

Current evidence: Repository code exposes development endpoints for workspaces, reveal-once hashed API keys, connected-account records, commands, events, webhook endpoints, and Google auth intents. A partial TypeScript SDK and static console exercise part of that local control plane.
Target contract: A server creates a tenant-scoped integration context and keeps each customer identifier opaque and immutable; An end user authorizes a provider through a bounded connection flow, after which reads, writes, and events carry the resulting account identifier; Common resources remain stable while provider extensions preserve behavior that cannot be normalized honestly
Known limits: The current Compose topology is a single-host development package without production ingress, KMS, backups, high availability, or operated service evidence; Provider routes have different release states, and adding a shared account record does not make an unreleased provider method usable
Release gates: Publish a versioned REST contract, scoped authorization model, lifecycle policy, and executable examples for every released method; Complete production tenancy, secret custody, monitoring, backup restoration, and incident-response evidence; Qualify each provider separately through policy review, sandbox faults, and consented real-account conformance

Starting point

Model the customer boundary before the channel

The first integration decision is which application workspace owns an account, not whether the first endpoint is mail or messaging. API keys, redirect allowlists, webhook destinations, and connected accounts must resolve to that same tenant. This gives support and audit tooling one reliable boundary when provider identifiers overlap or a user belongs to several customers.

Use DewEngine public IDs in application records instead of database keys
Keep development and future production credentials in separate environments

Implementation sequence

Connect, verify, then expose an action

A safe rollout starts with authorization and account health, then a narrow read or write whose provider outcome can be proven, then the events required to keep local state current. Adding a broad resource catalog before one vertical path survives revocation, retries, and deletion would create impressive documentation without an operable integration.

Release one vertical slice with its reconnect and retirement path
Bind examples to the exact capability state in the catalog

Resource design

Normalize cautiously and retain lineage

Shared fields should cover identifiers, account ownership, timestamps, participants, content, and state that has equivalent meaning. A versioned provider payload can retain diagnostic or channel-specific data without silently promoting it into the common contract. Consumers need to know whether a value came from provider truth, DewEngine inference, or application input.

Namespace every external identifier by provider and connected account
Version canonical schemas independently from raw provider payloads

Failure contract

Design errors as part of the integration

Applications need distinct responses for invalid input, missing permission, account attention, provider rejection, throttling, transient infrastructure failure, and unknown dispatch outcome. Each class drives a different product action. Collapsing them into a generic retry would create duplicate writes, hide reconnect work, and make an operator guess which system owns recovery.

Expose retry eligibility and required user action separately
Preserve sanitized provider diagnostics for support without leaking secrets

Adoption gate

Expand only after the first path is boring

The integration should grow when the initial provider has stable schemas, observable latency, bounded retries, tested revocation, and support procedures. New channels can reuse the account and event concepts, but they still need their own eligibility and failure evidence. Reuse is an architectural advantage, not permission to skip connector qualification.

Track capability status in code and public copy from one registry
Make unsupported operations fail explicitly instead of degrading silently

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 the local development API the same as a hosted DewEngine service?+

No. Local endpoints and tests establish narrow implementation evidence. They do not prove customer authentication, operated infrastructure, production provider grants, capacity, support, or a service-level commitment.

Must an application adopt every planned provider at once?+

No. The intended integration is incremental. A team should select one authorized provider path, verify the complete account-to-event lifecycle, and add another channel only when its separate catalog status and release gates permit it.

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 ↗