Banata

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

EndpointRateBurst
POST /v1/browsers60/min20
GET /v1/browsers600/min100
DELETE /v1/browsers120/min30

Sandbox endpoints

EndpointRateBurst
POST /v1/sandboxes60/min20
GET /v1/sandboxes600/min100
DELETE /v1/sandboxes120/min30
POST /v1/sandboxes/exec300/min50
POST /v1/sandboxes/code300/min50
GET /v1/sandboxes/terminal600/min100
File system operations (fs/read, fs/write, fs/list)300/min50
POST /v1/sandboxes/opencode/prompt300/min50

Billing endpoints

EndpointRateBurst
GET /v1/usage30/min10
GET /v1/billing30/min10
POST /v1/billing/checkout5/min2

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:

typescript
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.

Use exponential backoff with jitter:

typescript
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/sdk SDK handles retries automatically with exponential backoff and jitter. It respects the Retry-After header 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