Bybit API error 10005: permission denied on an API key

CoTrading editorial team 2026-09-23

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

Bybit V5 returns retCode: 10005 with the message “Permission denied, please check your API key permissions.” The API key your request used does not carry the permission the endpoint requires. The fix: find out which key the process actually loaded, grant that key the permission the endpoint needs (or issue a new key that has it), and restart whatever holds the old credentials.

This page is for anyone whose reads work but whose orders, leverage changes or account operations come back with 10005. It explains what the code tells you, the one cause that covers most cases, and why the error often survives a permission change you are sure you made.

What this error actually means

A Bybit API key is more than an identifier and a secret. It carries a set of permissions chosen when it was created, and each private endpoint needs a particular one. 10005 is Bybit telling you the key and the endpoint do not match.

In our reading, that makes it a narrower error than it first looks. A key Bybit does not recognise for the host produces 10003; a request from an address outside the key’s bound IPs produces 10010; a bad signature produces 10004. 10005 is the answer to “can this key do this?”, not “is this key valid?”.

A note on scope. This page deliberately does not list Bybit’s permission names or which endpoint requires which. We have not verified how Bybit’s key-management page presents its permission scopes today, and a wrong label is worse than none. Read the scopes from the key’s own settings page and the endpoint’s documentation, and match them there.

The usual cause: a read-only key calling a write endpoint

Starting with a read-only key is good practice — see read-only vs trade permission — and it means 10005 is the expected result the first time the code tries to change state. Typical triggers:

Placing, amending or cancelling an order
POST /v5/position/set-leverage
POST /v5/position/switch-mode
Any endpoint that moves funds

The signature of this cause is clean: every read works, every write in one area fails, and it has always been that way on this key. Grant the missing permission — and only that one — or create a separate key for the component that trades.

Other causes, in order of likelihood

1. You changed a different key from the one in use. The most common reason the error survives a fix. Two keys exist, and the process loads the old one — from a stale environment variable, a secrets store that was not updated, a config file earlier in the search path, or a container that was not restarted after the change.

2. You changed the key in a different environment. Bybit has four environments — mainnet, testnet, mainnet-demo, testnet-demo — with separate keys. Permissions set on a mainnet key do nothing for the testnet key your staging bot uses, and the reverse.

3. The permission covers a different product area. If the key’s settings split permissions by product, the one you enabled may not be the one that covers the endpoint’s category. Read the endpoint’s docs, then the key’s settings, side by side.

4. It is not a permission problem. Several codes sit close to 10005 and read like it:

Code	Meaning (Bybit’s wording)	What is actually wrong
`10005`	“Permission denied, please check your API key permissions.”	The key lacks the permission
`10010`	“Unmatched IP, please check your API key’s bound IP addresses.”	Request IP not bound to the key
`10003` (REST)	“API key is invalid…” — key and domain not matched	Key used on another environment’s host
`10028`	“The API can only be accessed by unified account users.”	Account type, not key permission
`100028`	“The API cannot be accessed by unified account users.”	Account type, not key permission
`10009`	“Service Restricted: Access is currently unavailable for your region. …”	Regional restriction
HTTP `403`	Includes requests from restricted regions	The guide names US and Mainland China IPs

The account-type pair is the one most often misread as a permission problem. No key setting fixes 10028 or 100028; the endpoint and the account type disagree. Regional restrictions are not a key problem either, and there is no key setting — or anything else we would suggest — that works around them.

How to confirm which one you have

1. Name the endpoint. Log the path and category of every request that returns 10005. “Orders fail” is a symptom; “POST to the create-order endpoint on linear fails” is a diagnosis.

2. Prove the key authenticates. Make a read, such as GET /v5/account/wallet-balance, with the same credentials. If it succeeds, the key is valid and the problem is scope. If it fails with a different code, follow that code instead.

3. Prove which key is loaded. Log a short, non-secret fingerprint of the API key at startup — the first and last four characters is enough. Compare it with the key whose settings you edited. This step alone resolves most “I already fixed it” cases.

4. Confirm the environment. Log the base URL next to the key fingerprint. A testnet host with a mainnet key fingerprint is a different bug, but you will see it here.

5. Compare the key’s settings with the endpoint. Only now open the settings page, with a specific endpoint and a specific key in hand.

Keep the fix narrow

Resist the urge to tick everything to make the error go away. Every permission on a key is something a leaked copy of it can do.

One key per component. The reader gets a read-only key; the part that trades gets a key with trading permission; nothing that trades needs a permission that moves funds off the account.
Bind IPs to keys with trading permission — see Bybit API error 10010 for what that looks like when it goes wrong.
Check at startup. A process that makes one representative call of each kind on boot fails immediately with 10005, rather than at the first real order.

The full list is in the exchange API key security checklist.

For automation, 10005 is a permanent error: retrying cannot succeed. It should stop the component and raise an alert. That matters more when a language model is calling the tools — a failed call looks like something to try again, and no retry changes a key’s permissions.

FAQ

What does Bybit error 10005 mean?

It means the API key used for the request does not have the permission the endpoint requires. Bybit documents it as “Permission denied, please check your API key permissions.” The key itself was accepted; the refusal is about what the key is allowed to do, so the fix is in the key’s permissions, not the request.

I enabled the permission and still get 10005. Why?

Usually because the process is using a different key from the one you edited: an old environment variable, a secrets store that was not updated, or a service that was not restarted. It can also be a key from another environment — Bybit’s mainnet, testnet and demo keys are separate. Log a fingerprint of the loaded key and compare.

Is Bybit error 10005 the same as 10028?

No. 10005 is about the key’s permissions. 10028 means the endpoint can only be accessed by unified account users, which is about the account type and cannot be fixed by changing the key. Its mirror image, 100028, means the endpoint cannot be accessed by unified account users.

Should my code retry on 10005?

No. A permission refusal will fail identically on every retry and only uses up rate limit. Treat it as a configuration error: stop, alert, and fix the key. Checking permissions with one representative call at startup surfaces it before any order is attempted.