Creating the Binance API key

Which permissions the platform actually uses, why the IP allowlist is mandatory rather than advisable, where the credentials go, and how to rotate them without an outage.

5 min readUpdated 3 August 2026binance, api-key, permissions, ip-allowlist, security

The API key you create here is not a read-only integration credential. It places orders, moves customer deposits and — if you enable it — sends money out of your Binance account to addresses your customers type in. Treat it as the most sensitive secret on the install, alongside the database password.

Create the key on Binance

Open API Management. Log in at binance.com, open the profile menu and choose API Management, then Create API.
Choose a system-generated key and give it a label that identifies this install — the hostname is a better label than the product name, because you will eventually have more than one.
Complete verification. Binance asks for email, SMS and 2FA confirmation before it will show you the secret.
Copy the secret now. Binance shows it exactly once. If you lose it the only path is deleting the key and creating another.
Set the permissions and the IP allowlist before you leave the page. Both are covered below.

Permissions

The platform calls a specific and small set of Binance endpoints. Grant what those need and nothing more.

Binance permission	Needed	What stops working without it
Enable Reading	Yes	Everything. Market load, balances, deposit history, withdrawal history
Enable Spot & Margin Trading	Yes	Customers cannot place orders — order creation fails at the exchange
Enable Withdrawals	Only if payouts should leave automatically	Approved withdrawals fail at the exchange and the customer is credited back
Permits Universal Transfer	No	Nothing. The platform never transfers between Binance accounts on Binance
Enable Futures	No	Nothing. This provider is spot only — the row's `type` is `spot`
Enable Margin	No	Nothing. Orders are placed as plain spot orders with no margin parameters

A key with reading and spot trading is enough to run markets, charts, orders and deposit address issuance. It is not enough to pay a customer out. If you would rather move money by hand, leave the withdrawal permission off deliberately and process payouts from the Binance interface — but then turn off withdrawal auto-approval on the platform too, or every request will fail at the exchange and be refunded automatically.

Note also the transfer sub-account behaviour: the KuCoin connector performs an internal transfer before withdrawing, because KuCoin separates its main and trade accounts. The Binance path does not — it withdraws directly from the spot balance. So the spot balance is the only balance that matters, and funds parked in Earn, Funding or a sub-account are invisible to the platform.

The IP allowlist

This is not hardening. It changes what the key can do.

Binance only permits withdrawals from keys that are restricted to specific IP addresses. An unrestricted key can read and trade, and its withdrawal calls will be refused no matter what permission box you ticked. Unrestricted keys are also retired by Binance on its own schedule, which produces the worst kind of outage — one that arrives weeks after the last configuration change.

Allowlist the server's outbound IP. Three ways to get that wrong:

The domain's IP is not necessarily the server's egress IP. Behind a CDN or a proxy they are different addresses. Ask the server itself what address it presents, from the box, over the same path the backend uses.
If you configure an outbound proxy on the provider, allowlist the proxy. The proxy is what Binance sees. Your own IP becomes irrelevant.
IPv6 is the silent case. Without a proxy the connector forces IPv4 on its outbound agent precisely because allowlists are IPv4 and a dual-stack box that prefers IPv6 presents an address nobody allowlisted. If you place a proxy in front, that guarantee moves to the proxy and becomes yours to maintain.

If your Binance account also restricts withdrawals to whitelisted destination addresses, customer withdrawals to arbitrary addresses will fail at the exchange. That is an account-level setting, not a key setting, and it is incompatible with self-service withdrawals.

Where the credentials go

Into the project root .env, and nowhere else. They are never written to the database, never rendered in the admin panel and never returned by an API.

APP_BINANCE_API_KEY="your_api_key"
APP_BINANCE_API_SECRET="your_api_secret"

Binance API key.

Binance API secret.

Binance needs no third value. The passphrase variable exists for providers that require one — the admin screen only lists APP_BINANCE_API_PASSPHRASE when the active provider is KuCoin — and setting it for Binance does nothing.

The names are assembled at runtime from the active provider's alias, so a misspelt variable is indistinguishable from an absent one: the connector logs that credentials are missing, counts a failed attempt, and after three failures refuses to retry for thirty minutes.

What the key is used for

Every authenticated call the platform makes, and the feature it serves:

Call	Used by
`loadMarkets`, `fetchMarkets`	Market import, order validation, the fee comparison screen
`fetchCurrencies`	Spot currency import — a signed call on Binance, so it returns an empty set on an unauthenticated connection
`fetchTickers`	The market list ticker stream
`watchTicker`, `watchOHLCV`, `watchOrderBook`	The trade screen's live feeds
`fetchOHLCV`	Chart cache build
`createOrder`, `fetchOrder`	Customer order placement
`fetchBalance`	Credential verification, the admin balance screen, the pre-flight check before a withdrawal
`fetchDepositAddressesByNetwork`, `fetchDepositAddresses`, `fetchDepositAddress`	Issuing a deposit address to a customer
`fetchDeposits`	Confirming a customer's deposit
`withdraw`, `fetchWithdrawals`	Paying a customer out, and reconciling stranded payouts

Rotating a key

Rotation is a restart, not a hot swap. The connector caches one live Binance instance per provider for the lifetime of the process.

Create the new key on Binance with the same permissions and the same IP allowlist. Do not delete the old one yet.
Edit .env and replace both values.
Restart the backend and the cron worker.
```
pm2 restart backend cron
```
Verify on /admin/finance/exchange. A green result means markets loaded and the balance call succeeded with the new key.
Delete the old key on Binance once verification passes.

Expect a short window during the restart where the ticker stream, order placement and deposit polling are unavailable. Nothing is lost — the deposit verifier retries, and a customer order that never reached Binance never debited a wallet.

Security notes that are specific to this integration

The verify button round-trips the live key. It builds a fresh connection, loads markets, fetches the balance and closes. It is deliberately not on the admin audit trail, because it changes nothing — saving the key is the audited action, and saving happens in .env, outside the panel entirely.

Exchange names are scrubbed from customer-facing errors. When an order fails the message is sanitised before it leaves the API, replacing the provider's name with asterisks. Your customers do not learn which venue backs the platform from an error message. Your logs still record it in full.

A proxy URL with embedded credentials is masked on read. The provider row returns *** in place of the userinfo, so the value in the input box is not the value in the database. Re-typing the full URL is the only way to change it.