Bond implements multiple types of rate limits to ensure fair usage and system stability. The /fapi/v1/exchangeInfo endpoint's rateLimits array contains objects related to RAW_REQUEST, REQUEST_WEIGHT, and ORDER rate limits. A 429 status code is returned when either rate limit is violated.

Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban (HTTP 418).

Rate Limit Types

REQUEST_WEIGHT

Scope

Per IP address

Mechanism

Each endpoint has a weight; heavier endpoints cost more

Tracking

Current used weight included in response headers

RAW_REQUESTS

Scope

Per IP address

Mechanism

Limits total number of requests regardless of weight

ORDERS

Scope

Per account (not per IP)

Mechanism

Limits number of orders in a given time period

IP Limits

Weight header

X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter)

On 429

Back off immediately; do not spam the API

Auto-ban

HTTP 418 for repeated violations

Ban duration

Scales from 2 minutes to 3 days for repeat offenders

Limit basis

Based on IPs, not API keys

Tip: Use WebSocket streams for real-time data to reduce REST API rate limit pressure.

Order Rate Limits

Header

X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter)

Scope

Per account

Note

Rejected/unsuccessful orders may not include order count headers

Response Headers

X-MBX-USED-WEIGHT-1M

Current used weight for 1-minute window

X-MBX-USED-WEIGHT-1H

Current used weight for 1-hour window

X-MBX-ORDER-COUNT-10S

Current order count for 10-second window

X-MBX-ORDER-COUNT-1M

Current order count for 1-minute window

Retry-After

Seconds to wait before retrying (included with 429)

Handling 429 Responses

When you receive a 429 status code:

Step 1

Stop making requests immediately

Step 2

Check the Retry-After header for recommended wait time

Step 3

Implement exponential backoff for retries

Step 4

Review your application's request patterns to reduce weight

{ "code": -1003, "msg": "Too many requests; current limit is 1200 requests per minute." }

Best Practices

Use WebSocket

WS connections don't count against REST rate limits

Request queuing

Queue and space out requests on your application side

Cache responses

Cache data that doesn't change frequently (e.g., exchange info)

Monitor usage

Track rate limit headers in every response

Optimize endpoints

Use bulk endpoints and lower-weight alternatives when possible

Example: Checking Rate Limit Headers

import requests response = requests.get('https://fapi.bond.xyz/fapi/v1/exchangeInfo') # Check rate limit headers used_weight = response.headers.get('X-MBX-USED-WEIGHT-1M') print(f"Used weight (1 minute): {used_weight}") # Check if approaching limit if int(used_weight) > 1000: print("Warning: Approaching rate limit!")