How to Handle a Kalshi API Key Safely

A Kalshi API key is the credential that tells Kalshi's API which account a request comes from. It's what lets a program do the things a logged-in person can, such as reading account data and placing orders, so it deserves the same care as a password. Kalshi sets the exact steps to create one, the format, what it can access, its limits and any cost, and it publishes all of that in its own API documentation.

So this page doesn't repeat Kalshi's steps. It covers what the key is for, which questions to answer in Kalshi's docs before you request one, and how to handle the key once you have it, which is where most leaks happen.

How to get Kalshi API key access

The answer to "how to get kalshi api key" access is in Kalshi's documentation and account settings, and it can change. What you can prepare for:

• An account. API keys usually belong to an account, so you'll need one in good standing, in a place Kalshi serves.
• A key and possibly more than one piece. Some exchanges issue a key id plus a private key, and ask you to sign each request with it. Others issue a single token. Follow Kalshi's scheme exactly.
• A one-time view. Many services show a secret only once, at creation. Have somewhere safe to put it before you click the button.
• Separate test credentials. If Kalshi offers a demo environment, its keys are separate from live ones. Our guide to setting up the Kalshi Python SDK covers switching between the two.

Is Kalshi API free?

People asking "is kalshi api free" usually mean one of two things: does reading data cost anything, and do you pay to trade. Those are separate questions. Access to data and trading fees are set by Kalshi, may differ by what you're doing, and change over time, so check Kalshi's current docs and fee pages rather than any third-party summary. The same goes for "kalshi api cost": if there's a charge, Kalshi's pages are where it's stated, and it belongs in your budget before you write code.

Kalshi API limits

Every exchange API caps how fast you can make requests. Kalshi's own pages state its limits in its docs, and they may differ by endpoint or account. Build for them from the start:

1. Read the published limits and set your client a little under them.
2. On a rate-limit error, wait before trying again, and wait longer each time. Honor any retry time the response gives you.
3. Count your own requests, so you know you're near the limit before Kalshi tells you.
4. Prefer a stream to polling where the docs offer one: fewer requests, fresher data.

Storing the key

The rules are the same for any secret, and they're the part you control:

• Never in code. Not in a script, not in a notebook, not in a config file that gets committed.
• Never in a URL. URLs end up in server logs, proxy logs and browser history.
• Never in logs. Log that a request was authenticated, not with what.
• In the environment, or a secrets manager. Load it at start-up and fail loudly if it's missing.

import os, sys

def require_secret(name: str) -> str:
    value = os.environ.get(name, "").strip()
    if not value:
        sys.exit(f"{name} is not set; refusing to start")
    return value

def redact(value: str) -> str:
    return value[:4] + "..." if len(value) > 8 else "***"

key_id = require_secret("KALSHI_KEY_ID")
print("using key", redact(key_id))

If Kalshi's scheme gives you a private key file, keep it outside the repository, readable only by the user that runs the program, and point to it with an environment variable. Add .env and your key file's name to .gitignore before the first commit, not after.

Rotating and revoking

Plan for the day a key leaks, because the fix is the same whether it does or not:

• Create a new key, deploy it, confirm it works, then revoke the old one.
• Rotate on a schedule, and immediately when someone with access leaves or a laptop goes missing.
• Use one key per program where Kalshi allows it, so revoking one doesn't stop everything.

A key that can trade can lose money in minutes if it's misused. That's reason enough to treat it like the bank card it effectively is. If you're building something that trades on its own, our guide to what Kalshi bots need covers the risk limits that should sit between a key and an order.

The same rules on ZippyOddsAPI

ZippyOddsAPI is independent and not affiliated with Kalshi, but its own key rules show the pattern in practice. A ZippyOddsAPI key goes in an Authorization: Bearer header. A key in the URL is refused with 400 api_key_in_url, because URLs end up in logs. The secret is shown once when the key is issued and stored only as a keyed hash, so a lost key has to be rotated. A key can also be limited to certain scopes, an IP allowlist, a monthly credit cap and an expiry.

ZippyOddsAPI keys are issued on request, and the ZippyOddsAPI docs explain how to ask for one and what each request costs in credits.

For what you can do with Kalshi's API once your key is set up, read our Kalshi API guide. For a comparison across prediction venues, see the prediction market API overview.