Setting API Key IP Allowlists and Minimal Permissions Step by Step

API keys are the most common way a trading bot, portfolio tracker or spreadsheet add-on reads your balances and places orders for you. The problem is that most keys are created in a hurry: the default permissions stay switched on, the IP restriction field is left blank, and the key ends up able to withdraw or trade from anywhere on the internet. This guide walks through the decisions you make before creating a key, how to work out which IP addresses to allow, how to trim permissions down to read-only or trade-only, and what to record so you can audit the key later. It applies to keys you create on Binance, OKX, Bybit or Bitget, and the exact wording of each screen differs, so treat every label as something to confirm on the exchange's own help centre rather than a fixed fact. Nothing here is investment advice, and no configuration can guarantee that a key will never be misused.

Decide what the key is for before you open the API page

Write one sentence describing the job the key has to do. A portfolio tracker that only reads balances needs no trading and no withdrawal rights. A grid bot that places and cancels orders needs spot trading but still does not need withdrawals. A tool that moves funds between accounts is a different risk category and usually should not exist as an automated key at all. If you cannot state the job in one sentence, stop and clarify it first, because permission choices follow directly from that sentence.

Then separate read needs from write needs. Reading includes balances, open orders, trade history and, on futures-enabled accounts, position and margin data. Writing includes placing, amending and cancelling orders, and transferring between wallets. Withdrawal permission is a third category that almost no bot requires. Many tools also ask for a label or nickname for the key; use something that names the tool and the date, so a key found later in a list is identifiable without guesswork.

Before you start, confirm on the exchange's account settings whether the account has any security prerequisites for API creation, such as a completed identity verification step or an active two-factor method. The verification page and the help centre describe what your account currently needs. Do not assume the flow will be identical to a guide written months ago, and do not proceed if a screen asks for information you did not expect.

Work out the exact IP addresses to allow

An IP allowlist means the exchange only accepts requests signed with that key when they arrive from an address on your list. The first job is finding the real outbound address of the machine or service that will call the API. If the bot runs on a home connection, the address is usually your internet provider's public address, and it can change when the router reconnects or the provider rotates it. If it runs on a rented server, the provider shows the address in the instance details. If it runs on a hosted bot platform, the platform publishes the addresses it sends requests from, and you must use those, not your own.

Collect addresses in the format the exchange's form expects, which is normally a single address or a range in the standard four-part notation, and note whether the field accepts several entries separated by commas. Some exchanges also let you restrict a key to a country or region instead of exact addresses; that is weaker than an address list, and you should treat it as a fallback rather than a first choice. If the tool's documentation does not state its outbound addresses, ask the tool's support before creating the key, because guessing will simply produce failed requests.

Plan for change. If your address is dynamic, decide now how you will notice a change and what you will do about it: either move the bot to a fixed address, or accept that you will update the allowlist when requests start failing. Record the address you entered, the date, and where you found it, so a future failure is a two-minute diagnosis instead of a mystery. Never widen the list to every address just to make an error go away; that removes the control you came here to set.

Trim permissions to the minimum and save the key

On the API creation screen, switch off everything the tool does not need. Read-only is the correct starting point for trackers, tax tools and dashboards. Enable spot trading only if the bot genuinely places or cancels spot orders. Futures or margin permissions should be enabled only if the tool trades those products and you have deliberately decided to allow it, and the futures documentation on the exchange explains what those permissions expose. Leave withdrawal permission off; if a tool insists on it, treat that as a reason to reconsider the tool.

Where the exchange offers an option to restrict the key to a specific IP list, enable it and paste the addresses you collected. Where it offers a separate switch for reading account data versus trading, set them independently rather than enabling a combined profile. If the screen shows a permission you do not recognise, open the help centre article for API management in a second tab and read what it does before ticking it. Take a screenshot of the final permission summary before you confirm, because some exchanges never show that summary again in the same form.

After saving, the exchange usually displays the key and the secret once. Copy them into the tool immediately, then store the secret in a password manager or the tool's own encrypted store, not in a plain text file, a chat message or a screenshot. If the secret is lost, you cannot recover it; you delete the key and create a new one. Also note whether the exchange supports restricting a key to certain account types, such as spot only, and set that if the tool does not need others.

Verify the key behaves as intended and keep it reviewable

Run a first test with the smallest possible action the tool supports, such as fetching a balance or listing open orders, and confirm it succeeds. Then test the boundary: try an action the key should not be allowed to perform, such as a withdrawal call or an order on a product you disabled, and confirm the exchange rejects it. A rejection is the result you want; it proves the permission trim took effect. If the forbidden action succeeds, delete the key immediately and rebuild it, because something on the creation screen was left enabled.

Check the exchange's API management page for the key's last-used time and any request logs it exposes, and compare that against when your tool actually ran. A key that shows activity when your tool was idle deserves investigation. If requests start failing after a working period, the two usual causes are a changed outbound address or an expired or rotated secret; check the address first, then the key status, before changing anything else.

Keep a short record for each key: the tool it belongs to, the permissions enabled, the addresses allowed, the date created, and where the secret is stored. Review that record when you stop using a tool, when you change hosting, or on a regular schedule you choose. Delete keys that belong to tools you no longer run. If your account offers a notification for API key creation or changes, turn it on so an unexpected key does not sit unnoticed. The help centre explains where those security notifications are configured.

Risk boundary: DeFi Protocol Guide

Digital assets are volatile and derivatives can amplify losses. This website has no login, wallet connection, deposit form or customer-support chat. A referral link only records attribution; it does not guarantee access, pricing, rewards, approval or investment results. Availability can differ by residence, legal entity and product, so no regional access is assumed from language or branding alone.

Scenario checkpoint

• Write down the single job the key must perform and the exact permissions that job requires before opening the API page.
• Find the true outbound IP address of the bot or service, and confirm whether it is fixed or can change.
• Disable withdrawal permission and any product permission the tool does not use.
• Paste the address list into the IP restriction field and save a screenshot of the final permission summary.
• Store the secret in a password manager or the tool's encrypted store, never in plain text.
• Test one allowed action and one forbidden action, then confirm the forbidden one is rejected.