Planned capability

Event delivery

Treat real-time as durable evidence, not instant magic

Design product reactions around versioned events that can be verified, deduplicated, and replayed. DewEngine's broader real-time goal covers provider observations and account health, while its existing development evidence is limited to a signed delivery pipeline and a very small set of canonical event producers.

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

Talk to us ↗Read technical guides →

Planned boundary

Broader provider events remain a planned contract

The cross-channel real-time surface is planned and not callable as a customer service. Tested webhook mechanics do not establish live subscriptions, message events, mailbox changes, or calendar watches for unreleased connectors.

Current evidence: The worker can sign webhook requests with HMAC-SHA256, reject unsafe destinations, lease deliveries, retry transient failures, dead-letter exhausted work, record attempts, and replay explicitly. Sandbox events and one development-only Calendar created event exercise that machinery.
Target contract: Publish a versioned envelope with immutable event ID, event type, occurrence time, workspace, connected account, resource identity, and sanitized payload; Persist the canonical event and its delivery jobs before attempting a customer endpoint, then expose delivery state separately from provider state; Allow consumers to deduplicate, recover missed delivery, and fetch the referenced resource when an event is only a change signal
Known limits: Webhook delivery will be at least once; duplicates, endpoint downtime, network ambiguity, and out-of-order observations must be expected; A provider may offer delayed, incomplete, expiring, or wake-up-only notifications, so the event catalog cannot promise universal immediacy or coverage
Release gates: Add secret rotation, endpoint filters, replay authorization, payload-version policy, and tenant-isolation tests; Prove queue fairness, bounded retry, recovery after crashes, load behavior, and an operated delivery objective; Qualify each canonical event against an authorized connector's actual notification and reconciliation lifecycle

Event semantics

Name what happened and who observed it

A useful event distinguishes a provider-originated change from a DewEngine command result and from an application request. Its payload should state the connected account and resource version involved. Consumers can then decide whether to update a screen, advance a workflow, or fetch current state without interpreting transport timing as business meaning.

Keep event occurrence, ingestion, and delivery timestamps separate
Version payload meaning instead of silently repurposing old event names

Implementation pipeline

Commit once, deliver independently

Canonical event creation belongs in the same transaction as the resource or command settlement that caused it. After commit, one delivery job per eligible endpoint can progress through its own lease and retry history. This prevents an endpoint outage from rolling back provider truth and keeps replay from creating a second domain event.

Use event IDs as consumer deduplication keys
Retain a delivery attempt ledger without storing signing secrets in logs

Consumer design

Acknowledge fast and project idempotently

A receiving service should authenticate the signature against the raw body, reject stale or invalid requests, persist the event ID, and respond before expensive downstream work. Its projector can process asynchronously and safely see the same event again. Ordering assumptions should be scoped narrowly to a resource version, never to the entire workspace.

Store the original event ID beside each derived update
Fetch authoritative state when a later version arrives first

Recovery boundary

Make missed delivery an operator-visible state

Retries need a cap because a permanently invalid endpoint should not consume the queue forever. Dead-letter status, the last sanitized response, next action, and explicit replay permission belong in the console. Changing a destination or rotating a secret must not silently replay historical data outside the customer's chosen window.

Require deliberate replay after endpoint repair
Separate transient transport failures from invalid destination policy

Provider reality

Pair notifications with reconciliation

Some provider callbacks are complete objects, others only signal that a cursor advanced, and some may be dropped or expire. Each connector needs a documented recovery read, renewal schedule, deduplication key, and gap strategy. Real-time UX should display last confirmed synchronization rather than infer freshness solely from a healthy webhook endpoint.

Track provider subscription health separately from customer delivery health
Publish known event gaps beside each released connector

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 a successful webhook response prove that the end user saw a message?+

No. It proves only that the configured customer endpoint acknowledged a DewEngine delivery attempt. Provider acceptance, recipient delivery, read state, and application presentation are different facts with separate evidence.

Should a consumer assume webhook events arrive exactly once and in order?+

No. The intended contract is retryable, at-least-once delivery. Consumers must deduplicate by event ID and handle ordering through resource versions or a current-state fetch where the provider contract permits one.

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 ↗