Skip to main content
This tab is different from the others. There is no StateSet host behind it: the chat widget runs in your customer’s browser and calls your backend. These pages are the contract that backend has to meet. Implement POST /api/chat and the widget works; implement the rest as you need threads, catalog cards, cart actions, and analytics.
Nothing here is served by response.stateset.com. The widget can also be wired to a ResponseCX agent through the ResponseCX API; that is a different surface with its own tab.

Two surfaces

Send a message

The one endpoint the widget needs. Non-streaming JSON, or SSE when stream: true.

Threads

Create, read, update, delete, and post into a persistent thread.

Analytics events

Every user, assistant, commerce and lifecycle action, with a funnel stage on outcomes.

Admin API

Sites, draft and published config, install snippets, versions and rollback.

Authentication

Streaming

When the request carries stream: true, answer with Content-Type: text/event-stream and one JSON object per data: line. The widget concatenates every text_delta into the reply and renders the other events as it receives them; end with data: [DONE].

Errors

Any non-2xx response is { "error": "<message>", "type": "<optional code>" }. The widget shows error inline in the conversation and calls the onError prop with the same object. Leave GET /api/threads/{id} out of your rate limiter — the widget polls it to refresh a thread.

Not in this reference

The repository also ships integration flows built for individual customers — order lookup against a specific store, review-platform attachments, subscription changes, promotional offers. They are implementation details of one backend rather than the contract, and are not documented here.