Limits & SLA
Monthly quotas by plan, what happens when you cross them, the operational rate limits that apply no matter what plan you're on, and our uptime commitment.
Monthly quotas
Quota is per calendar month (UTC), per event kind, per key. It resets at 00:00 UTC on the 1st.
| Plan | Embed loads | Renders | Inventory lookups | Over quota |
|---|---|---|---|---|
| Free | 5,000 / mo | 1,000 / mo | 500 / mo | Throttled: refused with 429 until next month |
| Starter | 100,000 / mo | 25,000 / mo | 10,000 / mo | Served, tracked for overage |
| Pro | 1,000,000 / mo | 250,000 / mo | 100,000 / mo | Served, tracked for overage |
| Enterprise | uncapped | uncapped | uncapped | n/a |
Free throttles at the cap instead of billing past it, on purpose: there's no card on file to bill
on a $0 plan. Every paid plan keeps serving requests past quota instead of cutting your site off; see
Pricing for the overage rates and their current status. A 429 on
the Free plan carries a Retry-After header with the exact number of seconds until the
reset.
Cached renders: counted, never billed
Cached renders count toward your monthly quota, but are never billed as overage. Both halves of that are true at once, and they answer two different questions:
- Quota is about value delivered. Every time your page showed a rendered skin, it counts as one render against the number you're paying for, whether that particular request happened to be a cache hit or triggered a fresh render. From your integration's point of view, a cache hit did exactly the same job as a fresh render.
- Overage is about cost incurred. Once you're past quota on a plan that bills overage, only a render that actually cost compute counts toward it: a genuinely fresh render. A cache hit, and a request that arrived while an identical render was already in flight and joined it, cost nothing extra. Neither is ever billable, even when it lands after your cap.
In practice, a popular listing whose image is requested constantly will burn through its render quota on cache hits alone (each one counts). Once you're on a paid plan, though, going over that quota never itself produces a bill. You're only ever charged for the renders among the overage that required real work, and see Pricing for whether that charge happens automatically yet.
Operational rate limits
These are separate from your monthly plan quota, and the same for every plan. They protect Steam's own per-IP rate limit and the render worker, which are shared resources.
| Surface | Limit |
|---|---|
| Inventory lookups | 5 cache misses / IP / minute; 12 lookups may be queued server-wide at once; a Steam 429 pauses all lookups for 60 seconds. See Inventory API. |
Renders (wait=1) |
8 distinct configs may be rendering at once; a blocking request waits up to 45 seconds before giving up. Non-blocking requests are never refused this way: they get the placeholder instead. See Render API. |
Origins per key
| Plan | Registered origins |
|---|---|
| Free | 2 |
| Starter | 5 |
| Pro | 20 |
| Enterprise | 100 |
Manage registered origins from the dashboard. A key with no origins registered is inert: it can't be embedded anywhere until you add at least one.
Uptime and catalog freshness
- 99.5% uptime, measured monthly.
- New CS2 cases are renderable within 7 days of release.