Rate limits

The budget

Requests are counted per principal (Service Account) in a fixed one-minute window. Rejected requests still count. A 429 consumes budget, so exceeding the limit repeatedly keeps requests rejected for the remainder of the window. Back off on a 429; do not retry immediately.

The rate limit is 60 requests per minute per principal.

Exceeding the limit

HTTP/1.1 429 Too Many Requests
Retry-After: 23

{ "error": { "code": "rate-limited", "message": "…" } }

Wait the Retry-After seconds (the remainder of the current window), then resume. The response body is the standard error envelope.

Staying under the limit

• Use batches. One GET /creators?ids=… with 100 identifiers is one request; 100 single reads are 100. Batch endpoints exist so list workloads do not spend the budget one item at a time.
• Honour Retry-After on 202s. The polling interval is server-controlled; polling faster than instructed spends budget without returning data sooner.
• Windows are fixed, not sliding. A burst that straddles a window boundary can briefly exceed the per-minute figure; this behavior should not be relied upon.