Architecture

Trace backend routing, account grants, per-target publication outcomes, and durable webhook acceptance in one flow.

These diagrams show the boundaries an application must keep explicit. The diagrams describe the contract; an adapter’s capability manifest and evidence determine which operations are available for a particular backend and platform.

Backend routing

An account reference selects one configured backend instance before dispatch. A failure does not authorize a different destination or backend.

Account connection and ownership

The application owns tenant membership. The backend owns its connection and token lifecycle. Discovered accounts are only candidates: a tenant grant exists only after the user picks accounts and select stores them. A browser request cannot turn a display identifier into an authorized backend call.

Per-target publication lifecycle

One publication intent can fan out to several targets, but every delivery has its own outcome. scheduled, accepted, and processing are pending and need later reconciliation. published always carries a PlatformPostRef in post; the provider-native identifiers inside it are optional.

The publication status summarizes the targets. It is complete when every target published, pending when every target is pending, and partial for any other mix, including published plus processing. Read each target’s state rather than the summary.

Durable webhook acceptance

Verify the backend’s actual signature or shared-secret mechanism on the raw body before parsing. Persist a deduplication key before acknowledging so retries are safe.