Live inventory page

Live Page contacts Steam during your request and returns one inventory page. Use it for one-off previews, bounded partial reads, or compatibility with an existing page-by-page integration.

For a complete inventory collected for you, use Refresh followed by Current. See the Live Page API Reference for all parameters and response fields.

Request inputs

• steam_id identifies the Steam account.
• app_id identifies the Steam application.
• context_id identifies the inventory context.

Public visibility is controlled by Steam. A valid request can still return a documented privacy outcome when the upstream inventory is private.

Why context 2 is the usual inventory

Steam separates an application's items into numbered contexts. For Team Fortress 2, app_id=440 identifies the game and context_id=2 is the ordinary player backpack. Treat the pair as one identity: do not copy context 2 to another game unless that game's documentation explicitly says it uses the same context.

Make the request

Set STEAMCALL_API_KEY to your Credential secret in your server environment and replace the example Steam ID with the inventory you want to read. The response below uses synthetic data.

curl --fail-with-body --max-time 15 \
  'https://api.steamcall.com/v2/steam/users/76561198000000000/inventory/440/2?language=english' \
  --header "X-API-Key: $STEAMCALL_API_KEY"

This example shows prepaid credit funding. Subscription-funded requests use the applicable Inventory allowance; see Usage & credits for the distinction.

Full 200 response

{
  "data": {
    "assets": [
      {
        "amount": "1",
        "appid": 440,
        "assetid": "123456789",
        "classid": "101",
        "contextid": "2",
        "instanceid": "0"
      }
    ],
    "descriptions": [
      {
        "appid": 440,
        "classid": "101",
        "instanceid": "0",
        "market_hash_name": "Mann Co. Supply Crate Key",
        "tradable": 1
      }
    ],
    "pagination": {
      "has_more": false
    },
    "total_count": 1
  },
  "meta": {
    "credits_charged": 1,
    "credits_remaining": 999,
    "price_version": 1,
    "product_code": "steam.inventory.page.v1",
    "rate_limit": {
      "limit_per_minute": 120,
      "remaining": 119,
      "reset_seconds": 60
    },
    "request_id": "req_01JEXAMPLE"
  },
  "success": true
}

What the important fields mean:

• assets are the individual owned item instances. assetid identifies this particular item in this inventory.
• descriptions are reusable metadata. Match an asset to a description with the same classid and instanceid.
• total_count is Steam's count for the complete inventory, not necessarily the number returned on this page.
• pagination.has_more tells you whether another page exists. Pass pagination.next_cursor back unchanged when present.
• meta.request_id is safe correlation evidence for logs and support; the remaining meta fields explain billing and rate limiting.

When Live Page is the right choice

• You need only the first one or two Steam pages.
• You need an immediate upstream observation and accept Steam latency/failure in that request.
• You are adapting an existing integration that already owns complete traversal and persistence.

Do not use Live Page as the default read path for a stateful inventory product. Every page contacts Steam, and different customers' cursor chains cannot be combined. Use Refresh when your workflow needs a refresh_id you can use to check collection progress and the final charge.

Does Live Page update Current?

A successful Live Page response does not guarantee a saved complete revision. Optional capture can save one after the same customer reads every page of a supported TF2 inventory, from the first page through the terminal cursor, in order and within the scan deadline, with all pages successfully billed. Partial or failed traversals do not publish a revision. Use Refresh when your application needs an explicit completion result instead of relying on capture.

Reliability

Use a bounded timeout and retain X-Request-ID. Do not fan out unbounded concurrent requests for the same inventory.

Interpret the outcome

A successful empty inventory, a private inventory, and a transient upstream failure are different states. See their complete worked shapes before deciding whether to publish new data, preserve an older snapshot, ask the user to change privacy settings, or retry.

For inventories that span pages, continue with Pagination. For a complete application workflow, read Build an inventory integration.