Skip to main content
After Your First Operation, you have a working local database and an agent that can inspect known records. To use your own business data, choose one outcome and connect the systems needed to produce it. This guide is an integration plan with read-only connection checks. It does not import data or enable automation by itself. Complete the linked service setup for the path you choose.

​
1. Pick an outcome and its starting point

Use brand onboarding when you need StateSet service provisioning. Provisioning a brand does not establish that your store, ERP, or payment-provider records have been imported and reconciled. Follow the connector setup for the operation you selected. For service hosts, credential sources, and headers, use the API directory. The local embedded example does not require a hosted commerce endpoint.

​
2. Decide which system owns each fact

Write down the authoritative source before configuring an agent to act on a field. The table below is an illustrative design, not a default StateSet configuration. Replace the owners with those used by your business. For each field you copy, specify the direction of updates and what happens when sources disagree. A cached stock value and a live reservation are different observations. Choose a freshness requirement for the action, then recheck state at the point where it matters.

​
3. Verify access before starting work

Run only the check for your chosen path. Use Bash and curl 7.76+. Set the named variables in the same shell using your actual service credentials and tenant or brand ID; never substitute an ID from a documentation response. These requests inspect workspace or connector state. They do not start a sync or fulfillment workflow. Their responses establish access and readiness, not completion of your business task.

​
ResponseCX workspace

Set RESPONSECX_API_KEY to a key with agents:read, then run:
Check: HTTP 200 with agent_count, agents, and next_action. Inspect the agents you expect to see. A successful read does not establish write scope or that a customer channel is connected. See the workspace contract.

​
Sync connectors

Set STATESET_SYNC_API_KEY and STATESET_SYNC_TENANT_ID, then run:
Check: the response’s integration results include the connectors your selected workflow requires, and those connectors are healthy. Missing or disabled connectors are not a passing result simply because the request returned 200. The Sync walkthrough explains configuration prerequisites, response envelopes, and the later job checks.

​
Temporal connector readiness

Set STATESET_TEMPORAL_API_KEY and STATESET_TEMPORAL_BRAND_ID, then run:
Check: ready is true, with the expected connectors present and healthy. A readiness result does not start a workflow. Continue through the Temporal walkthrough with actual brand and order IDs. For 401 or 403, check the selected service, header, scope, and organization access. For a missing record or connector, confirm the tenant or brand before creating anything. For timeouts, use the error-handling guide.

​
4. Keep identities separate across systems

An order number displayed to a customer is not necessarily the ID accepted by an API. A Shopify order ID, a Sync record ID, and an embedded order UUID are also different identities. Keep an explicit mapping in your integration, using only fields that each destination supports. A useful mapping records the source system and ID, destination system and returned ID, and the workflow or job that created the relationship. If the API has no place for your mapping, persist it in your own integration store. For a retryable operation, also retain the original request and its stable retry identity. A source record ID is not automatically an idempotency key. A local payment key does not configure a provider’s replay behavior. Check the contract of each operation you execute.

​
5. Give a person or agent the same task brief

This is a planning template, not an API payload or executable configuration. Replace the bracketed values before handing it to an operator or agent:
Start the agent with the relevant server and inspect its actual tool schemas. Use the agent onboarding procedure to select the connection and verify its first read. Credentials belong in the host or server configuration, not the brief.

​
6. Follow one record through to the outcome

For a Shopify-to-NetSuite order sync, verify the steps described in the Sync walkthrough:
  1. Confirm both connectors are configured and healthy.
  2. Start a bounded source sync and save the returned job ID.
  3. Inspect the job’s final result, including failed or skipped records.
  4. Find the intended order using its source identity.
  5. Run the destination step and inspect its job result.
  6. Compare the destination record and its identifier with the source order and mapping.
A 202 means work was accepted. A successful job response is still something to inspect for per-record results. An HTTP response alone does not prove that the intended destination record exists with the right fields. For other operations, choose equivalent evidence: The integration test plan turns these checks into test boundaries. Add a replay test and an interrupted-response scenario before relying on automatic retries for your operation.

​
Keep a completion record

Capture the run’s environment, input IDs, returned job/workflow/decision IDs, observed final states, and any unresolved records. For reads, state when the facts were observed. For writes, record both the attempted action and the evidence that it completed. If one system completed and another failed, report that partial outcome explicitly. Reconcile it through the original IDs before starting another write. The support checklist helps you collect a redacted reproduction.

​
Continue by outcome

Last modified on September 20, 2026