Concurrency
ScreenshotOne concurrency is calculated as the number of screenshot requests your organization can start during the current one-minute period.
It is not calculated from the full lifecycle of a request. A request does not occupy concurrency until it finishes rendering. Instead, starting an accepted request consumes one request from the current one-minute bucket.
How it works
At a high level:
- Your organization has a plan limit, for example 40 requests per minute.
- At the start of a one-minute bucket, that many request starts are available.
- Each accepted screenshot request spends one request start from the bucket.
- If the bucket still has request starts available, the API accepts the request.
- If the bucket is empty, the API returns
concurrency_limit_reached. - When the bucket resets, the available request starts are restored.
For example, if your plan allows 40 requests per minute, you can start up to 40 screenshot requests during the current bucket. They can be started gradually or in a short burst. Once those 40 request starts are used, wait for the next reset before starting more.
What this means
Concurrency is closer to requests per minute than to active in-flight renders.
If your requests take 10 seconds to finish, they do not return capacity when they complete. Capacity returns when the one-minute bucket resets. If your requests take longer than one minute, the next bucket can still become available while older requests are finishing.
Check the current bucket
Use the usage endpoint to read the current bucket:
concurrency.limit: how many requests can start in the bucket;concurrency.remaining: how many requests can still start before reset;concurrency.reset: when the bucket resets.
For bulk or queue-based workloads, drain up to concurrency.remaining requests into the API, then wait until concurrency.reset before sending more.
Related errors
If the current bucket has no remaining request starts, the API returns concurrency_limit_reached.