Kalshi Subaccounts Explained: Separate Balances, Transfers and Restricted API Keys

DeskBot — trading software and customer guides

Facts in this article were checked against Kalshi's API documentation (docs.kalshi.com, Subaccounts, Sub-users vs. Subaccounts and the Portfolio API reference) on October 27, 2026; the FAQ was re-checked on October 29, 2026. Kalshi changes its API often; check the docs before you rely on any detail. DeskBot is not affiliated with Kalshi.

If you trade Kalshi through the API, one account can hold several separate pots of money. Kalshi calls them subaccounts. Each one has its own cash balance and its own positions, and an API key can be locked to a single one. That makes subaccounts the cleanest way to give a trading bot a fixed amount of capital without handing it your whole balance.

This guide covers what subaccounts are, who can use them, how the numbering and transfers work, what a restricted API key can and cannot do, and how they differ from sub-users (Team Members), which people often mix up with them.

What a Kalshi subaccount is

Kalshi's docs describe subaccounts as a way for a Direct account to split its balance and positions into independent buckets under one set of API credentials. Three things follow from that:

  • Separate money. Cash in subaccount 3 is not available to orders placed in subaccount 5.
  • Separate positions. A contract bought in one subaccount shows up only in that subaccount's positions, fills and settlements.
  • One owner. All subaccounts sit inside your account. A subaccount has no login and no permissions of its own.

As of this writing subaccounts are API-only. The Kalshi web and mobile apps do not yet show numbered subaccounts, so you create, fund and read them through the trade API.

Who can use them

Subaccounts are available to Direct accounts on the Advanced API tier or above. The Create Subaccount endpoint says so directly. Kalshi's rate-limit page explains that Advanced is reached by calling the Upgrade Account API Usage Level endpoint; the higher tiers (Expert and up) are earned from trading volume or assigned by Kalshi.

If your account is on the Basic tier, the create call will not work until you upgrade. Nothing else about your account changes when you start using subaccounts: your existing balance simply lives in subaccount 0.

Numbering: 0 is primary, 1 to 63 are yours

Number Meaning
0 Primary subaccount. This is your normal account balance.
1–63 Numbered subaccounts you create. Assigned in order, starting at 1.

That is 64 buckets in total, counting the primary. You cannot choose the number: each call to POST /portfolio/subaccounts returns the next one as subaccount_number. The request body is optional and only takes an exchange_index (exchange shard), which defaults to 0.

Moving money between subaccounts

Cash moves with POST /portfolio/subaccounts/transfer. The required fields are:

Field What it is
client_transfer_id A UUID you generate. It makes the transfer idempotent.
from_subaccount Source number, 0–63.
to_subaccount Destination number, 0–63.
amount_cents Amount in cents. $50.00 is 5000.

An optional exchange_index picks the shard (default 0). A few details matter in practice:

  • Nothing leaves your account. Kalshi notes that transfers net to zero at the account level. It is a move from one pocket to another, not a withdrawal.
  • Retries are safe. If a request times out and you resend it with the same client_transfer_id, Kalshi returns 409 instead of moving the money twice. Generate a new UUID only for a genuinely new transfer.
  • Amounts are cents, not dollars. Sending 50 moves fifty cents. This is the most common first mistake.
  • There is a history. GET /portfolio/subaccounts/transfers lists past transfers, paginated, so you can reconcile what moved where.

Worked example: fund a bot with $200

Say your primary balance is $1,000 and you want a bot to trade with $200 and no more.

  1. Create a subaccount. The response is {"subaccount_number": 1}.
  2. Transfer: from_subaccount: 0, to_subaccount: 1, amount_cents: 20000, plus a fresh UUID.
  3. Check: GET /portfolio/subaccounts/balances returns each subaccount's balance. Primary should show $800, subaccount 1 should show $200.
  4. Create an API key restricted to subaccount 1 (next section) and give only that key to the bot.

Now the most the bot can commit is the $200 in subaccount 1 plus whatever that subaccount wins back. It cannot reach the $800, because it cannot see it and cannot move it. If you later want to add capital, you do the transfer yourself with your unrestricted key.

A note on fees and breakeven: subaccounts do not change Kalshi's trading fees. Each subaccount pays the same fee schedule on its own fills, so a small subaccount still has to clear the same per-contract fee as your primary. Our fees guide and breakeven win-rate guide walk through that math.

Restricted API keys: locking a key to one subaccount

When you generate an API key you can restrict it to a single subaccount. According to Kalshi's docs, a restricted key can:

  • Place, amend and cancel orders on its subaccount, and manage order groups.
  • Read that subaccount's balance, positions, fills and settlements.
  • Run the REST RFQ lifecycle on its subaccount, including creating combo markets in multivariate event collections and posting or accepting quotes.
  • Read GET /portfolio/subaccounts/balances, which returns only its own subaccount, broken out by exchange index.

And it cannot:

  • Transfer funds between subaccounts.
  • Create or manage subaccounts or API keys.
  • Act on RFQs or quotes belonging to a different subaccount.

Calls outside the allowed set return 403 with a message that the key is restricted to a single sub-account. Two behaviours are worth knowing before you point a bot at a restricted key:

  • Omitting subaccount is fine. A request without a subaccount parameter acts on the key's locked subaccount. Naming any other subaccount is rejected. So a bot that has never heard of subaccounts will, per the docs, simply trade the locked one, as long as it only calls endpoints a restricted key may use.
  • Self-trade prevention spans every subaccount. If an order from the restricted key would match an order resting in another of your subaccounts, its self_trade_prevention_type decides: taker_at_cross cancels the incoming order, maker cancels the resting one. If you run two strategies that might quote both sides of one market, expect some orders to be cancelled rather than filled against yourself.

Only the account owner can create API keys. Restricted keys also have narrower support on FIX (order entry and the maker quote lifecycle only) and on perps, where some endpoints such as margin balance are not yet available to them. Our Kalshi API keys and authentication guide covers creating keys and signing requests.

Subaccounts vs. sub-users (Team Members)

Kalshi has a second feature with a similar name. A sub-user is an extra login on your account; in the web app they appear as Team Members. The two solve different problems: sub-users control who can act, subaccounts control which money and positions an action uses.

Sub-users (Team Members) Subaccounts
What it is Another login with its own email and password A separate balance and set of positions
Balance and positions Shares the account's Has its own
Permissions Read, Trade and Transfers, set per sub-user None of its own; an API key can be restricted to one
Set up by Kalshi enables it; the owner adds sub-users in the web app The owner, through the API
Availability Institutions, on request Direct accounts on Advanced tier or above

Sub-user permissions apply to the whole account, so you cannot limit a sub-user to one subaccount. If the goal is to confine trading to a fixed pot of money, a restricted API key on a funded subaccount is the tool, not a sub-user.

Practical uses

  • Cap a bot's capital. Fund a subaccount with what you are prepared to lose, give the bot a key restricted to it, and keep the key for the rest of the account to yourself.
  • Keep strategies apart. One subaccount per strategy means each one's balance, fills and settlements are already separated, so you can see which strategy actually earns its fees.
  • Test a change on a small stake. Run a new version on a lightly funded subaccount alongside your existing setup instead of switching everything at once.
  • Cleaner records. Historical fills and orders requested with a restricted key return only that subaccount's rows, which makes per-strategy record keeping simpler.

Risks and limits to keep in mind

  • A subaccount limits how much is at stake, not whether you lose it. A bot can still lose its entire subaccount balance. Trading can lose money.
  • Not visible in the app yet. Because subaccounts are API-only today, positions in numbered subaccounts will not appear in the web or mobile app the way your primary does. Keep your own record of what you funded.
  • Tier requirement. You need the Advanced API tier or higher to create them.
  • Self-trade cancellations. Running opposing strategies in different subaccounts can cancel orders, as described above.
  • Netting is a per-subaccount setting. The API exposes GET and PUT /portfolio/subaccounts/netting to read and change whether netting is enabled for each subaccount. Read Kalshi's current docs on what it changes before you touch it.

Where DeskBot fits

DeskBot is a desktop trading tool for Kalshi's 15-minute markets. It runs on your own computer with your own Kalshi API key; we never hold your funds or your key. If you want to cap how much any automated tool can commit, the subaccount-plus-restricted-key setup above is the approach Kalshi itself documents for it. Check that the tool you use only calls endpoints a restricted key is allowed to use before you rely on it.

What is a Kalshi subaccount?

A separate cash balance and set of positions inside one Direct account, under the same API credentials. Every account has a primary subaccount numbered 0 and can use numbered subaccounts 1 to 63.

How many subaccounts can I have on Kalshi?

Up to 63 numbered subaccounts (1–63) plus the primary (0), for 64 in total.

Can I see subaccounts in the Kalshi app?

Not yet. Kalshi's docs describe subaccounts as an API-only feature that the web and mobile apps do not currently support.

Do I need a special account to create one?

You need a Direct account on the Advanced API tier or above. Advanced is reached through the Upgrade Account API Usage Level endpoint.

Does moving money between subaccounts count as a withdrawal?

No. Transfers stay inside your account and net to zero at the account level.

What happens if my transfer request times out?

Resend it with the same client_transfer_id. If the first one went through, Kalshi returns 409 and does not move the money a second time.

Can a restricted key withdraw money or move it between subaccounts?

No. A key restricted to one subaccount can trade and read that subaccount but cannot transfer funds between subaccounts or manage keys.

What does a restricted key get back when it calls a blocked endpoint?

A 403 saying the key is restricted to a single sub-account and cannot access that endpoint. Inside its allowed set (orders, order groups, balance, positions, fills, settlements and the REST RFQ flow on its own subaccount) it works normally.

Can I limit a sub-user (Team Member) to one subaccount?

No. Sub-user permissions apply to the whole account. To confine trading to one subaccount, use an API key restricted to it; only the account owner can create API keys.

Is a sub-user the same as a subaccount?

No. A sub-user is another login that shares the account's money; a subaccount is a separate pot of money with no login of its own.

Trading can lose money. Nothing here is financial advice and no profit or win rate is guaranteed. DeskBot is not affiliated with, endorsed by or sponsored by Kalshi.

Current product information: Kalshi · Robinhood · Setup and support. Check the relevant product page for current downloads, pricing, renewal and cancellation terms. Desktop and mobile products have separate availability and offers.

Educational content, not financial advice. Trading can lose money. DeskBot does not guarantee profits, returns, win rates or income and is not affiliated with or endorsed by the named exchanges or brokers.