Overview
The PrometheX API uses BBR-based adaptive rate limiting (Bottleneck Bandwidth and Round-trip propagation time). Unlike fixed-window rate limiters, BBR dynamically adjusts limits based on server load and response times.How It Works
| Aspect | Detail |
|---|---|
| Algorithm | BBR adaptive rate limiting |
| Scope | Per IP + per authenticated user |
| Error code | 110103 (PLEASE_WAIT) |
| HTTP status | 429 Too Many Requests |
Rate Limit Guidelines
While the exact limits are adaptive, these guidelines will keep you within safe bounds:| Endpoint Type | Recommended Max | Notes |
|---|---|---|
| Public reads (market list, detail) | 30 req/s | Cacheable — consider local caching |
| Authenticated reads (positions, portfolio) | 10 req/s | Per user |
| Trading operations (buy, sell, claim) | 5 req/s | Per user |
| SSE connections | 1 concurrent | Per user |
| Bulk operations | 2 req/s | Rate-sensitive |
Handling Rate Limits
Exponential Backoff
When you receive a110103 error, retry with exponential backoff:
Best Practices
Cache responses
Cache market listings and details locally. Most public data changes infrequently.
Use SSE
Instead of polling for updates, subscribe to SSE events for real-time data.
Batch requests
Fetch multiple items per page instead of making individual requests.
Add jitter
Add random jitter to retry delays to avoid thundering herd problems.
Do’s and Don’ts
| Do | Don’t |
|---|---|
| Cache public market data | Poll /get-markets every second |
| Use SSE for real-time prices | Poll /get-market-detail in a tight loop |
Batch with pageSize=50 | Fetch one market at a time |
| Retry with exponential backoff | Retry immediately without delay |
| Use a single SSE connection | Open multiple SSE connections |
Monitoring
If you’re building a high-frequency integration, monitor your error rates:If you consistently hit rate limits and need higher throughput, contact the PrometheX team on Discord to discuss dedicated API access.

