---
title: Architecture
description: 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.

```mermaid
flowchart LR
  Request[Application operation] --> Account[Authorized account reference]
  Account --> Route{Assigned backend instance}
  Route --> Direct[Direct platform adapter]
  Route --> Zernio[Zernio adapter]
  Route --> PostForMe[Post for Me adapter]
  Direct --> Platform[Selected platform]
  Zernio --> Platform
  PostForMe --> Platform
  Direct -. failure .-> Error[Structured outcome]
  Zernio -. failure .-> Error
  PostForMe -. failure .-> Error
```

## Account connection and ownership

The application owns tenant membership. The backend owns its connection and token lifecycle. A browser request cannot turn a display identifier into an authorized backend call.

```mermaid
sequenceDiagram
  participant User
  participant App as Application server
  participant Store as Tenant/account store
  participant Backend
  User->>App: Start or resume connection
  App->>Backend: Create provider connection/session
  Backend-->>App: Callback or connection event
  App->>Store: Save tenant membership + backend reference
  App-->>User: Show authorized account choice
  User->>App: Request operation for chosen account
  App->>Store: Check tenant membership and backend instance
  App->>Backend: Execute with server-held credentials
```

## Per-target publication lifecycle

One publication intent can fan out to several targets, but every delivery has its own lifecycle. `accepted` and `processing` remain pending.

```mermaid
flowchart TD
  Intent[Publication intent] --> Prepare[Local validation and preparation]
  Prepare --> Fanout{One delivery per target}
  Fanout --> A[Target A]
  Fanout --> B[Target B]
  A --> AState{Destination state}
  B --> BState{Destination state}
  AState -->|published + native ref| DoneA[Published A]
  AState -->|failed| FailedA[Failed A]
  AState -->|unknown or processing| ReconcileA[Reconcile A]
  BState -->|published + native ref| DoneB[Published B]
  BState -->|failed| FailedB[Failed B]
  BState -->|unknown or processing| ReconcileB[Reconcile B]
```

## 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.

```mermaid
sequenceDiagram
  participant Provider
  participant Endpoint as Webhook endpoint
  participant Verify as Raw-body verifier
  participant Events as Durable event store
  participant Worker
  Provider->>Endpoint: Signed event delivery
  Endpoint->>Verify: Raw body + provider headers
  Verify-->>Endpoint: Valid or reject
  Endpoint->>Events: Insert event idempotently
  Events-->>Endpoint: Accepted or duplicate
  Endpoint-->>Provider: Acknowledge after durable insert
  Worker->>Events: Claim pending event
  Worker->>Worker: Apply normalized event + reconcile state
```