Capabilities and tasks

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.

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:

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.

Pooled vs named account types

Bank capabilities come in two variants, encoded as the accountType field and the capability ID suffix (for example ach_pooled, wire_named):

pooled: shared Swipelux bank account. Each pay-in uses a unique reference to route funds. Pick this for one-time transfers.
named: dedicated bank details for the customer (virtual IBAN, dedicated ACH account). Reusable and shareable with any payer. Required for issued bank accounts.

Default to pooled. Use named only when the customer needs reusable bank details. Check the supported response for which variants are available.

Request the capability

Request the selected option with POST /v3/customers/{customerId}/capabilities/{capabilityId}:

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, select IDs from OPEN_TASK_IDS, then read each current task with GET /v3/customers/{customerId}/tasks/{taskId}:

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:

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:

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}:

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.

Get started

Onboard customers

Build money flows

Launch

Capabilities and tasks

Discover supported capabilities

Pooled vs named account types

Request the capability

Complete current tasks

Hosted actions

Upload documents

API answers

Continue when the capability is ready

​Discover supported capabilities

​Pooled vs named account types

​Request the capability

​Complete current tasks

​Hosted actions

​Upload documents

​API answers

​Continue when the capability is ready

Discover supported capabilities

Pooled vs named account types

Request the capability

Complete current tasks

Hosted actions

Upload documents

API answers

Continue when the capability is ready