Skip to content
SarvexDocs
Esc
↑↓navigate↵open⌘Jpreview

Subscribe to live journey updates for the store

WebSocket upgrade (RFC 6455) — modelled here for discoverability, not a standard HTTP operation. The client authenticates by sending the bearer token as a WebSocket subprotocol (Sec-WebSocket-Protocol: bearer, <token>) rather than an Authorization header, since browsers cannot set custom headers on the handshake request; the server echoes back bearer as the negotiated subprotocol. Ownership of store_id is verified against the resolved principal before the upgrade completes, exactly as on GET /stores/{store_id}.

On every server-side journey transition (see control.journey.updated in sarvex-v1-syncing-plane-async.yaml) the server pushes one journey_stream_message text frame with type: journey.updated. The payload is a thin signal, not the full journey record — the client is expected to re-fetch GET /stores/{store_id}/journey on receipt (same “thin event, fat pull” convention the plugin uses for change signalling).

The same connection also carries type: task.updated frames whenever a task belonging to this store changes (see control.task.updated in sarvex-v1-syncing-plane-async.yaml), scoped to stores that already have a journey record. The client is expected to re-fetch the task via GET /tasks/{id} (task_id on the frame) rather than treat the frame as authoritative.

It also carries type: orders.updated frames whenever a new order is recorded for this store (see sync.order.created in sarvex-v1-syncing-plane-async.yaml) — the Path’s “Agent orders this week” tile re-reads GET /orders on receipt.

No message frame should be treated as authoritative on its own, and a client that never connects (or whose connection drops) must still see current state on next page load via the GET endpoints above — the stream is a freshness optimization, not a dependency.

GET/stores/{store_id}/journey/stream
Authorization
AuthorizationBearer token (JWT) · headerrequired

JWT issued by the external IdP via the OAuth 2.0 authorization-code flow (Kinde in production; a simulator in test). The client obtains it and sends it as a Bearer token on every authenticated call. Sarvex's services verify it — issuer, audience, signature (IdP JWKS), expiry — and read identity and tenant from its claims. Sarvex does not issue or revoke these tokens. merchant_id/store_id are read from the verified claims (and the merchant→store mapping), never from the URL. The operator scope is required for /operator/*. Operators acting on a specific merchant pass the X-Operate-As header, which is recorded in the audit log.

Path parameters
store_idstringrequired

A store the caller's merchant owns. Authorized server-side against the principal; not a free-form tenant selector.

Responses
101

Switching Protocols — connection upgraded to a WebSocket.

401

Missing or invalid credentials.

errorobjectrequired
Show properties
codestringrequired
messagestringrequired
detailsobject | null
404

Resource not found within the caller's tenant.

errorobjectrequired
Show properties
codestringrequired
messagestringrequired
detailsobject | null
Try it
Server
Authorization
Parameters
Request
curl -X GET "https://api.sarvex.example.com/v1/stores/string/journey/stream" \
  -H "Authorization: Bearer YOUR_TOKEN"
Response
Switching Protocols — connection upgraded to a WebSocket.