StateSet API Docs

StateSet’s Rust engines give your application and AI agents two complementary capabilities: operate commerce records and coordinate work across systems over time. MCP exposes selected operations as tools your assistant can discover and call. You do not need to write Rust to start. Use the embedded engine through a supported language binding, configure hosted workflows in Response, or connect an assistant to the appropriate MCP server.

Choose the engine for the job

System	What it does	Where it runs	Start here
iCommerce embedded engine	Orders, stock, payments, returns, procurement, production, and other commerce records	In your application’s process, with the selected database backend	Local order and stock example
Temporal workflow engine / Workstream	Coordinates provider calls, model generation, review, dispatch, and durable execution	A deployed API/control plane and workers backed by Temporal; control-plane records use PostgreSQL	Helpdesk workflow trial
ResponseCX	Builds and tests support agents, knowledge, rules, and customer-facing experiences	The Response application and its services	First support agent
MCP servers	Expose the permitted operations of these systems to an external assistant	Local process or remote HTTP endpoint, depending on the server	MCP management walkthrough

ResponseCX and Workstream are different management surfaces. An agent created in Response is not automatically an active-horizon workflow agent, and a local commerce database is not automatically connected to your hosted brand.

What you can build with the commerce engine

The linked examples execute against @stateset/embedded 1.35.1, the Node binding to the native engine. Their results establish the behavior described here; other bindings and versions may expose different methods.

Operation	What the example verifies	What you integrate separately
Create an order	Stock-aware creation, reservation, insufficient-stock rejection, and cancellation	Storefront/channel synchronization and payment processing
Manage inventory	Stock quantities, adjustments, and reservations	Warehouse scans, location processes, and external stock ownership
Record payment and refund state	Replay identity and balance guards	The actual payment provider and settlement outcome
Process a return	Return lifecycle and completion requirements	Carrier labels, physical inspection, disposition, and refunds
Approve a purchase order	Supplier identity and approval transitions	Supplier delivery, acknowledgements, and receiving
Receive an inbound shipment	Partial receipt and quantity/cancellation guards	Stock posting and put-away
Track a shipment	Tracking and shipment-state records	Carrier custody, order fulfillment, and inventory consumption
Record production	BOM definition and cumulative batch progress	Material consumption, finished-goods posting, and quality evidence
Resolve a warranty claim	Claim approval, completion, and denial	Replacement orders, repair work, refunds, and customer communication

A completed record is evidence about that record. For example, receiving goods does not make inventory sellable unless the stock-posting process also completed. Preserve related IDs and verify each outcome when combining these operations.

Your first commerce task through MCP

Run Your First Operation to create a persistent local database and its MCP configuration. Then ask your assistant to read the generated order ID and stock SKU. The guide supplies actual identifiers, so the assistant can compare tool results with your independent inspection program. The iCommerce MCP server uses that database. It does not gain access to Shopify, Response, or Workstream merely because those services also expose MCP. Configure the source of truth and integration explicitly before using it for real operations. For native Rust integration and other bindings, use the embedded engine guide and binding reference. Check the chosen binding’s actual surface before translating a Node example into Rust or another language.

What you can build with the workflow engine

The Rust workflow engine separates orchestration from activities that call external services. It provides an API, a control plane for brands/configuration/connectors, and workers that execute workflows through Temporal. A customer-support workflow can fetch a ticket, evaluate routing and escalation rules, gather context, generate a response, wait for configured review, and dispatch through a provider. The source also includes workflow families for returns, warranties, subscription retention, payment recovery, support follow-up, delivery exceptions, and connector work. Inspect each family’s contract and deployment prerequisites; they do not all share one request schema. Start with the workflow API walkthrough or the workflow reference, then use the matching endpoint reference for the operation you select.

Durable execution is not a guarantee that an external action happens exactly once. An activity can be retried after an uncertain response. Provider idempotency, stable request identities, and reconciliation still matter for messages, orders, refunds, and other effects.

Long-running agents

Workstream’s start_agent tool starts an active-horizon agent backed by Temporal and an isolated sandbox. It returns a workflow ID that can be inspected after the initiating assistant conversation closes. get_agent_status reports progress, evidence, budgets, and approval needs. Supply the required task, duration, turn/failure, sandbox, and budget bounds using the current start schema. Do not equate a durable agent with unlimited execution or permission to take any action. See active-horizon agents.

Scheduled operations

list_scheduled_jobs inspects a brand’s schedules, and create_scheduled_job configures a supported recurring workflow. A schedule is a future source of runs, so review its target, frequency, timezone, scope, and possible customer effects before enabling it. Inspect the actual runs and outcomes after scheduling; schedule creation alone proves no work completed.

Use MCP to inspect, operate, and improve

Task	Server and starting tools	Evidence to retain
Understand the support workspace	Response: `describe_workspace`, `describe_vocabulary`	Agent IDs, configuration gaps, available templates
Create and test a support agent	Response: `provision_agent`, `get_agent`, `test_agent`	Saved settings and observed test answers
Turn a correction into a test	Response: `create_eval`, `run_eval`	Evaluation ID and grading result, including unavailable grading
Launch a workflow trial	Workstream: `run_onboarding_accelerator`, status/report reads	Per-step results and a dry-run workflow ID
Diagnose operational friction	Workstream: `get_brand_scorecard`, `get_improvement_breakdown`, run reads	Representative failures, skips, and escalations
Propose a config improvement	Workstream: `propose_config_patch`, `validate_config`, evaluation tools	Diff, current version, and evaluation evidence
Follow a durable agent	Workstream: `get_agent_status`	Workflow ID, progress, budget, and unresolved approvals

These are starting points, not a fixed catalogue. Credentials, scopes, profiles, and deployment versions determine the tools your connection exposes. Use tools/list, inspect input schemas, and verify results in the same tenant and data source.

Combine the systems around one business task

For an order-status request, a possible integration is:

Response or a helpdesk webhook captures the question.
The workflow obtains the order identity and reads the authoritative commerce system.
A model drafts an answer using the actual order/tracking result and approved policy.
The configured review process approves or escalates the draft.
The channel integration dispatches the reply and records its outcome.

This is an integration design, not an automatically connected demo. The commerce system might be your embedded deployment or an external store. Choose one authority for the task and map its order IDs to the workflow and conversation. Use Connect Your Operation for that mapping. Ask your assistant to plan the operation before enabling it:

Map an order-status workflow for my workspace. Inspect the available StateSet
MCP tools and configured systems without making changes. Identify the source
of order truth, the customer channel, the workflow brand, and the review owner.
Show which steps are already supported and which require a connector or service.
Propose the smallest trial with a concrete question, record IDs, expected result,
and verification steps. Do not create records, switch routing, or send replies.

Success: a plan tied to actual tools and systems, followed by a trial whose records and outcomes your team can verify. Expand only after that first operation works.

Next steps

Operate a durable agent: launch an approved task, inspect progress, and control its execution.
Platform onboarding: sign up and reach your first useful answer.
MCP server directory: choose the connection for the task.
Your first week: review live outcomes and measure improvement.

Get started

Build your first integration

Operate and improve

Resources and support

Platform

Using the APIs

StateSet Response

StateSet ResponseCX

Temporal Engine

StateSet iCommerce Engine

StateSet iCommerce EDI Engine

StateSet Mail

StateSet iCommerce Voice Engine

StateSet iCommerce NSR Engine

AI Agents

StateSet Agents

StateSet iCommerce Sandbox Engine

StateSet ACP

StateSet UCP

StateSet ICP

StateSet Sequencer

StateSet Set L2

StateSet Cloud

Apps & Consoles

Tools

Build Operations with Rust Engines & MCP

Choose the engine for the job

What you can build with the commerce engine

Your first commerce task through MCP

What you can build with the workflow engine

Long-running agents

Scheduled operations

Use MCP to inspect, operate, and improve

Combine the systems around one business task

Next steps

​Choose the engine for the job

​What you can build with the commerce engine

​Your first commerce task through MCP

​What you can build with the workflow engine

​Long-running agents

​Scheduled operations

​Use MCP to inspect, operate, and improve

​Combine the systems around one business task

​Next steps

Choose the engine for the job

What you can build with the commerce engine

Your first commerce task through MCP

What you can build with the workflow engine

Long-running agents

Scheduled operations

Use MCP to inspect, operate, and improve

Combine the systems around one business task

Next steps