Skip to main content

​
The limit

Each API key has a request rate limit: The limiter counts requests, not bytes and not endpoint cost. A small metadata read and a large download both consume one request.

​
What happens when you exceed it

The rejection happens after authentication and bucket-scope checks, but before the route handler runs. No file operation is performed. No Retry-After header is documented. Do not depend on one.
1

Stop immediately on 429

Do not continue a tight retry loop. Each rejected request still represents load.
2

Back off with jitter

Start around one second, double up to a ceiling (for example 30 seconds), and add random jitter so concurrent workers do not retry in lockstep.
3

Reduce concurrency

If 429s persist, lower the number of parallel workers using the same key. The limit is per key, not per process.
4

Split by workload

Give independent services their own keys so one burst does not starve another integration.

​
Fail-open behavior

If the limiter’s Redis backing store is unavailable, the limiter fails open: requests are allowed rather than rejected. This avoids turning a cache outage into an API outage, but it means the limit is not enforced during that window. Do not design your integration to rely on the limiter for safety. It is a fairness control, not an authorization or billing control.

​
Limits are not the same as quotas

A 429 is temporary. A trial quota or subscription failure requires an account change.

​
Bulk operations

For large migrations:
  • Use one key per migration job.
  • Process files sequentially or with low concurrency.
  • Prefer listing endpoints with larger page sizes to reduce request count, within documented maximums.
  • Pause between batches rather than relying on retries after 429.
  • Record progress so a failed batch can resume without duplicating uploads.

​
Monitoring

Track at least:
  • request rate per key,
  • 429 count and ratio,
  • p95 and p99 latency,
  • upload failure rate by status,
  • trial remaining, if applicable.
Alert on sustained 429 ratios rather than individual spikes. A brief spike during a deployment is normal; a sustained 5% rejection rate is not.

​
When to request a higher limit

If your workload is legitimate and consistently near the limit, contact support@everabyte.com with:
  • company ID,
  • key public prefix,
  • expected requests per minute,
  • endpoint mix,
  • business justification.
Do not create many keys to circumvent the limit. That fragments auditability and does not change the underlying capacity.