Platform
Rate Limits
Per-organization rate limits for all Banata API endpoints, how they work, and how to handle 429 responses.
All API endpoints are rate-limited per organization. Rate limits protect the platform and ensure fair resource allocation.
Limits by Endpoint
Browser endpoints
| Endpoint | Rate | Burst |
|---|---|---|
POST /v1/browsers | 60/min | 20 |
GET /v1/browsers | 600/min | 100 |
DELETE /v1/browsers | 120/min | 30 |
Sandbox endpoints
| Endpoint | Rate | Burst |
|---|---|---|
POST /v1/sandboxes | 60/min | 20 |
GET /v1/sandboxes | 600/min | 100 |
DELETE /v1/sandboxes | 120/min | 30 |
POST /v1/sandboxes/exec | 300/min | 50 |
POST /v1/sandboxes/code | 300/min | 50 |
GET /v1/sandboxes/terminal | 600/min | 100 |
File system operations (fs/read, fs/write, fs/list) | 300/min | 50 |
POST /v1/sandboxes/opencode/prompt | 300/min | 50 |
Billing endpoints
| Endpoint | Rate | Burst |
|---|---|---|
GET /v1/usage | 30/min | 10 |
GET /v1/billing | 30/min | 10 |
POST /v1/billing/checkout | 5/min | 2 |
Rate is the sustained requests per minute. Burst is the maximum number of requests that can be made in a quick spike.
Handling Rate Limit Responses
When you exceed a rate limit, the API returns:
HTTP/1.1 429 Too Many Requests
Retry-After: 3
{ "error": "Rate limit exceeded. Please try again later." }The Retry-After header tells you how many seconds to wait before retrying.
Recommended retry strategy
Use exponential backoff with jitter:
async function fetchWithRetry(url: string, options: RequestInit, maxRetries = 3) {
for (let attempt = 0; attempt < maxRetries; attempt++) {
const response = await fetch(url, options);
if (response.status !== 429) {
return response;
}
const retryAfter = parseInt(response.headers.get("Retry-After") || "1", 10);
const jitter = Math.random() * 0.25; // 0–25% jitter
const delay = retryAfter * 1000 * (1 + jitter) * Math.pow(2, attempt);
await new Promise((r) => setTimeout(r, delay));
}
throw new Error("Rate limit exceeded after retries");
}Tip: The
@banata-boxes/sdkSDK handles retries automatically with exponential backoff and jitter. It respects theRetry-Afterheader and retries on both 429 and 5xx responses.
Tips for Staying Within Limits
Polling frequency
When polling for session status, 1-second intervals are typical. The GET endpoints have generous 600/min limits, so polling several sessions per second stays well within bounds.
CDP and WebSocket traffic is not rate-limited
Once a browser session is ready, all CDP interaction happens over the WebSocket connection, not the REST API. CDP commands do not count against rate limits.
Similarly, sandbox terminal sessions use WebSocket connections that are not rate-limited after the initial connection.
Batch management
If you need to create many sessions, space your requests to stay within the 60/min creation limit. For higher throughput, contact support about custom rate limits.
Next Steps
- API Reference — Full endpoint documentation
- Billing & Plans — Plan limits and usage tracking
- Browser Sessions — Session creation options