Tabfleet rate limits

Which limits are reported#

GET and POST /v1/sessions report the workspace browser-launch cooldown: at most one new launch per 20 seconds. The policy describes browser launches, not the number of GET requests you may make. An idempotent replay does not consume another launch. POST /v1/sessions/{id}/share reports the existing workspace-wide allowance of 60 viewer links per 60-second window. Other operations do not advertise a generic REST request quota. Authentication is required to see workspace-specific counters.

RateLimit and RateLimit-Policy#

Responses use the Structured Fields syntax from draft-ietf-httpapi-ratelimit-headers-11, which is an IETF Internet-Draft rather than a final RFC. RateLimit-Policy names a policy, q gives its quota and w its window in seconds. RateLimit uses the same name, r for remaining allowance, and t for seconds until the current counter resets. A t value of zero means no active cooldown or fixed window remains. These are snapshots, not reserved capacity: concurrent requests can change availability.

RateLimit-Policy: "browser-launch";q=1;w=20
RateLimit: "browser-launch";r=0;t=20

Retry-After and other constraints#

On a 429, honor Retry-After in seconds before another attempt; it takes precedence over quota hints. Browser concurrency, trial minutes, provider capacity, and shared service limits are separate constraints and can block work even when a reported quota remains. Read the JSON error code. A zero launch allowance does not prevent listing or closing browsers.

Retry a failed session creation using the same Idempotency-Key and identical options. Do not blindly repeat clicks, form submissions, or other mutations after an ambiguous failure. API browser clients on allowed dashboard origins can read RateLimit, RateLimit-Policy, Retry-After, and Link through CORS.