List items for sale
Puts backpack items on the market. Each group in listings becomes one listing at the given price in cents; items holds backpack item ids (the id from GET /public/v1/backpack) with the quantity of each to sell. Identical commodity items grouped together sell as one stack. A commodity backpack row is a quantity rather than a single copy, so the same id may appear in several groups — that is how you get separate listings for copies of one item at the same price; the groups draw from one pool, and asking for more than the row's amount in total fails with INSUFFICIENT_ITEMS. At most 50 groups per request, 50 items per group. Send price_decay instead of price on a group to list it with an auto-decaying price: it starts at start_price and falls to end_price over total_hours (24-168). To sell something still sitting in Steam, use POST /public/v1/sell instead. Accounts have a ceiling on how much they can have listed at once; past it, listing fails with LISTING_LIMIT_REACHED. Contact support if you are hitting it.
Authorization
apiKey API key generated from your account settings on the website. Send as Authorization: Bearer csd_....
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
curl -X POST "https://example.com/public/v1/list" \ -H "Content-Type: application/json" \ -d '{ "listings": [ { "items": [ { "id": 1, "amount": 1 } ], "price": 1 } ] }'{ "listings": [ { "id": 1, "app_id": 1, "market_hash_name": "string", "price": -9007199254740991, "amount": -9007199254740991, "commodity": true, "created_at": "2019-08-24T14:15:22Z" } ]}Edit a listing PATCH
Changes the `price` (cents) or `amount` of your active listings. Send a single listing body, or a `listings` array of up to 50 to edit in bulk. The per-listing semantics are identical either way. In bulk each listing is applied in its own transaction, so a failure affects only that row: every entry comes back in `results` with `ok` and, when it failed, the `error` code the single form would have returned, in the order you sent them. Send either field or both. Send `price_decay` instead of `price` to put the listing on an auto-decaying price, falling from `start_price` to `end_price` over `total_hours` (24-168); it behaves like `price` for everything below, including the partial reprice. Raising `amount` takes more of the same item from your backpack. Lowering it returns the surplus to your backpack, *unless* you send `price` at the same time, which is a partial reprice: the listing keeps the `amount` you asked for at the new price and the surplus stays on the market in a new listing at the old price, so repricing part of a stack never takes the rest off sale. Sending `price` is what decides this, not whether the value changed, so re-sending the price a listing already has still splits rather than returning anything. Send `amount` on its own to pull copies back to your backpack, and leave `amount` out entirely when you only want to change the price: that reprices the whole stack in place, which is what a price updater wants. The response is always the listing you edited; find the new one through `GET /public/v1/my-listings`.
Value of your listings GET
What your active listings are worth at their asking prices: `total_value` in cents, across `listing_count` listings holding `item_count` items. Optional `app_id` filter. The v1 equivalent was `ISales/GetActiveListingsValue`.