Skip to main content
This reference documents the Rust stateset-http REST/SSE layer. It is separate from native embedding, MCP Streamable HTTP and the messaging gateway. Choose your deployed interface before transferring field names, credentials or retry rules between them.
Reviewed October 20, 2026. 475 operations across 64 tags were exported offline from stateset-icommerce source b8597997 plus the reviewed working tree. Workspace release: 1.39.0; OpenAPI metadata version: 1.0.4. The contract includes in-progress invoice/payment fields and does not establish published native-binary behavior or hosted availability. Handler-backed corrections are retained in the spec overlay.

Deployment and authentication

The generated examples use https://api.stateset.com/api/v1 as the contract address. Obtain your actual provisioned host and credentials first; the dated host report does not establish a public Commerce deployment. For local commerce without a hosted key, use the native quickstart. The embedded Rust HTTP server defaults to loopback with bearer authentication. Retrieve an auto-generated token through the builder API before serving. Public binds require explicit operator configuration for authentication, authorization and request limiting. Verify a private route and negative access cases; health is not an authentication check. See HTTP access controls.

Start with a workflow

The new source routes include inventory reservation lookup/expiry/sweeps; shipment metadata, manifest edits and cancellation; return changes/rejection/completion; tax exemptions; x402 intent lifecycle; message/credit inspection; lot genealogy; and kernel audit/checkpoint verification. Their presence does not configure a provider or qualify an external workflow.

Inventory and warehouse

Reservations, warehouse locations, receiving and fulfillment are separate state machines. The source adds explicit reservation lookup, confirmation/release, expiry and sweeps. Use stock fulfillment for physical posting and system ownership when integrating standalone WMS/TMS systems.

Financials

Payments, invoices, AP/AR, general ledger, assets and revenue recognition have their own methods and transitions. A commerce record does not automatically prove a journal was posted or a provider settled. Start with finance and verify resulting records and external outcomes separately.

Manufacturing and quality

Work orders, BOMs, batches, quality checks and lot/serial traceability are documented source domains. Lot genealogy adds related evidence; it is not a physical quality acceptance result. Use the traceability workflow with actual identifiers.

Preserve original request identity

HTTP retry receipts persist in the selected store. Required-key creates return 428 without Idempotency-Key; changed fingerprints return 422. A pending reserved key returns 409 and never expires automatically, because the business operation may already have committed. Authorization precedes replay. Keep original route, tenant, body and key before dispatch; use operator reconciliation rather than another key after uncertainty. Native kernel receipts, provider retry keys and HTTP receipts are different contracts. A successful local payment, shipment status or invoice does not prove settlement, physical stock consumption, carrier custody or a posted ERP object. Verify each actual outcome.

Scope and coverage

The spec covers core commerce, inventory/warehouse, fulfillment, manufacturing/procurement, finance, engagement, integrations and protocol operations. Methods not registered in this OpenAPI export are not inferred from native accessors. Feature/backend support, policy, expected versions and deployed configuration remain authoritative. See bindings, MCP, and backup/recovery.
Last modified on October 20, 2026