Create one under account → API keys. You choose the permissions when you create it, and you can restrict it to a list of addresses.

permission	what it allows
read	Your account, positions, orders, trades and income. Changes nothing.
trade	Place and cancel orders, set leverage and margin type.
transfer	Move money in and out of the account.

The secret is shown once, at creation. We store a hash of it and cannot show it to you again; if you lose it, revoke the key and create another.

A key cannot create or revoke keys, change your password, or manage your sessions — those need the password behind a browser session. That is deliberate: otherwise a leaked read-only key becomes a trading key in two steps.

Every authenticated request carries:

where	name	what
header	X-MBX-APIKEY	The key. Not the secret.
parameter	timestamp	Milliseconds since the epoch.
parameter	recvWindow	Optional. Milliseconds. Default 5000, maximum 60000.
parameter	signature	Lowercase hex HMAC-SHA256, under the secret, of everything else. Sent last.

Sign the bytes you send, in the order you send them. The payload is the query string (or the form body) exactly as it goes on the wire, with signature removed — not a re-encoding of a parsed object. If you build the string, sign that same string, and send it unchanged, you cannot get this wrong. If you sign a re-serialisation, a different parameter order or a differently-escaped space will produce a payload you never sent.

GET parameters go in the query string; POST and DELETE parameters go in the query string too.

curl -H "X-MBX-APIKEY: $KEY" \
  "$BASE/fapi/v2/balance?timestamp=$TS&signature=$SIG"

# where
TS=$(date +%s000)
SIG=$(printf 'timestamp=%s' "$TS" | openssl dgst -sha256 -hmac "$SECRET" -r | cut -d' ' -f1)

import { createHmac } from 'node:crypto';

function signed(params, secret) {
  const q = new URLSearchParams({ ...params, timestamp: Date.now() }).toString();
  return `${q}&signature=${createHmac('sha256', secret).update(q).digest('hex')}`;
}

There is no /fapi/v1/time yet. Binance publishes one and most client libraries call it at startup to measure their clock offset. We do not serve it, so if your clock is more than recvWindow out you will get -1021 on every request. Check your clock first. Raising recvWindow works but widens the window in which a captured request can be replayed.

no credential

read

trade

Send newClientOrderId. Binance has no request-id parameter, so we use yours as one: retrying a placement that timed out with the same id returns the original order instead of opening a second position. Without it, a retry is a new order — which is Binance's behaviour too, and the reason this is worth saying.

transfer

operator

House endpoints. They need an operate key, which a client account cannot create — listed so the surface is complete, not because you can call them.

Binance's codes, with Binance's meanings, so an existing client's error branch needs no change. Every failure is { "code": …, "msg": … }.

• We are the counterparty. There is no order book of other clients and no public trade tape, so there is no /fapi/v1/depth or /fapi/v1/trades. /broker/v1/quote/{symbol} is our price.
• Anything of ours that is not in Binance's API lives under /broker/v1/. We add no fields to a /fapi/ response, so a strict client will not trip over them.
• No /fapi/v1/time yet.
• No websocket user stream yet. Poll /fapi/v2/positionRisk and /fapi/v1/userTrades.