Get Balances by Coin

The same money as GET /v1/wallets/balance, arranged differently: one entry per coin, split across the three wallets. This is the more convenient shape for a trading client.

Permission: READ_BALANCE

Reading the response

wallets is an object keyed by coin ticker, not an array.

The three slot keys are lowercase: spot, asset, future. Note that walletType on the other balance endpoint is uppercase. This asymmetry is real, so do not normalize one to match the other.

All six values are always present and default to the string "0".

What you actually want

For spot trading, read wallets.<COIN>.spot.available. That is the number that decides whether your order will be accepted. locked is already committed to open orders, and the other two wallets cannot fund a spot order.

Notes

Only coins you hold an account for appear. Filtering by a coin you have never held returns {"wallets": {}}. It does not invent a zero entry.

An API key can read balances here but can never move funds. POST /v1/transfers is session-only, and no permission can authorize it.

Errors: 400 VALIDATION_ERROR for a bad or unknown query parameter, plus the authentication set.

Request Code Samples

Shell

JavaScript

Java

Swift

PHP

Python

HTTP

Objective-C

Ruby

OCaml

Dart

Responses

🟢200

application/json

Bodyapplication/json

Example

{
  "wallets": {
    "USDT": {
      "spot": {
        "available": "1500.25",
        "locked": "200"
      },
      "asset": {
        "available": "0",
        "locked": "0"
      },
      "future": {
        "available": "500",
        "locked": "0"
      }
    },
    "BTC": {
      "spot": {
        "available": "0",
        "locked": "0"
      },
      "asset": {
        "available": "0.051",
        "locked": "0"
      },
      "future": {
        "available": "0",
        "locked": "0"
      }
    }
  }
}

🟠400

Reading the response#

What you actually want#

Notes#

Request

Request Code Samples

Responses

Reading the response

What you actually want

Notes