> ## 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.

# Capabilities and tasks

> Activate the customer capability for a flow and complete only the work currently requested.

A capability tells you whether a customer can use a specific outcome, payment method, and direction. Open tasks tell you what must happen before that capability or a related resource can move forward.

```mermaid theme={null}
flowchart TD
  A["Discover supported capability"] --> B["Request capability"]
  B --> C{"Open tasks?"}
  C -->|"Yes"| D["Complete hosted actions or API answers"]
  D --> E["Refetch capability"]
  C -->|"No"| E
  E --> F{"Status ready?"}
  F -->|"No"| C
  F -->|"Yes"| G["Build the selected flow"]
```

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

## Discover supported capabilities

Read the customer's current options with [`GET /v3/customers/{customerId}/capabilities/supported`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-supported):

```bash theme={null}
curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/capabilities/supported" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"
```

Choose a response entry that matches the intended `directions`, `method`, and `accountType`. Continue only when `availability` is `available` or `beta` and `eligibility.eligible` is `true`. If `institutions` are returned, select only an ID from that response.

Store the selected `data[].id` as `CAPABILITY_ID`. Never copy a capability ID from another customer or environment.

## Request the capability

Request the selected option with [`POST /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id):

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

Use an explicit `institutions` array only when you need to select from IDs returned by the supported-capability response.

Store `data.status` as `CAPABILITY_STATUS`, `data.openTaskIds` as `OPEN_TASK_IDS`, and each `data.applications[].id` in `APPLICATION_IDS`.

## Complete current tasks

List tasks with [`GET /v3/customers/{customerId}/tasks`](/api-reference/tasks/list-customer-tasks), select IDs from `OPEN_TASK_IDS`, then read each current task with [`GET /v3/customers/{customerId}/tasks/{taskId}`](/api-reference/tasks/get-customer-task):

```bash theme={null}
curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/tasks/${TASK_ID}" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"
```

Use the latest `data.revision` and `data.requirements`. Refetch the task immediately before submitting if either may have changed.

### Hosted actions

When the task returns `verificationSessions` or `tosSessions`, store each session `id` and current `url`. Send the customer to the returned URL, then read the task again. These are task-scoped actions, not a separate customer-verification lifecycle.

### Upload documents

When a requirement requests a document, upload it with [`POST /v3/customers/{customerId}/documents`](/api-reference/documents/post-v3-customers-by-customer-id-documents):

```bash theme={null}
export DOCUMENT_PATH='/absolute/path/to/requested-document.pdf'

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/documents" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: customer-document-001" \
  --form "file=@${DOCUMENT_PATH}"
```

Store the returned `data.id` as `DOCUMENT_ID` before submitting the answer that references it.

### API answers

Submit one complete answer set for the current revision with [`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_API_KEY}" \
  --header "Idempotency-Key: task-submission-001" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "taskRevision": 3,
  "answers": [
    {
      "requirementId": "req_from_current_task",
      "answer": {
        "type": "text",
        "value": "Current answer"
      }
    }
  ]
}
JSON
```

Take every requirement ID and answer type from the latest task. If the API reports that the task changed, refetch it and rebuild the submission from the new revision.

## Continue when the capability is ready

Read the capability again with [`GET /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id):

```bash theme={null}
curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/capabilities/${CAPABILITY_ID}" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"
```

Replace the stored status and task IDs with the latest response. Continue only when the current capability status permits the account, quote, or transfer you intend to create.

Next, choose the matching journey in [Common flows](/integration/common-flows).


## Related topics

- [Preview capability tasks](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-tasks-preview.md)
- [Sandbox testing](/integration/sandbox.md)
- [KYB workflow](/knowledge-base/business-onboarding/kyb-workflow.md)
- [Cancel capability](/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id-cancel.md)
- [Create capability](/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id.md)