Are My Broker API Keys Safe? How Credentials Should Be Handled

An API key lets software place orders in your account. It does not let anyone withdraw your money. That distinction defines the entire risk picture, and understanding it tells you what to protect against and what not to worry about.

What an API key can and cannot do

Can	Cannot
Place, modify and cancel orders	Withdraw funds from your account
Read positions, orders and balance	Change your bank details
Square off existing positions	Transfer securities out
Act within market hours	Change your broker login password

The right-hand column is the reassuring part. Money leaves a broker account through a separate, more heavily protected channel that API access does not touch.

Why that does not mean it is harmless

The left-hand column is still serious. An attacker who could place orders in your account could cause losses deliberately — opening positions you did not want, or closing ones you did. The risk is real; it is just a different risk from theft.

The three layers that protect you

Indian broker API access is protected by more than the key alone, which is why a leaked key is less immediately catastrophic here than in some other markets.

The key and secret. Issued by your broker, revocable by you at any time.
A registered IP address. Requests from any other address are refused, so a stolen key used from elsewhere does not work.
A daily session token. It expires every day, so even a working session has a short life.

How a key could realistically be exposed

Thinking about the actual paths is more useful than general caution, because most of them are avoidable with a specific habit.

Path	How likely	The habit that prevents it
Sent over chat or email to support	Common	Never send credentials to anyone, ever
Included in a screenshot	Common	Crop or redact before sharing anything
Left in a config file on a shared machine	Occasional	Keep credentials out of files you sync or share
Platform stores them poorly and is breached	Rarer	Ask how they are stored before entering them
Your own device is compromised	Rarer	Standard device hygiene; nothing platform-side helps here

The top two account for most real-world exposure and both are entirely within your control. No amount of encryption on a platform's side helps once a key has been pasted into a chat window.

How a platform should store your credentials

Four things distinguish responsible handling from careless handling, and you can ask about all of them directly.

Practice	What it means	Why it matters
Encrypted at rest	Credentials are not stored as readable text	A database leak does not immediately expose keys
Decrypted only in memory, at point of use	Plaintext exists briefly, only while placing an order	Reduces the window in which it can be read
Never displayed back	Not shown in the interface, including to staff	Removes screenshots and support chats as a leak path
Not logged	Credentials never appear in application logs	Logs are copied and retained far more widely than databases

On Arthalab, broker credentials are encrypted at rest and decrypted in memory only at the moment an order is placed. They are never shown back in the interface, including to admin users — the admin panel can show a connection's network settings but not its key, secret, access token or client ID.

Warning signs

Signals that a platform is handling credentials badly, in rough order of seriousness.

It asks for your broker login password rather than API credentials you generated. There is no legitimate reason for this.
It displays your API key back to you in full. If the interface can show it, so can anyone who gains access to the interface.
Support asks you to send credentials over chat or email. Both are stored, forwarded and backed up in ways nobody controls.
It claims to automate your daily broker login. That requires storing your password.
It cannot tell you how credentials are stored. A vendor that has thought about this can answer in a sentence.

What you should do

Generate API credentials yourself, in your broker's own portal
Whitelist a dedicated IP address rather than a broad range
Never send credentials over chat, email or screenshots
Revoke and regenerate the key if you suspect exposure
Review your broker's active API apps periodically and remove unused ones
Keep your broker login password separate and never share it

The periodic check worth doing

The fifth item is the one people skip. API apps accumulate — created for a platform you trialled once, left active years later. An unused app is a credential you are not watching.

If you think a key has been exposed

Revoke it in your broker's portal first

This is the action that actually stops it working. Do it before anything else.

Check your order book and positions

Look for anything you did not place. The order book is the record that matters here.

Tell your broker

They can advise on whether further action is needed and have visibility you do not.

Generate fresh credentials

A new key and secret, entered into your platform.

Re-whitelist and validate

Run validation to confirm the new setup works before relying on it.

Using several platforms at once

If you trial or run more than one platform, each is another place your credentials exist. That is manageable, with one practice.

Where your broker allows multiple API apps, create a separate one per platform. The benefit is isolation: you can revoke one platform's access without disrupting the others, and if something goes wrong you know which set of credentials was involved.

Why one app per platform matters

Reusing a single app across platforms removes that ability. Revoking becomes all-or-nothing, and attributing unexpected activity becomes guesswork.

What a platform cannot protect you from

Being clear about the boundary matters as much as the protections themselves.

A compromised machine. If your own device is compromised, anything you can see can be seen.
Credentials you shared. No storage practice helps once a key has been sent to someone.
A strategy that loses money. Security and performance are unrelated questions.
Your broker's own security. That relationship is between you and them.

The short version

An API key can place orders but cannot withdraw funds
Three layers protect you: the key, the registered IP, and daily session expiry
Credentials should be encrypted at rest and never displayed back
A request for your broker password is a reason to stop, always
If exposed, revoke first and check the order book second
Review and remove unused broker API apps periodically

The whitelisting step is the one that does most of the work here. Setting it up correctly takes a few minutes and is what makes a leaked key substantially less useful.

Frequently asked questions

Most often by being sent over chat or email, or included in an unredacted screenshot. Both are entirely within your control, and no amount of platform-side encryption helps once a key has been pasted somewhere.

No. Where your broker allows several, create one per platform. That lets you revoke a single platform's access without disrupting the others, and makes unexpected activity attributable.

Each is another place your credentials exist, which is manageable with separate API apps. The real risk is running two platforms live against the same broker account, where neither knows what the other has placed.

Not necessarily. The key alone is not enough — requests also have to come from your registered address within a valid daily session. That is precisely why those requirements exist.

No. API access covers order placement and account reading. Funds leave a broker account through a separate channel that API credentials do not reach.

Place or close orders in your account, which could cause losses. They would also need to be sending requests from your registered IP address and within a valid daily session, which is what makes a stolen key much less useful on its own.

No. If the interface can display it, anyone who gains access to the interface can read it. Not displaying it back is a basic expectation.

No, and no legitimate platform needs it. API credentials that you generate and can revoke are the correct mechanism. A password request is a reason to stop.

Revoke it in your broker's portal first, then check your order book for anything you did not place, then tell your broker and generate fresh credentials.

No. They are encrypted at rest and never shown back in the interface, including to admin users. The admin panel can show a connection's network settings but not its key, secret, token or client ID.

There is no fixed schedule, but reviewing your broker's active API apps periodically and removing unused ones is worth doing. An app created for a platform you trialled once is a credential you are not watching.

Each additional platform is another place your credentials exist. Use separate API apps per platform where your broker allows it, so you can revoke one without disrupting the others.

Start with a free 3-day trial

Build a strategy, backtest it and run it on paper — no broker, no IP and no money needed to try it.

Create a free account

All articles More in SEBI & Compliance