Rate Limits

The XBTFX Trading API uses a weight-based rate limiting system to ensure fair usage and platform stability. Each API key has a shared budget of 600 weight per minute.

How It Works

Every endpoint has an assigned weight. Each request consumes that weight from your per-minute budget. When the budget is exhausted, further requests receive a 429 Too Many Requests response until the window resets.

Endpoint Weights

Endpoint	Method	Weight
/v1/auth/status	GET	1
/v1/account	GET	1
/v1/symbols	GET	2
/v1/symbols/:symbol	GET	1
/v1/trade	POST	1
/v1/close	POST	1
/v1/modify	POST	1
/v1/positions	GET	1
/v1/orders	GET	1
/v1/history	GET	1
/v1/close-all	POST	10
/v1/close-symbol	POST	10
/v1/close-by	POST	1
/v1/reverse	POST	1

Response Headers

Every response includes rate limit headers so you can track your usage:

Header	Description
X-RateLimit-Budget	Total weight budget per minute (600)
X-RateLimit-Used	Weight consumed in the current window
X-RateLimit-Remaining	Weight remaining in the current window
X-RateLimit-Weight	Weight consumed by this specific request

Rate Limit Exceeded

When you exceed the budget, the API returns HTTP 429:

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded",
  "retry_after_sec": 12
}

The retry_after_sec field tells you how many seconds to wait before retrying.

Best Practices

• Monitor headers. Check X-RateLimit-Remaining in responses to avoid hitting the limit.
• Use WebSocket for quotes. Streaming prices over WebSocket does not consume REST rate limit budget.
• Cache symbol data. Symbol specifications change infrequently. Cache the response from /v1/symbols instead of fetching on every trade.
• Batch closes. Use /v1/close-all or /v1/close-symbol instead of closing positions individually when you need to exit multiple positions.
• Back off on 429. Wait for the retry_after_sec duration before retrying. Do not retry in a tight loop.