Planned capability

Integration platform builders

Expose communication as reliable actions and recoverable triggers

Plan an iPaaS adapter around stable account references, schema discovery, asynchronous commands, event deduplication, and precise failure branches. DewEngine's role is the provider-facing communication boundary; the integration platform continues to own workflow scheduling, step data, customer authentication, replay policy, and connector user experience.

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

Talk to us ↗Read technical guides →

Planned boundary

There is no released iPaaS adapter contract

This integration-platform use case is planned and not callable. No production action catalog, trigger subscription, connection component, schema-discovery endpoint, or certified adapter exists for an iPaaS publisher.

Current evidence: Development services expose some REST records and signed webhook deliveries, while the TypeScript SDK models a subset of requests. There is no external application identity, delegated iPaaS connection, broad resource schema, hosted provider fleet, or long-running trigger conformance.
Target contract: Map each iPaaS customer connection to one DewEngine workspace and expose only the connected accounts and operations that customer may use; Represent provider-visible writes as idempotent commands whose eventual state can be polled or received as a signed event; Offer cursor-based reads and replayable triggers with versioned schemas, stable identifiers, and raw provider extensions where documented
Known limits: End-to-end exactly-once execution is not possible across an iPaaS scheduler, DewEngine, networks, and third-party providers; every boundary needs its own deduplication contract; An adapter cannot hide provider eligibility, missing events, asynchronous outcomes, message windows, payload limits, or a platform's own runtime and storage rules
Release gates: Stabilize the REST and event contracts, scoped application authorization, pagination, error codes, and deprecation policy; Prove idempotency across repeated iPaaS runs, webhook replay, cursor gaps, delayed settlement, credential retirement, and connector upgrades; Publish operation-level provider coverage and pass the chosen integration platform's security, review, and lifecycle requirements

Connection model

Separate platform authorization from provider authorization

The iPaaS first authorizes its customer to a DewEngine workspace through an application-level grant. That customer then selects a provider account it has separately connected. Keeping these relationships distinct lets either side be revoked without exposing provider secrets to the integration platform or accidentally sharing one customer's account with another workflow tenant.

Use opaque account choices populated after workspace authentication
Display provider attention and reconnect state in the connection test

Implementation adapter

Map one platform run to one durable command

The adapter derives an idempotency key from connection, workflow, step, and run identity, then retains the DewEngine command ID. Short runtime timeouts return a waiting state rather than creating another write. Later polling or callback settlement resumes the same step, including indeterminate states that require operator review instead of automated repetition.

Keep orchestration retries separate from provider dispatch retries
Return structured branch codes rather than parsing human error text

Trigger contract

Make instant and polling triggers converge

A signed DewEngine event can wake an instant trigger, while a cursor read repairs delivery gaps or platform downtime. Both paths use the same event ID and resource version so overlap produces one workflow occurrence. Subscription expiry, dead-letter delivery, or account sync degradation should produce visible administrative state rather than a misleading empty trigger result.

Persist trigger cursors per customer connection and event filter
Bound historical replay to an explicit operator-selected window

Schema evolution

Keep saved workflows valid across additive change

Integration platforms often cache fields when a workflow is authored. Required inputs, enums, nested output, and provider extensions therefore need stable versioning and clear defaults. Removing a provider capability should disable new configuration and give existing workflows a precise migration state, not let an old template invoke an operation the account no longer supports.

Test archived workflow definitions against every supported adapter version
Represent optional provider fields without changing common-field meaning

Partner gate

Release the adapter after operational ownership is agreed

Before launch, DewEngine and the iPaaS publisher need a support boundary for customer identity, provider reconnect, stuck commands, replay, abuse reports, and schema changes. Load tests should reflect platform fan-out and bursty schedules. Documentation must state which party owns suppression, retention, payload storage, and any human approval in the workflow.

Trace one support correlation ID across both platforms
Rate-limit by customer account without starving unrelated tenants

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 DewEngine intended to replace an iPaaS workflow engine?+

No. DewEngine's planned responsibility is account authorization and communication execution. The iPaaS still schedules steps, stores workflow state, transforms data, obtains business approval, and decides how failures branch.

Can an iPaaS mark a send complete when DewEngine accepts the command?+

Only as accepted for processing, not as provider-confirmed or delivered. The adapter must retain the command ID and wait for its explicit outcome, including an indeterminate state when dispatch cannot be proven safely.

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 ↗