Skip to main content
The Temporal Engine runs StateSet’s long-running workflows: a customer conversation that resolves over days, a return that moves through receipt and refund, an agent that keeps working a queue for up to 24 hours. This API starts those workflows, signals them, reads their status, and manages the brands and policies that govern how they behave.
This is the surface an API key can call — 170 of the engine’s 208 operations. Not listed: the 26 inbound webhook receivers (Shopify, Zendesk and others POST to those; you register the URL on the platform side and the engine verifies the signature), and the WorkOS console session endpoints. A brand-scoped key covers everything except the Fleet group, which needs a global credential and refuses a brand key with Operation requires global credential scope.

​
The workflows

Every workflow family has a /start, a /{id}/status, and — where the workflow supports it — review and cancel signals. Start with POST /v1/workflows/response-automation-v2/start; the workflow page explains the phases and the review gate it runs through.

​
Brands are the unit of configuration

A brand carries the deterministic config, connectors, policies and workflow bindings that every workflow for that tenant reads. The Brands group is the largest for that reason: validate a config before applying it, read the scorecard that says how the brand is performing, dry-run a change against logged decisions, and only then activate.
Change config through propose_config_patch → validate_config → apply_config, never by editing in place. Every applied version is kept, and list_config_versions is the audit trail. The MCP connector exposes the same fifteen operations to an agent.