The canonical mutation surface is Most's /v3 HTTP API with bearer authentication backed by finite Skarbiec capabilities. Events flow back out as HMAC-signed webhooks with bounded retry; attachments use independently expiring signed URLs; location reads answer from what the bridge recorded.
HTTP API — canonical mutation, account-adoption, location and webhook-subscription interface: `GET /v3/accounts`, `POST /v3/accounts/messages-app/import`, `POST /v3/chats`, message, reaction, typing, voice, edit, unsend, `GET /v3/chats/{chat_id}/location`, `GET /v3/chats/{chat_id}/location/history`, and subscription routes.
Developer first use — authenticated `GET /v3/onboarding/first-use`, also discoverable as `most-cli onboarding` and MCP tool `most_onboarding_first_use`; its primary action is `most-cli adopt-messages`, and completion requires accepted imported history or an actual `message.delivered` / `message.read` provider receipt.
Health API — `GET /healthz`, unauthenticated and secret-free; exposes build identity and active composition.
Attachment API — expiring HMAC-signed `GET /v3/attachments/{id}?exp=…&sig=…`.
Worker protocol — `/internal/worker/connect`, protected by mTLS and a dedicated bearer capability; the wire contract lives in docs/remote_worker_protocol.md.
A new conversation creates durable chat and message records, dispatches through one eligible transport worker, and returns stable identifiers and status. Authentication, validation, and worker selection happen before backend dispatch.
A continued conversation uses the Most `chat_id` and keeps the same conversation identity: the chat is durably assigned to a transport and, when pooled, to one physical worker.
A saved chat is not proof of message acceptance. HTTP 200 can contain delivery_status=failed. Inspect the `message` receipt of a new conversation, or the returned message of a continued one, and its optional error. Most Desktop and the messaging examples reject failed receipts while retaining the chat identifier.
Send endpoints currently have no idempotency key, so callers must not automatically retry an ambiguous provider outcome. Once an upstream provider has accepted a request, final delivery is the provider's domain; Most reports acceptance and subsequent provider receipts.
When a transport observes an inbound message, a status change or a location fact and a matching webhook subscription exists, Most normalizes and persists the event, then delivers an HMAC-signed webhook with bounded retry. The receiver can verify the raw body and timestamp; attachment access uses independently expiring signed URLs.
Subscribable events: `message.received`, `message.delivered`, `message.read`, `message.failed`, `location.received`, `location.sharing.started`, `location.sharing.stopped`. Every delivery carries exactly three signature headers: `X-Webhook-Event`, `X-Webhook-Timestamp`, `X-Webhook-Signature`, plus `X-Webhook-Subscription-ID`.
4xx identifies caller or authorization errors; a missing chat returns 404; 401 means a missing or invalid bearer (`AUTH_BYPASS=1` is local development only).
A failed SMS receipt reports the actual integration URL, operation, HTTP status and bounded error code when supplied. HTTP 401 inside that receipt refers to wisent-integrations rejecting Most, not the caller's authentication to Most. Missing provider identifiers and invalid JSON are failures, not queued messages.
501 means no executable capability: the selected composition has no transport for the requested service. Do not enable an unavailable transport merely to suppress the error.
503 means a configured dependency or the chat's pinned worker is unavailable — restore the assigned worker; there is no cross-worker failover of an existing chat.