> ## Documentation Index > Fetch the complete documentation index at: https://docs.stateset.com/llms.txt > Use this file to discover all available pages before exploring further. # Temporal Engine API > Start, signal and observe long-running commerce workflows, and manage the brands that run them — 170 endpoints on api.workstream.stateset.com, generated from the engine's spec. 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. | | | | -------- | ---------------------------------------------------------------------------- | | Base URL | `https://api.workstream.stateset.com` | | Auth | `Authorization: Bearer ` or `X-API-Key: ` — brand-scoped or global | | Spec | `docs/openapi.yaml` in the engine repository, version 0.1.2 | 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. | Family | What it runs | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | `response-automation-v2` | The primary workflow: a customer conversation, resolved through the function-calling loop with a review gate | | `active-horizon-agent` | An agent working continuously in bounded turns, for up to 24 hours | | `return-lifecycle` | A return from request through receipt, inspection and refund | | `warranty-automation-v2` | A warranty claim end to end | | `subscription-retention` | A cancellation intent, worked toward retention before it is honoured | | `payment-recovery` | A failed payment, retried and escalated | | `support-followup` | A follow-up on a conversation after a delay | | `delivery-exception-callback` | A carrier exception, turned into proactive outreach | | `cohort-fanout` | One action applied across a cohort, with per-member workflows | | `sandbox-agent-loop` | An agent session inside a sandbox, with its own outcomes and SLOs | | `connector` | A connector sync or health check as a workflow | | `order-fulfillment`, `wholesale-order` | Order and wholesale-order lifecycles | Start with [`POST /v1/workflows/response-automation-v2/start`](/api-reference/temporal/workflows/v1-workflows-response-automation-v2-start-create); the [workflow page](/next-temporal/workflow) 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](/next-temporal/mcp-connector) exposes the same fifteen operations to an agent. ## Related * [Temporal Engine overview](/next-temporal/overview) — what the engine is for * [Workflow anatomy](/next-temporal/workflow) — phases, signals, the review gate * [Control plane](/next-temporal/control-plane) — multi-tenancy, outbox, DLQ, migration * [Operations](/next-temporal/operations) and [runbooks](/next-temporal/runbooks)