Trading API
Authentication
How to send the key, the first call to make, and the routes that refuse it.
Send the key in either header. If both are present, X-API-Key is the one that is read.
X-API-Key: usr_ak_a1b2c3d4e5f60718.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Authorization: Bearer usr_ak_a1b2c3d4e5f60718.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxEvery account and trading route takes the key. The market data routes are public and take none. Session tokens are not accepted on this surface.
The first call
GET /account confirms the key works and reports the policy in force:
curl -s "https://api.beta.cardiv.xyz/api/trade/v1/account" -H "X-API-Key: usr_ak_..."| Field | |
|---|---|
tier | RETAIL, or MARKET_MAKER once WolfEdge has attached the policy |
partyId | The party the key resolves to |
clientOrderIdPrefix | What every clientOrderId you send must start with: api- for a retail account, the firm's slug plus a hyphen for a market maker |
feeExempt | false for retail, true for a registered market maker |
status | ACTIVE, SUSPENDED or DISABLED. A non-active account is refused new placements while its resting orders carry on. |
limits.allowedPairs, limits.maxOpenOrders, limits.ordersPerMinute | The account's caps: "all", null and the venue default when uncapped |
A 401 here means the wrong key or the wrong environment.
What a key cannot reach
The routes that list, issue and revoke keys, /api/v1/api-keys on the app's own surface, answer 403 SESSION_REQUIRED to a key. That is deliberate: a leaked key cannot replace itself or lock you out. Manage keys in the app.
Need help
Write to support@wolfedgelabs.com and include your party ID.