Planned capability

Interoperability boundary

Build portable account flows without making a legal promise

Treat interoperability as a product design discipline: explicit authorization, visible source lineage, disconnectable access, and bounded data movement. This route does not determine whether a business, platform, provider interface, or use case falls under the Digital Markets Act or any other law.

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

Talk to us ↗Read technical guides →

Planned boundary

This is architecture guidance, not a compliance feature

The interoperability surface is planned and not callable, and the page is not legal advice or a statement of DMA compliance. Provider rights, statutory eligibility, and customer obligations require independent analysis.

Current evidence: The development control plane records workspace-owned accounts, allowlisted redirects, Google authorization intents, and a local credential-retirement workflow. Those mechanisms demonstrate bounded state transitions only; they do not establish regulatory entitlement, portability, or production deletion.
Target contract: Record who authorized each account, which provider path supplied the data, and what application workspace may act on it; Expose connection state and a deliberate disconnect path without implying ownership of the provider-side identity; Keep normalized resources traceable to native identifiers so an export or correction can preserve provenance
Known limits: DewEngine cannot confer provider access, override platform terms, or decide that a customer qualifies for a statutory interoperability right; A local ciphertext-clearance test does not prove upstream grant revocation, backup expiry, complete erasure, or a legally sufficient data-subject workflow
Release gates: Obtain qualified review for the chosen providers, jurisdictions, data roles, and customer-facing claims; Implement consent records, export lineage, correction, retention, deletion, and grant-wide revocation with auditable outcomes; Verify authorized provider contracts and production operations before describing any interoperability path as usable

Product posture

Separate technical portability from legal eligibility

A portable resource model can reduce customer lock-in even where no regulation applies. Conversely, a statutory right may carry conditions that a generic connector does not satisfy. Product copy, onboarding, and contracts should distinguish those questions so an engineering convenience is never presented as permission from a provider or regulator.

Describe the implemented transfer mechanism, not a broad legal conclusion
Attach jurisdiction and provider review to each release decision

Implementation controls

Carry authorization context with every resource

The planned model associates a native account, grant or session type, consent record, workspace owner, and allowed purpose. When a provider token changes or a user disconnects, dependent jobs should be fenced before secret retirement. Data that remains for audit or contractual reasons needs a separate retention basis and expiry, not an accidental orphaned row.

Fence writes before retiring authorization material
Record purpose and retention decisions independently from connector health

Data movement

Preserve meaning when schemas cross systems

An export should include stable DewEngine identifiers, provider lineage, timestamps, and schema versions so another system can interpret the record. Provider-only fields should remain clearly named instead of being forced into misleading common values. The receiving application remains responsible for its own lawful basis, access controls, and deletion lifecycle.

Make transformations explicit and reversible where practical
Avoid claiming that a normalized field is authoritative when it is inferred

Provider constraint

Interoperability does not erase access rules

Official interfaces can restrict account types, scopes, review status, message windows, retention, or downstream use. Non-official access paths may carry a different legal and product-risk profile. DewEngine's capability catalog must keep those paths separate, with the most cautious release state controlling what public pages and clients may rely on.

Do not merge official and session-based access into one marketing claim
Disable a path when its policy gate is unresolved

Release evidence

Prove revocation and export as full lifecycles

A release review should start before authorization and finish after disconnect, deletion, or export. Tests need to cover stale callbacks, duplicate retirement work, upstream ambiguity, cross-tenant identifiers, expired backups, and partially failed exports. Legal review can then evaluate a concrete mechanism instead of aspirational diagrams or feature names.

Exercise the same provider grant shape used in the operated environment
Retain evidence of outcome without retaining the secret being removed

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.

Does using DewEngine make an application compliant with the Digital Markets Act?+

No. Compliance depends on the parties, service, jurisdiction, data flow, provider terms, and exact legal duties. DewEngine can only expose technical controls after they are implemented and verified; qualified counsel must assess the legal position.

Does explicit user authorization guarantee provider permission?+

No. User intent is necessary for the planned account model, but provider eligibility, application review, approved scopes, contractual restrictions, and applicable law can still limit or prohibit a requested capability.

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 ↗