Rate Limits and Caching

Rate Limits and Caching

Steam can throttle or reject excessive requests, and availability can vary by endpoint and key type. Do not rely on a single undocumented numeric limit for every service.

Cache suitable data

Suggested starting points—not Steam guarantees:

Data	Example cache period
Player summary	2–5 minutes
Friends and owned games	5–15 minutes
App or package metadata	Several hours
Achievement schema	12–24 hours
Current player count	30–60 seconds
Supported API list	Several hours

Choose durations based on product needs and shorten them when users expect privacy or profile changes to appear quickly.

Laravel example

use Illuminate\Support\Facades\Cache;

$games = Cache::remember(
    "steam:games:{$steamId}",
    now()->addMinutes(10),
    fn () => $steam->player($steamId)->GetOwnedGames(),
);

Retry policy

Retry only transient failures such as selected 429 and 5xx responses.

• use exponential backoff with jitter;
• set a maximum attempt count;
• respect a Retry-After header when present;
• do not retry invalid IDs, invalid keys or permission failures indefinitely;
• avoid retry storms during Steam outages.

Timeouts

Inject a configured Guzzle client:

use GuzzleHttp\Client as HttpClient;
use TeemoCell\SteamWebApi\Client;

$steam = new Client(
    apiKey: $apiKey,
    client: new HttpClient([
        'connect_timeout' => 5,
        'timeout' => 10,
    ]),
);

Large imports

Run full app-list or Workshop imports as queued or scheduled jobs. Add checkpoints, deduplication and bounded concurrency. See Pagination.