Capabilities और tasks

export API_BASE='https://platform.swipelux.com'
export SWIPELUX_API_KEY='replace-with-your-api-key'

​

समर्थित capabilities खोजें

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

{
  "institutions": [
    {
      "id": "jpmorgan",
      "name": "JPMorgan Chase",
      "bic": "CHASUS33",
      "logoUrl": "https://wallet.swipelux.com/bank-logos/jpmorgan.png",
      "countries": ["US"],
      "isDefault": true
    }
  ]
}

​

Pooled बनाम named account types

• pooled: साझा Swipelux bank account। Funds को route करने के लिए प्रत्येक pay-in एक unique reference का उपयोग करता है। एक-बार के transfers के लिए इसे चुनें।
• named: customer के लिए dedicated bank details (virtual IBAN, dedicated ACH account)। पुन: उपयोग करने योग्य और किसी भी payer के साथ साझा करने योग्य। Issued bank accounts के लिए आवश्यक।

​

Capability का अनुरोध करें

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 '{}'

​

प्रति bank साझा applications

• एक approval कई capabilities को cover कर सकता है। उदाहरण के लिए, एक bank पर approved case ACH और wire दोनों capabilities को ready बना सकता है।
• बाद का कोई request जो किसी मौजूदा case से मेल खाता है, उसी का पुन: उपयोग करता है। Swipelux कोई दूसरा application नहीं खोलता और कोई duplicate tasks नहीं जोड़ता।
• अलग-अलग banks पर cases स्वतंत्र होते हैं। एक bank पर rejection किसी दूसरे bank के case को प्रभावित नहीं करता।

• 201 का अर्थ है कि request ने एक नया application case खोला।
• 200 का अर्थ है कि request किसी ऐसे application case पर resolve हुआ जो customer के पास पहले से था, उदाहरण के लिए ऐसी bank capability के लिए दोहराया गया request जो customer के पास पहले से है, या किसी canceled capability के लिए request। card या stablecoin_transfers के लिए दोहराया गया request अब भी 409 capability_already_exists लौटाता है।
• selectedApplicationId data के बगल में एक top-level field है, जिसमें उस case का ID होता है जिसे request ने चुना या खोला। जब request ने कोई case नहीं चुना, तो Swipelux इसे छोड़ देता है। Idempotent replay वही value लौटाता है।

{
  "data": {
    "id": "ach_named",
    "status": "pending",
    "openTaskIds": ["tsk_000000000000000002"],
    "applications": [{ "id": "apl_000000000000000005", "status": "in_review" }]
  },
  "selectedApplicationId": "apl_000000000000000005"
}

​

Customer के applications सूचीबद्ध करें

curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/applications" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"

• scope: एक bank पर case के लिए named, बिना bank वाले cases के लिए provider_pooled या platform, या unclassified historical case के लिए null। provider_pooled और platform cases के लिए institution मौजूद नहीं होता।
• requestedScope[]: case के विरुद्ध अनुरोधित capability keys, प्रत्येक अपने पहले requestedAt के साथ। Entries कभी हटाई नहीं जातीं।
• coverage[]: वे capability keys जिन्हें case का approval cover करता है, प्रत्येक grantedAt और source के साथ। Coverage scope record करता है, authorization नहीं। वर्तमान status के लिए capability पढ़ें।
• probes[]: case द्वारा cover की गई pooled capability keys के लिए method checks, प्रत्येक capabilityKey, status, और reason के साथ। Named keys को कभी probe की आवश्यकता नहीं होती।
• generation, predecessorApplicationId, और supersededByApplicationId: succession links। जब supersededByApplicationId set हो, तो case को replace कर दिया गया है। वर्तमान case तक पहुँचने के लिए उस ID का पालन करें। किसी capability की applications[] केवल वर्तमान cases सूचीबद्ध करती है, इसलिए replace किया गया case केवल इसी सूची में दिखता है।

{
  "data": [
    {
      "id": "apl_000000000000000005",
      "status": "ready",
      "scope": "named",
      "institution": { "id": "jpmorgan", "name": "JPMorgan Chase", "bic": "CHASUS33" },
      "requestedScope": [
        { "capabilityKey": "ach_named", "requestedAt": "2026-09-20T10:00:00.000Z" }
      ],
      "coverage": [
        { "capabilityKey": "ach_named", "grantedAt": "2026-09-22T12:00:00.000Z", "source": "approval" },
        { "capabilityKey": "wire_named", "grantedAt": "2026-09-22T12:00:00.000Z", "source": "approval" }
      ],
      "probes": [],
      "generation": 1,
      "predecessorApplicationId": null,
      "supersededByApplicationId": null
    }
  ],
  "nextCursor": null,
  "hasMore": false
}

​

वर्तमान tasks पूरे करें

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

​

पुन: उपयोग किए गए profile evidence

​

Requirements render करें

• allowedValues: किसी scalar field के लिए, या किसी array field के प्रत्येक item के लिए अनुमत values। इन्हीं values को submit करें, translated display labels को नहीं।
• valueSchema: एक self-contained JSON Schema Draft 7 document जो input shape, nested properties, required fields, और structural constraints का वर्णन करता है। Objects पर enums संबंधित property पर दिखाई देते हैं, उदाहरण के लिए tax identifiers के लिए valueSchema.items.properties.type.enum। Swipelux submission के बाद भी cross-field और review validation लागू करता है, इसलिए schema पास करने वाली value भी reject हो सकती है।
• valueType: "country", या arrays के लिए itemValueType: "country": field uppercase ISO 3166-1 alpha-2 codes लेता है। valueSchema में nested country properties format: "iso-3166-1-alpha-2" का उपयोग करती हैं। Localized labels के लिए एक standard country list का उपयोग करें।

{
  "id": "req_000000000000000010",
  "key": "account_purposes",
  "title": "Account purpose",
  "status": "action_required",
  "request": {
    "type": "profile",
    "prompt": "Select every purpose that applies.",
    "required": true,
    "profilePointer": "/financialProfile/accountPurposes",
    "valueType": "array",
    "itemValueType": "string",
    "allowedValues": ["business_expenses", "ecommerce", "payroll"],
    "valueSchema": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "array",
      "items": { "enum": ["business_expenses", "ecommerce", "payroll"] }
    }
  }
}

​

Hosted actions

• action.kind: "available" में action.url और action.expiresAt शामिल होते हैं (वर्तमान में हमेशा null)। action.url store करें, customer को उस पर भेजें, फिर task को दोबारा पढ़ें। Session-level url और expiresAt fields में वही values होती हैं।
• action.kind: "unavailable" का अर्थ है कि कोई link नहीं दिखाया जाना चाहिए। Session-level url और expiresAt fields मौजूद नहीं होते। Session का status अकेले यह तय नहीं करता कि आपको कौन सा action kind मिलेगा।

{
  "data": {
    "verificationSessions": [
      {
        "id": "vfy_000000000000000003",
        "key": "identity_verification",
        "type": "identity_verification",
        "status": "action_required",
        "action": {
          "kind": "available",
          "url": "https://platform.swipelux.com/kyc/redirect/cus_000000000000000001/tsk_000000000000000002/vfy_000000000000000003",
          "expiresAt": null
        },
        "url": "https://platform.swipelux.com/kyc/redirect/cus_000000000000000001/tsk_000000000000000002/vfy_000000000000000003",
        "expiresAt": null
      }
    ],
    "tosSessions": [
      {
        "id": "vfy_000000000000000004",
        "key": "terms_of_service",
        "type": "terms_of_service",
        "status": "completed",
        "action": { "kind": "unavailable" }
      }
    ]
  }
}

​

Documents upload करें

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

​

API answers

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

​

Businesses के लिए beneficial-owner पूर्वापेक्षा

{
  "type": "resource_reference",
  "prompt": "Add or select a qualifying beneficial owner.",
  "required": true,
  "resourceType": "related_party",
  "qualification": "beneficial_owner"
}

• एक qualifying related party बनाना या अपडेट करना उसी reevaluation में requirement को पूरा करता है और उस owner के अपने profile और document work को खोलता है। Business related parties जोड़ें देखें।
• आप एक resource_reference answer के साथ, जो उसका relatedPartyId रखता है, किसी qualifying party को स्पष्ट रूप से reference भी कर सकते हैं।
• पूरा होने के बाद भी requirement वर्तमान task में सूचीबद्ध रहता है। जब कोई अन्य obligation खुला नहीं रहता, तो task satisfied हो जाता है।
• आखिरी qualifying party को archive करना, या उसे qualify करने वाले facts को हटाना, requirement को फिर से खोल देता है, भले ही task satisfied हो चुका हो।

​

जब capability तैयार हो तो जारी रखें

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