List capabilities

GET /api/v1/partner/customers/{customerId}/capabilities

Required scope: customers:read (global tier). Capabilities are a sub-resource of the customer, so no separate scope is needed.

Reports, per capability, two independent facts:

• enabled — the grant: whether your partner integration is permitted to use this capability on this customer. See How grants are set below.
• available — merchant-side truth, which can flip on its own (e.g. KYB expiring, a chargeback threshold landing) with nobody touching the partner’s configuration.

Reporting both lets you explain a disabled action in your own words (“payments unavailable — verification pending”) instead of guessing from a 409.

Request

curl -X GET https://www.niftipay.com/api/v1/partner/customers/pc-1/capabilities \
  -H "Authorization: Bearer <partner_api_key>"

No request body.

Response 200

{
  "request_id": "req-1",
  "api_version": "2026-08-01",
  "data": {
    "capabilities": [
      {
        "capability": "payments.crypto",
        "enabled": false,
        "available": true,
        "reason": null
      },
      {
        "capability": "payments.fiat_card",
        "enabled": true,
        "available": false,
        "reason": "chargeback_threshold"
      },
      {
        "capability": "payouts",
        "enabled": false,
        "available": true,
        "reason": null
      },
      {
        "capability": "payout_wallets",
        "enabled": false,
        "available": true,
        "reason": null
      },
      {
        "capability": "refunds",
        "enabled": false,
        "available": true,
        "reason": null
      },
      {
        "capability": "wallets",
        "enabled": false,
        "available": true,
        "reason": null
      },
      {
        "capability": "withdrawals",
        "enabled": false,
        "available": true,
        "reason": null
      }
    ]
  }
}

All seven capabilities are always returned. When a capability’s availability check itself fails, the entry degrades to { "available": true, "reason": "availability_unknown" } — distinguishable from a healthy resolve — so you can render the uncertainty rather than assert a state you have no basis for. The internal error is logged, never returned.

How grants are set

Two arrangements exist, and which one applies to you is a property of your partner integration rather than of any individual customer.

Auto-granted. A customer you create starts with the same capability set a merchant signing up directly receives:

The two held capabilities are the money-out and card rails. They are granted automatically the moment the customer’s verification is approved, and withdrawn again if it is later rejected — you do not need to ask anyone.

Manually granted. Every capability starts at false and is turned on by Niftipay staff per customer.

Either way, the check below is the same, and it is the one to build against: read enabled and available rather than assuming a starting state.

enabled and available are two separate gates

Turning a grant on does not make a capability usable. Calling a rail you have been granted but whose merchant is not eligible returns 409 capability_unavailable, not a 403 — the two failures need different handling:

Errors