What happens after a request arrives

HTTP lifecycle

The server applies a shared body cap and database-backed rate limits before routing. Host-aware root handling separates public, application, API, and docs behavior. Provider callbacks have dedicated verified routes. Remaining requests are passed to the web router, which resolves authentication, loads domain state, and renders HTML.

Errors are converted to bounded public responses. Structured observability records method, path, status, and duration without publishing secrets.

Callback lifecycle

sequenceDiagram
  participant P as Provider
  participant H as HTTP service
  participant D as PostgreSQL
  participant W as Durable worker
  participant S as Domain service
  P->>H: Signed callback
  H->>H: Verify and normalize
  H->>D: Insert inbox event
  D-->>H: Committed or duplicate
  H-->>P: HTTP 200
  W->>D: Claim event with lease
  W->>S: Process typed event
  S->>D: Commit state and outbox
  W->>D: Complete, retry, or dead-letter

The HTTP response does not wait for OpenAI planning or provider delivery. Duplicate provider event IDs converge on the existing inbox record.

Outbound command lifecycle

When a workflow selects outbox delivery, the domain transaction stores the command with a stable idempotency key. A worker claims it with a lease, revalidates sensitive finance or fulfilment state where required, calls the provider, then records success, retryable failure, reconciliation state, or a terminal dead letter.

Unknown outcomes are not treated as ordinary failures. Meta, courier, payout, refund, and payment paths preserve provider references and use status or callback evidence to converge without blind duplication.

Failure and recovery