> ## 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. # Connect Your Operation > Move from a local example to your business systems: choose data owners, check service access, map record IDs, and verify an operational outcome. After [Your First Operation](/guides/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 | Outcome | Start with | Have ready | First evidence | | ------------------------------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Answer customer questions | [ResponseCX](/quickstart) | Workspace, scoped key, support knowledge, intended channel | Saved agent configuration and a verified response in that channel | | Exchange Shopify orders and NetSuite inventory | [Sync](/guides/sync-shopify-to-netsuite) | Tenant key and both connectors configured, including mapping defaults | Healthy connectors, a completed sync job, and matching destination records | | Run an order workflow through retries and review | [Temporal Engine](/guides/temporal-first-durable-workflow) | Brand, scoped key, configured connectors, and workflow inputs | Readiness, returned workflow ID, and the observed final outcome | | Apply a refund policy before execution | [NSR](/guides/nsr-first-verified-decision) | Organization key, policy, trusted facts, and an executor for the approved action | Decision/proof, followed separately by the actual refund result | | Own commerce state inside your application | [Embedded engine](/stateset-icommerce/stateset-icommerce-quickstart) | Runtime, database path, and application code that supplies real data | Saved records read back through the same database | Use [brand onboarding](/stateset-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](/api-reference/introduction). 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. | Fact | Example owner | What your integration must preserve | | ------------------------------------- | ------------------------------------- | -------------------------------------------------------------------- | | Customer order and purchased items | Storefront or order-management system | Source order ID, quantities, currency, and item IDs | | Available inventory | Warehouse or inventory system | SKU, location, quantity meaning, and observation time | | Captured payment and completed refund | Payment provider | Transaction ID, amount, currency, and provider state | | Return receipt and disposition | Returns or warehouse system | Returned item ID, received quantity, and inspection result | | Customer conversation | Support system | Conversation ID, channel, and operational records referenced | | Authorization decision | Configured decision service | Policy context, supplied facts, decision ID, and verification result | 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: ```bash theme={null} curl --silent --show-error --fail-with-body --max-time 20 \ 'https://response.stateset.com/api/v1/workspace' \ --header "Authorization: Bearer ${RESPONSECX_API_KEY:?Set a ResponseCX key with agents:read}" ``` **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](/api-reference/responsecx/workspace-list). ### Sync connectors Set `STATESET_SYNC_API_KEY` and `STATESET_SYNC_TENANT_ID`, then run: ```bash theme={null} curl --silent --show-error --fail-with-body --max-time 20 \ "https://api.sync.stateset.com/v1/tenants/${STATESET_SYNC_TENANT_ID:?Set your Sync tenant ID}/integrations/health" \ --header "x-stateset-api-key: ${STATESET_SYNC_API_KEY:?Set your Sync tenant key}" ``` **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](/guides/sync-shopify-to-netsuite) 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: ```bash theme={null} curl --silent --show-error --fail-with-body --max-time 20 \ "https://api.workstream.stateset.com/v1/brands/${STATESET_TEMPORAL_BRAND_ID:?Set your Temporal brand UUID}/connectors/readiness" \ --header "x-api-key: ${STATESET_TEMPORAL_API_KEY:?Set your Temporal brand key}" ``` **Check:** `ready` is `true`, with the expected connectors present and healthy. A readiness result does not start a workflow. Continue through the [Temporal walkthrough](/guides/temporal-first-durable-workflow) 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](/guides/error-handling-best-practices). ## 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: ```text theme={null} Outcome: [one business result] Environment: [test or production; service and tenant/brand/database] Authoritative source: [system and fields it owns] Input records: [actual IDs and how they map across systems] Freshness requirement: [how current the facts must be] Allowed operations: [specific reads and writes for this task] Completion evidence: [record states and provider/job results to verify] Retry identity: [where the original request and replay key are stored] Unresolved outcome: [who owns reconciliation and how to report the blocker] ``` Start the agent with the relevant server and inspect its actual tool schemas. Use the [agent onboarding procedure](/getting-started-for-ai-agents) 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](/guides/sync-shopify-to-netsuite): 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: | Claimed outcome | Evidence needed | | ----------------- | ------------------------------------------------------------- | | Agent configured | Read-back of the saved configuration | | Customer answered | Observed message in the intended conversation/channel | | Stock reserved | Reservation or order identity and resulting availability | | Policy approved | Decision and the required verification result | | Refund completed | Provider outcome plus reconciled local state | | Workflow finished | Documented terminal state plus the resulting business records | The [integration test plan](/guides/comprehensive-testing-guide) 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](/support#report-an-api-problem) helps you collect a redacted reproduction. ## Continue by outcome * [First local operation](/guides/first-operation): practice against a database you can inspect. * [Customer support](/quickstart): create and verify a ResponseCX agent. * [Store and ERP sync](/guides/sync-shopify-to-netsuite): configure data exchange and inspect jobs. * [Durable automation](/guides/temporal-first-durable-workflow): start and follow an operational workflow. * [Verified decisions](/guides/nsr-first-verified-decision): evaluate policy before the executor acts.