# How the Binance.US API differs from the global platform

> Binance.US is a separate platform, not a regional skin: it has its own base URLs, account and keys, product coverage, limits, and documentation. Global endpoints may return HTTP 451 before authentication when the request comes from a restricted location.

- Source: https://papaproxy.net/blog/binance-us-api.php
- Published: 2026-08-01
- Author: Alex Young
- Category: API & data · PapaProxy.net Blog

---

## Key takeaways

- Binance.US uses `api.binance.us`, its own account and keys, a separate WebSocket API, and `wss://stream.binance.us:9443` for streams.
- The current US signing examples use HMAC-SHA256, while the global Spot API also supports RSA and Ed25519; shared route names do not guarantee identical authentication support.
- Request weight is shared per egress IP, order-rate limits are shared per account, and permissions or IP whitelisting rules are configured per key.
- Endpoint coverage is independently versioned: compare current docs and actual symbol sets instead of relying on a permanent “US-only” endpoint list or a total symbol count.
- HTTP 451 can be decided before authentication from the egress IP; use the platform that serves your jurisdiction and confirm that Binance.US supports your state or territory.
- Regional platforms do not all use `/api/v3`; Binance TR, for example, documents its own base URLs and `/open/v1` routes.

## Binance.US and the global platform at a glance

| Area | Binance.US | Global platform |
| --- | --- | --- |
| REST API | `https://api.binance.us` | `https://api.binance.com` |
| Account and keys | Separate Binance.US account and keys | Separate global account and keys |
| Signed requests | HMAC-SHA256 examples in current US docs | HMAC, RSA, and Ed25519 keys supported |
| WebSocket API | `wss://ws-api.binance.us:443/ws-api/v3` | Global WebSocket API hosts |
| WebSocket Streams | `wss://stream.binance.us:9443` | Global market-stream hosts |
| Product coverage | Spot, market data, wallet and US-specific services | Spot plus global products such as futures and options |
| Limits and endpoint weights | Defined by the US platform | Defined independently by the global platform |
| Primary documentation | `docs.binance.us` | Binance Developer Docs |

## Base URL and API keys

The first difference is configuration. REST calls go to `https://api.binance.us`, request-response WebSocket calls go to `wss://ws-api.binance.us:443/ws-api/v3`, and market or user-data streams use `wss://stream.binance.us:9443`. The path structure is familiar across much of Spot — many routes still use `/api/v3/...` — which is why SDKs can often support the platform by changing the exchange profile or host. In ccxt, for example, the platform has the separate exchange id `binanceus`.

Authentication is similar only within limits. The current US examples use HMAC-SHA256 for signed requests, while the global Spot API supports HMAC, RSA, and Ed25519 key types. An existing HMAC client can therefore be adapted more easily than a client built around a global-only authentication option, but endpoint and signature support should still be checked against the host being called.

A Binance.US API key belongs to a Binance.US account. Registration, identity verification, balances, permissions, and credentials are separate from the global platform, so keys do not cross over. Binance.US currently documents Exchange, Custodial Solution, and Credit Line key types; the Exchange key is the ordinary choice for trading and account data. KYC must be complete before a key can be created.

Three controls that are often mixed together should be separated. Request weight is accumulated per egress IP and shared by all connections from that address. Order-rate limits are maintained per account and shared by that account's API keys. Permissions and optional IP whitelisting belong to the individual key; Binance.US recommends IP whitelisting for security, but does not describe it as mandatory.

The Binance.US API documentation is its own site, with a mirrored repository and a separate changelog, and it's the only source that matches this platform's behavior. Reading global docs while calling the US host is the root of a surprising share of “the docs are wrong” bug reports.

## Endpoint coverage compared with the global platform

“Reduced set” is the usual description, and it is directionally correct but incomplete. Binance.US does not expose counterparts to the global futures and options products, so code built around `fapi` or options hosts cannot be moved over by changing one domain. Spot trading, market data, wallet operations, WebSocket API calls, streams, and OTC endpoints are present, but available symbols and endpoint details follow the US platform's own release cycle.

That release cycle matters because an endpoint can appear on one platform first and later reach the other. Binance.US added `GET /api/v3/myFilters` to expose account-specific filters such as `MAX_ASSET`; the global Spot API now has the same route. It is therefore safer to describe the APIs as overlapping but independently versioned, rather than treating any one endpoint as permanently exclusive.

The exchangeInfo endpoint is the practical starting point for the US Spot surface. Query it against the host you actually use to read the current rate-limit objects, symbol list, filters, and statuses. Binance.US raised its `REQUEST_WEIGHT` ceiling to 6,000 per minute, while older samples in the documentation still show the historical 1,200. The live response is what your client should trust:

BashCopy code

```bash
curl -s "https://api.binance.us/api/v3/exchangeInfo" | jq '.rateLimits'
```

Look for the `REQUEST_WEIGHT` object and read its `interval`, `intervalNum`, and `limit` fields. Endpoint prices also differ between platforms: the Binance.US changelog lists weights such as 25 for `trades` and `historicalTrades`, 4 for `aggTrades`, and 20 for `myTrades` when a symbol is supplied. A throttler copied from a global client can therefore miscount even when the route name looks identical.

A total symbol count is useful as a rough size check, but it does not tell you whether the pairs your application needs are available. Compare the actual symbol sets instead:

BashCopy code

```bash
curl -s "https://api.binance.us/api/v3/exchangeInfo" \
  | jq -r '.symbols[].symbol' | sort -u > binance-us-symbols.txt

curl -s "https://api.binance.com/api/v3/exchangeInfo" \
  | jq -r '.symbols[].symbol' | sort -u > binance-global-symbols.txt

# Present globally but absent from Binance.US:
comm -23 binance-global-symbols.txt binance-us-symbols.txt

# Present on Binance.US but absent from the global response:
comm -13 binance-global-symbols.txt binance-us-symbols.txt
```

Run the comparison only from infrastructure that is eligible to access both services. If the global request returns 451, do not treat the resulting empty file as a coverage result. Check the HTTP status first, then compare the set difference or grep the output for the exact symbols your integration requires.

## What HTTP 451 means

An error 451 response uses the HTTP status “Unavailable For Legal Reasons,” defined by RFC 7725. Binance returns it when the requested global service is not available for the location from which the request arrives. Because the decision can be made from the egress IP before authentication, a public endpoint may fail even when no API key is present.

Three properties make it confusing in practice. It's decided by the egress IP, not by your account — which is why it fires on public endpoints, before any key is checked, and why the same code works from your laptop and fails from your server. It applies to the whole host family, so `api`, `fapi`, and the stream hosts all answer the same way. And it can appear without any change on your side: managed platforms have hit it after a provider moved capacity, and single datacenters have started returning it while others in the same country kept working — the reports on Binance's own developer forum from hosted-bot users follow exactly this shape.

Diagnose it without credentials first:

BashCopy code

```bash
url="https://api.binance.com/api/v3/ping"

curl -sS \
  -D response-headers.txt \
  -o response-body.txt \
  -w "HTTP %{http_code}\n" \
  "$url"

printf '\n--- Headers ---\n'
cat response-headers.txt

printf '\n--- Body ---\n'
cat response-body.txt

printf '\n--- Egress IP ---\n'
curl -sS https://api.ipify.org && printf '\n'
```

Start with the status line. A `200` from `/api/v3/ping` rules out a current host-wide 451 for that egress path. A `451` on this public endpoint means changing or regenerating the API key will not fix the request, because authentication was not needed. Record the hostname, response body, egress IP, provider region, and time; then test the platform that actually serves the account.

The correct response is boring and legal: use the platform that serves your jurisdiction. If you are eligible for Binance.US and reside in a supported state or territory, use it with its own account and keys. Binance.US does not currently accept registration and verification from every US state or region, so check its current availability list instead of assuming that a US location is sufficient. If your infrastructure sits in a restricted region while you are not, move the workload to a region where you are eligible under the terms you agreed to. Routing around an eligibility check isn't a technical problem to solve — it's a violation of the terms that can cost you the account, and no amount of infrastructure makes it otherwise.

## Other regional platforms

The US is the most visible example of a wider pattern, but regional platforms do not share one universal API layout. Separate legal entities can mean different accounts, credentials, base URLs, route families, product coverage, and documentation. Treat each platform as a separate integration even when its naming and trading concepts look familiar.

The Binance TR API documentation shows why copying `/api/v3` assumptions is unsafe: it lists `https://www.binance.tr` as a base endpoint, uses routes under `/open/v1/...`, and assigns some APIs to `https://api.binance.me`. The Binance Japan API documentation and Japan-operated support pages should likewise be checked for current key, product, and endpoint support rather than inferred from the US or global platform.

The operational rule that survives regulatory and product changes is simple. First identify which entity holds the account. Then take the base URL, authentication method, discovery endpoints, symbols, weights, and limits from that entity's current documentation. A live `exchangeInfo` request is useful on Binance.US and the global Spot API, but it is not a universal discovery mechanism for every regional platform.

Two details are worth planning around when trading or data workloads run across regions. The first is a stable address: if you use IP whitelisting on a key, a dynamic egress can turn that safeguard into an outage. The second is that request-weight budgets belong to the platform and IP being used; workloads on another entity or host must be measured separately. That's the shape our [proxies for Binance](/target/binance-proxy-server/) fit: dedicated IPv4 addresses that stay static for the plan term, one per key or bot, with geo-targeting so an integration connects from the region where it's meant to run.