Planned capability

REST contract

Make provider outcomes predictable without pretending providers match

Plan a versioned JSON API around tenant ownership, stable public identifiers, explicit capability, durable writes, and truthful outcome state. The current repository contains a useful control-plane development slice; the broader communication resource contract and operated service described by this route remain unreleased.

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

Talk to us ↗Read technical guides →

Planned boundary

The unified REST API is not a customer endpoint

The cross-provider REST surface is planned and not callable as a hosted product. Development routes for control-plane records do not prove a released messaging, mail, calendar, profile, or agent API.

Current evidence: Quarkus resources implement tenant-scoped workspaces, API keys, connected accounts, commands, events, webhook endpoints, redirect URIs, auth intents, and a narrow Calendar create/list/get development path. The source TypeScript SDK covers only part of this surface.
Target contract: Use opaque immutable public IDs, consistent collection envelopes, cursor pagination, request validation, and versioned error codes across released resources; Require idempotency for externally visible writes and expose queued, attempted, indeterminate, provider-confirmed, or rejected state accurately; Advertise methods from the capability catalog so an account cannot invoke an operation its provider path has not qualified
Known limits: A common envelope cannot erase provider-specific permissions, asynchronous behavior, message windows, quota units, resource gaps, or native identifiers; The development API lacks customer sign-in, scoped application roles, production infrastructure, a complete OpenAPI lifecycle, and released multi-provider conformance
Release gates: Freeze versioning, pagination, filtering, idempotency, error, deprecation, and provider-extension rules in a reviewed OpenAPI contract; Implement scoped credentials, tenant-isolation attacks, quotas, audit access, request limits, and backward-compatibility tests; Execute every published sample against an operated environment and hide methods whose connector evidence is incomplete

Resource contract

Put ownership in every path and object

Authentication resolves one workspace before a resource lookup begins. Connected accounts, commands, events, and future messages or mail remain tenant-scoped even when their provider identifiers collide. Responses use DewEngine public IDs for durable references and carry provider identity separately, which prevents a native key from becoming accidental cross-customer authority.

Return not found across tenant boundaries instead of leaking existence
Never reuse a public identifier after deletion

Implementation semantics

Separate acceptance from provider confirmation

A write can be durably accepted before any provider request occurs. The API should return a command identifier and explicit state, then permit polling or event-driven settlement. Synchronous convenience is appropriate only when the provider outcome is known inside a bounded request and still must not be mislabeled as recipient delivery or business completion.

Expose attempt history through sanitized support views
Leave uncertain dispatches indeterminate until reconciliation proves an outcome

Collection behavior

Use cursors that survive changing datasets

Large conversations and event streams need opaque cursors tied to a documented sort order and filter set. Numeric page offsets drift when new provider observations arrive. The contract should bound limits, reject incompatible cursor reuse, and explain whether results reflect a snapshot or a moving collection so clients can resume safely.

Keep cursor internals private and versioned
Return stable tie-break identifiers when timestamps match

Error boundary

Give clients one safe response to each failure class

Validation, authentication, missing capability, account attention, quota, provider rejection, transient infrastructure, and unknown outcome should have distinct machine codes. Raw provider context can appear in a bounded extension after redaction. Clients then know whether to correct input, ask the user to reconnect, wait, stop, or request operator review.

Do not expose provider credentials or full upstream bodies
Document retry eligibility beside each canonical code

Compatibility gate

Make every released method executable evidence

Schema validation alone cannot qualify a connector. Contract tests must run SDK requests through authentication, persistence, worker dispatch, provider fakes, settlement, and signed events. Real-account conformance then checks the authorized provider behavior. A method remains absent from generated documentation until both the shared contract and its provider-specific gates pass.

Generate clients from the same reviewed API description
Test old clients against additive server releases

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.

Are the repository's development REST routes a public service?+

No. They provide local executable evidence for a narrow control plane and Calendar slice. Hosted availability, customer authorization, provider approval, operational capacity, support, and broader resource coverage have not been established.

Will one normalized request behave identically on every provider?+

No. DewEngine's target is consistent ownership, identifiers, command state, and errors. Provider-specific capabilities, permissions, timing, quotas, and outcomes remain visible through capability data and bounded extensions.

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 ↗