> ## Documentation Index
> Fetch the complete documentation index at: https://docs.swipelux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sandbox testing

> Control capability, task, wallet, and transfer outcomes in the Swipelux sandbox environment while building and regression-testing your integration.

Sandbox uses the same API host as production. A sandbox API key selects the test environment, where helpers simulate outcomes without moving real funds.

Keep the key on your backend. Sandbox helpers do not replace production compliance or onboarding.

Use [Errors and retries](/integration/errors) to test how your integration handles validation, state, and retryable platform failures returned by sandbox operations.

```bash theme={null}
export API_BASE='https://platform.swipelux.com'
export SWIPELUX_SANDBOX_API_KEY='replace-with-your-sandbox-key'
```

## Test capability readiness

After requesting a capability, set its sandbox status with [`POST /v3/sandbox/customers/{customerId}/capabilities/{capabilityId}/status`](/api-reference/sandbox/post-v3-sandbox-customers-by-customer-id-capabilities-by-capability-id-status):

```bash theme={null}
curl --request POST \
  "${API_BASE}/v3/sandbox/customers/${CUSTOMER_ID}/capabilities/${CAPABILITY_ID}/status" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"status":"ready"}'
```

Refetch the capability after using the helper. Treat its current `status` and `openTaskIds` as the result your product must handle.

## Test an open task

Create a capability-scoped task with [`POST /v3/sandbox/tasks`](/api-reference/sandbox/post-v3-sandbox-tasks):

```bash theme={null}
curl --request POST \
  "${API_BASE}/v3/sandbox/tasks" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data @- <<JSON
{
  "scope": {
    "type": "capability",
    "customerId": "${CUSTOMER_ID}",
    "capabilityId": "${CAPABILITY_ID}"
  },
  "items": [
    {
      "type": "explanation",
      "request": "Explain the source of funds."
    }
  ]
}
JSON
```

Store `data.id` as `TASK_ID`, `data.revision` as `TASK_REVISION`, and the current `data.requirements[0].id` as `REQUIREMENT_ID`. Submit the answer through [`POST /v3/customers/{customerId}/tasks/{taskId}/submissions`](/api-reference/task-submissions/create-customer-task-submission):

```bash theme={null}
curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/tasks/${TASK_ID}/submissions" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Idempotency-Key: sandbox-task-submission-001" \
  --header "Content-Type: application/json" \
  --data @- <<JSON
{
  "taskRevision": ${TASK_REVISION},
  "answers": [
    {
      "requirementId": "${REQUIREMENT_ID}",
      "answer": {
        "type": "text",
        "value": "Sandbox requirement completed."
      }
    }
  ]
}
JSON
```

Then accept or reject the current submission with [`POST /v3/sandbox/tasks/{taskId}/review`](/api-reference/sandbox/post-v3-sandbox-tasks-by-task-id-review):

```bash theme={null}
curl --request POST \
  "${API_BASE}/v3/sandbox/tasks/${TASK_ID}/review" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"outcome":"accepted"}'
```

Use [Capabilities and tasks](/integration/onboarding/capabilities-and-requirements) for the production task-completion pattern.

## Fund a sandbox wallet

Credit an issued wallet with [`POST /v3/sandbox/accounts/{accountId}/topup`](/api-reference/sandbox/post-v3-sandbox-accounts-by-account-id-topup):

```bash theme={null}
curl --request POST \
  "${API_BASE}/v3/sandbox/accounts/${ACCOUNT_ID}/topup" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"amount":"250.00","currency":"USDC"}'
```

Store the returned `data.id` as `TRANSFER_ID` when you want to inspect the simulated funding transfer.

The topup id is a transfer id. Fetch it through [`GET /v3/transfers/{transferId}`](/api-reference/money-movement/get-v3-transfers-by-transfer-id) or list it through [`GET /v3/transfers`](/api-reference/money-movement/get-v3-transfers) to exercise your inbound-deposit code path against sandbox topups. The transfer projection is a completed inbound stablecoin deposit with `origin: "inbound_deposit"`, `method: "stablecoin_transfers"`, and `direction: "stablecoin_move"`, and it is returned by the matching `accountId`, `origin`, `method`, and `direction` list filters.

## Complete or fail a transfer

Set the outcome with [`POST /v3/sandbox/transfers/{transferId}/state`](/api-reference/sandbox/post-v3-sandbox-transfers-by-transfer-id-state):

<Tabs>
  <Tab title="Complete">
    ```bash theme={null}
    curl --request POST \
      "${API_BASE}/v3/sandbox/transfers/${TRANSFER_ID}/state" \
      --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
      --header "Content-Type: application/json" \
      --data '{"state":"completed"}'
    ```
  </Tab>

  <Tab title="Fail">
    ```bash theme={null}
    curl --request POST \
      "${API_BASE}/v3/sandbox/transfers/${TRANSFER_ID}/state" \
      --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
      --header "Content-Type: application/json" \
      --data @- <<'JSON'
    {
      "state": "failed",
      "stateDetail": {
        "code": "sandbox_review",
        "message": "Sandbox transfer failed."
      }
    }
    JSON
    ```
  </Tab>
</Tabs>

Next, run a [pay-in](/integration/receive-funds), [payout](/integration/send-funds), or [issued bank account](/integration/issue-bank-account) flow in sandbox.


## Related topics

- [Errors and retries](/integration/errors.md)
- [Authentication](/integration/authentication.md)
- [Create sandbox task](/api-reference/sandbox/post-v3-sandbox-tasks.md)
- [Credit a sandbox account](/api-reference/sandbox/post-v3-sandbox-accounts-by-account-id-topup.md)
- [Review sandbox task submission](/api-reference/sandbox/post-v3-sandbox-tasks-by-task-id-review.md)