Дослідження з перевіркою джерел: Binance / Coinbase / GATE IO
Текст статті показано у перевіреному англійському оригіналі. Переклад буде додано після перегляду джерел.
Direct answer
Binance, Coinbase Exchange, Gate API v4 and OKX all publish rate-limit controls, but the accounting unit is not interchangeable. Binance combines request weight, order counts and IP-based enforcement; Coinbase documents token-bucket limits by IP or profile; Gate separates public, private, order, wallet and withdrawal buckets; OKX mixes IP, user, instrument and sub-account rules. A safe integration must model each endpoint's unit, window, burst behavior, headers or error codes and unknown-order recovery instead of copying a single requests-per-second number.
Показати менше
Verified source facts
1. Binance documents request-weight and order-count limits, returns 429 for exceeded limits, and may issue escalating IP bans with 418 after repeated violations. 2. Coinbase Exchange documents public REST limits by IP and private limits by profile using a lazy-fill token bucket with separate burst capacity. 3. Gate API v4 publishes separate buckets for public, private, order, cancellation, wallet and withdrawal endpoints and says repeated excess traffic may be delayed or declined. 4. OKX documents different rate-limit keys for public REST, private REST, WebSocket order management, instrument-level trading and aggregate sub-account requests.
Comparison at a glance
Таблиця статті: прокрутіть горизонтально або сфокусуйте область таблиці й використовуйте клавіші зі стрілками.
| Decision layer | What to inspect | Minimum safe action |
|---|---|---|
| Accounting key | IP, API key, profile, user, sub-account or instrument | store the exact key beside every endpoint |
| Time window | per second, per two seconds or rolling bucket | normalize without discarding burst semantics |
| Request cost | one call versus weighted request units | read the endpoint-specific cost |
| Order limit | new, amend, cancel and unfilled-order counters | track each counter independently |
| Burst | temporary capacity above steady state | use a client-side token bucket |
| Response signal | headers, error code, 429 or 418 | parse and retain the venue signal |
| Backoff | retry-after and exponential delay | stop automatic retries when status is uncertain |
| Unknown order | timeout does not prove failure | query order state before resubmitting |
| WebSocket | connection, subscription and inbound-message limits | budget reconnects separately |
| Operations | monitoring, alerts and safe degradation | define a venue-specific circuit breaker |
1. Control test: Accounting key
A trading-control disclosure is meaningful only when converted into a testable rule. For accounting key, inspect IP, API key, profile, user, sub-account or instrument. Use a sandbox, non-production context, or the smallest reversible test available, then store the exact key beside every endpoint. Capture configuration and event evidence without recording credentials, and verify the documented cancel, reject, decrement, or history behavior.
Model the failure path, not just the setup path. Ask which strategy owns the maker and taker orders, which account boundary the venue evaluates, which message reveals intervention, and how reconciliation behaves after a partial fill or disconnect. Platform documentation describes supported settings; it cannot prove that an operator configured them correctly. In this dimension, internal shared limits is therefore an explicit audit gap.
The accounting key row should end with a concrete monitoring rule tied to IP, API key, profile, user, sub-account or instrument. Make the operator store the exact key beside every endpoint, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; internal shared limits remains a separate production risk until observed.
2. Control test: Time window
For time window, inspect per second, per two seconds or rolling bucket. Use a sandbox, non-production context, or the smallest reversible test available, then normalize without discarding burst semantics.
In this dimension, dynamic tier changes is therefore an explicit audit gap.
The time window row should end with a concrete monitoring rule tied to per second, per two seconds or rolling bucket. Make the operator normalize without discarding burst semantics, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; dynamic tier changes remains a separate production risk until observed.
3. Control test: Request cost
For request cost, inspect one call versus weighted request units. Use a sandbox, non-production context, or the smallest reversible test available, then read the endpoint-specific cost.
In this dimension, future weight changes is therefore an explicit audit gap.
The request cost row should end with a concrete monitoring rule tied to one call versus weighted request units. Make the operator read the endpoint-specific cost, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; future weight changes remains a separate production risk until observed.
4. Control test: Order limit
For order limit, inspect new, amend, cancel and unfilled-order counters. Use a sandbox, non-production context, or the smallest reversible test available, then track each counter independently.
In this dimension, matching-engine exceptions is therefore an explicit audit gap.
The order limit row should end with a concrete monitoring rule tied to new, amend, cancel and unfilled-order counters. Make the operator track each counter independently, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; matching-engine exceptions remains a separate production risk until observed.
5. Control test: Burst
For burst, inspect temporary capacity above steady state. Use a sandbox, non-production context, or the smallest reversible test available, then use a client-side token bucket.
In this dimension, undocumented smoothing is therefore an explicit audit gap.
The burst row should end with a concrete monitoring rule tied to temporary capacity above steady state. Make the operator use a client-side token bucket, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; undocumented smoothing remains a separate production risk until observed.
6. Control test: Response signal
For response signal, inspect headers, error code, 429 or 418. Use a sandbox, non-production context, or the smallest reversible test available, then parse and retain the venue signal.
In this dimension, WAF ambiguity is therefore an explicit audit gap.
The response signal row should end with a concrete monitoring rule tied to headers, error code, 429 or 418. Make the operator parse and retain the venue signal, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; WAF ambiguity remains a separate production risk until observed.
7. Control test: Backoff
For backoff, inspect retry-after and exponential delay. Use a sandbox, non-production context, or the smallest reversible test available, then stop automatic retries when status is uncertain.
In this dimension, ban duration is therefore an explicit audit gap.
The backoff row should end with a concrete monitoring rule tied to retry-after and exponential delay. Make the operator stop automatic retries when status is uncertain, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; ban duration remains a separate production risk until observed.
8. Control test: Unknown order
For unknown order, inspect timeout does not prove failure. Use a sandbox, non-production context, or the smallest reversible test available, then query order state before resubmitting.
In this dimension, delayed execution is therefore an explicit audit gap.
The unknown order row should end with a concrete monitoring rule tied to timeout does not prove failure. Make the operator query order state before resubmitting, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; delayed execution remains a separate production risk until observed.
9. Control test: WebSocket
For websocket, inspect connection, subscription and inbound-message limits. Use a sandbox, non-production context, or the smallest reversible test available, then budget reconnects separately.
In this dimension, network disruption is therefore an explicit audit gap.
The websocket row should end with a concrete monitoring rule tied to connection, subscription and inbound-message limits. Make the operator budget reconnects separately, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; network disruption remains a separate production risk until observed.
10. Control test: Operations
For operations, inspect monitoring, alerts and safe degradation. Use a sandbox, non-production context, or the smallest reversible test available, then define a venue-specific circuit breaker.
In this dimension, production traffic shape is therefore an explicit audit gap.
The operations row should end with a concrete monitoring rule tied to monitoring, alerts and safe degradation. Make the operator define a venue-specific circuit breaker, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; production traffic shape remains a separate production risk until observed.
Decision scenarios
Scenario 1: when accounting key becomes decisive
Consider a reader whose main constraint is IP, API key, profile, user, sub-account or instrument. The correct response is not to infer a universal platform or product winner. It is to store the exact key beside every endpoint, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.
Scenario 2: when time window becomes decisive
Consider a reader whose main constraint is per second, per two seconds or rolling bucket. It is to normalize without discarding burst semantics, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 3: when request cost becomes decisive
Consider a reader whose main constraint is one call versus weighted request units. It is to read the endpoint-specific cost, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 4: when order limit becomes decisive
Consider a reader whose main constraint is new, amend, cancel and unfilled-order counters. It is to track each counter independently, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 5: when burst becomes decisive
Consider a reader whose main constraint is temporary capacity above steady state. It is to use a client-side token bucket, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 6: when response signal becomes decisive
Consider a reader whose main constraint is headers, error code, 429 or 418. It is to parse and retain the venue signal, retain the evidence, and define a stop condition before funds or permissions are committed.
Тематичні хаби й інструменти:Порівняти Binance і OKXAPI бірж і контроль ринкових даних
Джерела
04- General REST API Information · developers.binance.com
- REST Rate Limits Overview
- Gate API v4 Frequency Limit Rule · gate.com
- OKX API Rate Limits · okx.com