Planned capability

Outreach product builders

Build outreach that stops before automation becomes noise

Plan multichannel outreach around explicit audience eligibility, connected-account ownership, conservative pacing, durable provider outcomes, reply detection, suppression, and human control. DewEngine would execute a qualified communication step; it would not supply targets, manufacture consent, optimize pressure, or authorize unsolicited contact.

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

Talk to us ↗Read technical guides →

Planned boundary

No multichannel outreach execution is released

This outreach product use case is planned and not callable. DewEngine has no sequence engine, lead source, mailbox sender, messaging sender, reply monitor, warm-up service, deliverability product, or customer outreach account.

Current evidence: Repository primitives can persist idempotent commands and deliver signed development webhooks, while the Calendar connector demonstrates narrow ambiguity handling. Gmail has no provider method and messaging routes remain planned, research, or decision-gated according to their separate capability evidence.
Target contract: Accept a single application-authorized step tied to workspace, connected account, recipient evidence, purpose, suppression result, content version, and schedule window; Apply provider capability, account pacing, thread state, and stale-action checks immediately before durable dispatch; Use stored inbound replies and explicit opt-out events to cancel every related pending step across accounts and channels
Known limits: DewEngine will not sell contact data, validate consent, evade provider controls, guarantee inbox placement, simulate human behavior, or promise response rates; Provider terms, message windows, mailbox reputation, regional law, recipient preference, account age, content, and incomplete event coverage can all prohibit or limit outreach
Release gates: Select only authorized provider paths and publish operation-level limits, access eligibility, and event gaps; Implement global suppression, reply-stop propagation, per-account pacing, daily caps, manual holds, idempotency, and unknown-send reconciliation; Pass abuse review, complaint handling, consented real-account tests, long-running soak tests, and auditable human-approval journeys

Responsibility split

Make the outreach product prove eligibility first

Before DewEngine receives a command, the calling product should know the recipient source, permitted purpose, relevant consent or relationship, suppression state, responsible workspace, and approved content. A provider's technical ability to deliver a message is not permission. Missing eligibility evidence should produce no queued work and no provider request.

Store the policy decision and evidence reference with each command
Refuse audience uploads that bypass the product's own eligibility review

Implementation dispatch

Reserve account capacity before a visible action

The planned worker acquires the account boundary, checks current pacing and circuit state, reserves the operation budget, records a pre-dispatch attempt, and only then calls the provider. A deterministic idempotency key maps scheduler retries to the same command. Ambiguous outcomes remain held until a safe provider-specific reconciliation proves what happened.

Re-evaluate suppression after queue delay and before dispatch
Never convert an unknown outcome into automatic resend

Reply stopping

Prefer false stops over one unwanted follow-up

An inbound resource tied to the recipient and native thread should suppress pending steps as soon as durable evidence arrives. When identity mapping or event coverage is uncertain, the workflow can pause for review rather than continue confidently. Edited, duplicated, or delayed observations should not reactivate a sequence that was already stopped.

Propagate opt-out and reply holds across every linked channel
Expose synchronization lag beside any automatic continuation decision

Account health

Let provider pressure slow the product down

Throttles, bounces, challenges, reconnect signals, quality warnings, and complaint indicators should reduce or halt work at the narrowest safe scope. The product needs a visible reason and operator next step. Automatically switching to another account or channel to evade a restriction would violate the intended protection boundary rather than improve reliability.

Do not route around an account or recipient suppression decision
Expire old queued steps before a paused campaign resumes

Release evidence

Measure prevented harm alongside successful execution

A responsible test program covers duplicate scheduler runs, reply during delay, opt-out propagation, account reassignment, provider throttle, bounce, expired credential, worker crash, uncertain send, and missing notification. Release metrics should include refused actions, prevented duplicates, stop latency, complaint handling, and unresolved outcomes, not merely throughput or messages accepted.

Run synthetic and consented fixtures before any broader workflow
Require an operator-readable audit for every outbound action

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 DewEngine make unsolicited outreach acceptable?+

No. A connector cannot create consent, lawful purpose, relevance, or provider permission. The outreach product and its customer remain responsible for eligibility, content, suppression, and respectful use before any command reaches DewEngine.

Will a sequence switch accounts when one account is throttled?+

Not as an automatic evasion tactic. The planned protection boundary should slow or stop the affected work, preserve the provider feedback, and require a policy-valid operator decision before any alternative path is considered.

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 ↗