ISV tokens can now read user wallets, transactions, orders and parlays

Availability: Sandbox since November 3, 2026 · Production since November 3, 2026

A token issued for your ISV without a sub claim can now read your users' data, which is useful for background jobs and support tools. Existing calls that carry a sub claim are unchanged.

When the token has no sub claim, the user is resolved like this:

• With ?userId=, the request is scoped to that user, who must belong to your ISV. A user of another ISV is treated as not found (404, or an empty page for lists).
• With neither a sub claim nor userId, behaviour is unchanged (ISV-level data).
• With a sub claim, the request is always scoped to that user and userId is ignored.

Endpoint behaviour with an ISV token (no sub):

• GET /private/v1/wallets: userId returns that user's wallet. Without it you still get the ISV pot.
• GET /private/v1/transactions: userId returns that user's transactions. The new scope=all query parameter returns every transaction of your ISV, ISV-level and user rows alike. The default, scope=isv, still returns ISV-level transactions only.
• GET /private/v1/market-orders and GET /private/v1/parlays: userId is required, and the request returns 400 without it. These lists now also document 404 responses.
• GET /private/v1/market-orders/{refId}: the order may belong to any user of your ISV.
• GET /private/v1/parlays/{parlayId}: returns a confirmed parlay placed by any user of your ISV. A parlay that was never confirmed returns 404.
• GET /private/v1/users/USERID/permissions: now checks that the user belongs to your ISV.

The four market order and parlay read endpoints are no longer permission-gated, so a user who is blocked by KYC or suspended can still read their history. Placing orders and parlays is still gated.

Listing all market orders or parlays across your ISV in a single call is not available. Query them per user.

See Market Orders, Parlays and Wallets.