Rate limits

A rate limit controls how many requests a Service Account can make in a time window. SteamCall manages this limit. You can view it in the Dashboard, but cannot change it yourself; contact support if your application needs a review.

Use the rate-limit response headers and documented 429 errors to decide when to wait. Coordinate requests across workers instead of letting each process retry independently.

Cache repeated reads and avoid polling faster than your product freshness requirement.

Share one budget

A Service Account has one shared request limit across all of its active Credentials. A per-process counter cannot see calls from other workers, scheduled jobs, deployment replicas, or sibling Credentials. Coordinate every Credential for the same Service Account against that shared budget, or deliberately partition work so aggregate traffic remains bounded.

Respond to exhaustion

When the API rejects a request for rate limiting, stop immediate retries. Use the documented reset metadata to schedule later work and add randomized jitter so a fleet does not resume at once.

For operations that return them, X-RateLimit-Limit gives the shared requests-per-minute limit, X-RateLimit-Remaining gives requests left in the current window, and X-RateLimit-Reset gives seconds until reset—not a Unix timestamp. Check the operation's API Reference for its response headers. See Retries & timeouts for bounded retries.

Observe useful dimensions

Track operation, outcome, and wait duration without using raw keys as labels. Alert on sustained rejections and queue age; a single bounded rejection can be normal backpressure.

Caching and request coalescing often reduce rate pressure more safely than increasing concurrency. See Caching and Prepare for production.