Item descriptions

An asset represents an item in an inventory. Its description provides reusable display details, such as a name or icon. Several assets can share one description.

Match both classid and instanceid, not the display name. In this example, data is the data object from a successful V2 inventory response:

const descriptionByKey = new Map(
  data.descriptions.map((description) => [
    `${description.classid}:${description.instanceid}`,
    description,
  ]),
);

const items = data.assets.map((asset) => ({
  asset,
  description:
    descriptionByKey.get(`${asset.classid}:${asset.instanceid}`) ?? null,
}));

assetid is not part of this join. It identifies one owned instance, while many assets can share the same description key.

Treat descriptions as shared data

The example joins records from one response. If you cache descriptions across requests, include the game (app_id) and requested language alongside classid and instanceid in your cache key. This keeps different games and translations separate.

A description is not evidence of ownership. Keep the inventory's assets as the source of which items the user owns.

Render defensively

Treat optional display metadata as optional. Never infer ownership, tradability, or marketability from a label when the public schema provides an explicit field.

Localized names can change with the requested language and are not stable database keys. Keep the language and retrieval time with cached display metadata, and use the canonical identifier fields for joins.

Request the language your user needs. Changing the language changes display metadata, not which assets the user owns.

When a description is absent, keep the asset and show a fallback such as “Item details unavailable.” Do not drop the item from the inventory. The example returns null for that description so your interface can handle it explicitly.

See the Inventory response schema for available fields and Caching for freshness guidance.