Bybit API error 10010: unmatched IP on a bound 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: 10010 with the message “Unmatched IP, please check your API key’s bound IP addresses.” The key has IP addresses bound to it, and the request arrived from an address that is not one of them. The fix: find the public IP Bybit sees from the machine that actually makes the call, and either bind that address to the key or send the traffic from an address that is already bound.

This page is for anyone whose Bybit key worked in one place and fails in another — laptop to server, host to container, before and after a restart. It covers what the binding checks, the cause behind most cases, and a quick way to see the address Bybit is comparing.

What this error actually means

When you bind IP addresses to a Bybit API key, Bybit compares the source address of each request made with that key against the bound list. 10010 is the result when the address is not on it.

Two things follow directly from the message, and they narrow the search:

The key is recognised. A key Bybit does not accept for the host produces 10003; this one is known and has a binding to compare against.
The address that matters is the one Bybit sees, not the one your machine thinks it has. Anything between your process and the internet — NAT, a gateway, a proxy — decides that address.

Binding is worth the trouble. It is the cheapest reduction in what a leaked key is worth, because a copy of the key and secret is useless from anywhere else. This page does not say which Bybit permissions require a binding: we have not verified that, and the key’s settings page is the authority.

The usual cause: you bound the wrong address

The address you bound is almost always one you saw, and the address that calls Bybit is one you did not look at.

You bound the IP shown in your browser, on your laptop. The bot runs on a server.
You bound the server’s address from its dashboard, but outbound traffic leaves through a NAT gateway with a different public address.
You bound the right address once, and it changed.

The last case has its own signature: it worked for days, then failed right after a restart, redeploy or router reboot. Many cloud instances receive a new public address when stopped and started unless a static one is attached, and residential connections rotate addresses on their own schedule.

Other causes, in order of likelihood

1. Containers, Kubernetes and CI. A process in a container usually leaves through the host’s or the cluster’s egress, not an address of its own. CI runners are worse: each job may egress from a different address in a shared pool.

2. More than one egress address. A NAT pool or load-balanced egress spreads requests over several public addresses. The symptom is intermittent: some requests pass, some return 10010, with no pattern in your code.

3. IPv6 versus IPv4. On a dual-stack machine, your HTTP client may reach Bybit over IPv6 while you bound an IPv4 address, or the reverse. We have not verified which address formats Bybit’s binding accepts; check which family your requests actually leave with and bind that.

4. A VPN or proxy on the machine. Traffic egresses from the VPN’s address. One caution: HTTP 403 is documented for requests from restricted regions — Bybit’s integration guide names IP addresses in the US or Mainland China — and a VPN is not a way around that. We will not suggest one.

5. The wrong key. You edited the binding on one key and the process loads another, or you edited a mainnet key while the process uses testnet or demo credentials. Bybit’s environments have separate keys.

How to confirm which one you have

Ask an IP-echo service what address it sees, from the same machine, container or job that calls Bybit:

curl -4 -s https://checkip.amazonaws.com   # IPv4 egress
curl -6 -s https://api64.ipify.org         # IPv6 egress, if any

Any IP-echo endpoint will do; what matters is where you run it. From inside a container, run it inside the container. Then match the pattern:

What you see	Most likely cause
Fails everywhere since the first deploy	Bound the laptop or dashboard address, not the egress
Worked, then failed after a restart	Public address changed
Works on the host, fails in the container	Container egresses through NAT
Fails intermittently	More than one egress address
`-4` matches the binding, requests still fail	Client is using IPv6
Echoed address matches, still `10010`	You edited a different key or environment

Log the egress address at startup, next to the base URL and a non-secret fingerprint of the key. When 10010 appears, the log already shows which of the three moved.

Codes that look similar

Code	Meaning	Why it is not `10010`
`10005`	“Permission denied, please check your API key permissions.”	Scope, not address — see Bybit API error 10005
`10003` (REST)	“API key is invalid…” — key and domain not matched	Environment mismatch — see Bybit API error 10003
`10018`	“Exceeded the IP Rate Limit.”	About traffic volume from an IP, not the binding — see Bybit API errors 10006 vs 10018
HTTP `403`	IP rate limit, GET with empty JSON body, or a restricted region	A status code, not a `retCode`

Fixing it so it stays fixed

Give the caller a stable egress address. A static public address on the instance, or a NAT gateway with a fixed address, then bind that.
One key per deployment. A key bound to one address serves one place. Two environments sharing a key means two sets of addresses on one binding and no attribution when it fails.
Do not remove the binding to make the error go away. That trades a configuration problem for a security one. Bind the right address instead.
Treat 10010 as permanent in code. Retrying from the same address fails the same way. Stop and alert.

The rest of the key hygiene is in the exchange API key security checklist.

FAQ

What does Bybit error 10010 mean?

It means the request came from an IP address that is not bound to the API key. Bybit documents it as “Unmatched IP, please check your API key’s bound IP addresses.” The fix is to bind the public address the calling machine actually egresses from, or to route the calls through an address that is already bound.

Why did Bybit error 10010 start after a restart?

Most likely the machine’s public IP address changed. Many cloud instances get a new public address when stopped and started unless a static one is attached, and home connections rotate addresses. Check the current egress address from the machine and compare it with the key’s binding.

Should I remove the IP binding to fix 10010?

Removing it makes the error disappear by removing the protection. A bound key is useless to anyone who copies it but sends from elsewhere, which is the main reason to bind at all. Give the caller a stable egress address and bind that instead.

No. 10010 is about your key’s own IP binding. Regional restrictions show up as HTTP 403 — Bybit’s integration guide says IP addresses in the US or Mainland China are restricted — or as 10009, “Service Restricted”. Those are access restrictions, not a key setting, and should not be worked around.