Errors and limits

Application errors

Several routes report failure inside an HTTP 200 response. A buy-order rejection can return success: 25 with a human-readable message, for example when the account exceeds its wallet-based active-order limit.

{
  "success": 25,
  "message": "This buy order cannot be placed …"
}

Treat success: true and success: 1 as success only for endpoints documented with those shapes. Numeric codes are endpoint-specific.

Null payloads

The structured search and listing POST endpoints can return literal JSON null with HTTP 200. Accept null as a transient or empty response and retry with bounded backoff.

Redirects and HTML

Page and eligibility routes can return 302. Routes normally used for JSON can return HTML when redirected, challenged, logged out, or rendered through a different frontend path. Validate Content-Type before decoding.

Confirmations

A successful sell request can still require account confirmation. Inspect:

• requires_confirmation;
• needs_mobile_confirmation;
• needs_email_confirmation.

The item is not necessarily active until confirmation completes.

Rate control

Steam publishes no limits for these routes. The figures below are the community's working consensus, not a contract, and they are enforced per client rather than per endpoint family:

The histogram limit counts distinct item_nameid values, not requests, so re-polling a small watchlist is far cheaper than sweeping the catalog. Budget it deliberately: it is the only route that exposes live buy-order depth.

Use conservative concurrency, cache immutable metadata, add jittered exponential backoff, and stop on repeated 429 or 5xx responses. Do not rotate accounts or IPs to evade enforcement.