Planned capability

Account safeguards

Protect connected accounts with observable, fail-closed execution

Plan account protection as an execution contract spanning eligibility, pacing, concurrency, provider feedback, credential health, circuit breaking, and operator control. DewEngine cannot make provider accounts risk-free; it can prevent its own workers from turning uncertainty or overload into repeated, unbounded action.

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

Talk to us ↗Read technical guides →

Planned boundary

General account protection controls are not released

The provider-wide protection layer is planned and not callable. No customer API currently exposes per-provider quotas, pacing budgets, health scoring, kill switches, reconnect workflows, or a guarantee against provider restriction.

Current evidence: The Calendar development path has idempotent commands, durable provider attempts, dispatch fencing, unknown-outcome reconciliation, and feature flags. Webhook workers use bounded leases and retries. These narrow safeguards do not establish account pacing or protection across mail and messaging providers.
Target contract: Evaluate workspace policy, account capability, suppression, recent provider feedback, concurrency, and action-specific limits immediately before dispatch; Serialize risky writes per account where provider behavior requires it and persist the reason for every delay, refusal, or circuit transition; Expose healthy, degraded, attention, reconnect-required, suspended, and disconnected states with a precise operator action
Known limits: Providers control their platforms and may throttle, challenge, suspend, change policy, or withhold diagnostics despite conservative DewEngine behavior; No universal pacing formula can replace provider-specific contracts, real-account observation, customer consent, content quality, or responsible product rules
Release gates: Implement account-scoped rate budgets, write serialization, circuit breakers, manual holds, and reconnect state across released connectors; Prove fairness and safe recovery under throttles, expired credentials, ambiguous timeouts, duplicate jobs, worker crashes, and provider outages; Publish provider-specific limit signals, unsupported safeguards, escalation paths, and measured operational thresholds

Risk model

Protect the account that actually performs the action

Limits should be evaluated against the connected account, provider operation, recent outcomes, and sometimes the target conversation. A workspace-wide request counter is too coarse, while isolated endpoint counters miss combined pressure across jobs. The planned ledger therefore records provider attempts and account consumption before scheduling another potentially visible write.

Combine application entitlement with the provider's tighter operational boundary
Never borrow capacity from a different user's account

Implementation controls

Fence, lease, and recheck before dispatch

A worker takes a bounded lease, obtains an account-scoped lock when required, and revalidates capability, health, suppression, and budget after the lease. It records a durable pre-dispatch attempt so a crash cannot make the next worker assume nothing happened. Heartbeats prevent healthy long work from being mistaken for an abandoned job.

Use database authority rather than in-process counters for distributed workers
Expire leases safely without erasing an indeterminate provider outcome

Provider feedback

Turn throttles into state, not retry storms

A provider response may include retry timing, quota category, challenge, permission loss, or only a generic rejection. The connector should classify what is known, preserve sanitized diagnostics, and reduce or stop work at the relevant scope. Exponential retry alone is insufficient when the provider explicitly requires reauthorization or policy review.

Honor provider retry timing where the contract exposes it
Escalate repeated authentication and policy failures out of the queue

Operator control

Make the safest action one click away

Support and customer administrators need account pause, provider-wide circuit status, queued-write visibility, and a cautious resume path. A pause should fence new dispatch while preserving already confirmed history. Resume should not release an old backlog blindly; each queued action must still pass content, recipient, suppression, age, and capability checks.

Record who changed a hold and why
Expire stale human-visible actions before reopening an account

Release evidence

Test account safety under the ugly outcomes

Qualification should inject rate limits, partial provider success, connection challenges, stale leases, out-of-order replies, time jumps, and many tenants competing for one worker pool. Metrics need to demonstrate that one degraded account neither floods its provider nor starves healthy accounts, while every refused or delayed command remains explainable to an operator.

Run prolonged soak tests with deterministic provider faults
Verify kill switches from API request through worker dispatch boundary

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.

Can DewEngine guarantee that a provider will never restrict a connected account?+

No. Provider enforcement remains outside DewEngine's control. The planned safeguards can reduce self-inflicted risk, honor known limits, stop unhealthy work, and preserve evidence, but they cannot promise account safety.

Will the system automatically retry every provider error?+

No. Validation, permission loss, policy rejection, reconnect requirements, and unknown dispatch outcomes need different handling. Only classified transient failures within account limits should retry automatically; other states require correction or review.

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 ↗