BUFF sale history is now available - POST /v1/archive/buff returns sale prices and daily total supply since September 2024.

How to Compare Steam and CSFloat Sales History

Steam and CSFloat both publish completed-sale history, and they are the two most complete sale records in CS2. They are also not directly comparable: Steam reports a median in Steam Wallet funds, CSFloat reports an arithmetic average in cash. The comparison is worth making, but only once both differences are handled explicitly.

This is the closest thing CS2 has to a locked-in versus cash price signal, which is why it gets asked for constantly and why it is so easy to get wrong.

The two datasets#

Steam CSFloat
Endpoint POST /v1/archive/steam POST /v1/archive/csfloat
Coverage Daily from April 26, 2013 Daily from 2022
Price statistic Median sale price Arithmetic average of that day's sales
Volume field volume, purchase count volume, sale count
Day key bucket, a full timestamp date, a YYYY-MM-DD string
Intervals 1h, 1d Daily only, no interval parameter
Variants Not supported Supported, under variants
Settlement Steam Wallet funds Cash
Refresh About 1-4x per day About 1-2x per day
Access Scale or Enterprise Scale or Enterprise

Four of those rows will break a naive join: the statistic, the key name, the variant support, and the settlement currency.

Request both series#

bash
curl -X POST https://api.cs2.sh/v1/archive/steam \
  -H "Authorization: Bearer <<YOUR_API_KEY>>" \
  -H "Accept-Encoding: gzip" --compressed \
  -H "Content-Type: application/json" \
  -d '{
  "items": ["USP-S | Printstream (Factory New)"],
  "start": "2026-04-27",
  "interval": "1d"
}'
bash
curl -X POST https://api.cs2.sh/v1/archive/csfloat \
  -H "Authorization: Bearer <<YOUR_API_KEY>>" \
  -H "Accept-Encoding: gzip" --compressed \
  -H "Content-Type: application/json" \
  -d '{
  "items": ["USP-S | Printstream (Factory New)"],
  "start": "2026-04-27"
}'

Steam returns data[].bucket as 2026-04-27T00:00:00Z. CSFloat returns data[].date as 2026-04-27. Normalise one to the other before joining rather than comparing the raw values.

Build the comparison#

  1. Request both series for the same item over the same window, starting no earlier than 2022 where CSFloat coverage begins.
  2. Key Steam rows by the date portion of bucket and CSFloat rows by date.
  3. Keep only dates present in both, and record how many you dropped.
  4. Calculate the ratio as CSFloat price divided by Steam price.
  5. Carry both volume values through to the result.

The ratio is a cash sale price against a Steam Wallet sale price. It is not a profit figure, because moving value out of Steam Wallet is not something the API models. Whatever assumption you make about that belongs in your own layer, stored separately from the raw ratio.

Reading the data correctly#

A median and an arithmetic average answer different questions about the same day. On an item with a wide price distribution, the average sits above the median whenever a few expensive copies sell, so part of any gap you measure is a statistical artefact rather than a market difference. This is worst on items where float, paint seed, or stickers drive large premiums, and mildest on liquid, homogeneous items like cases.

Steam supports no variants at all. Any comparison involving a Doppler phase, a Gamma Doppler phase, or a Case Hardened tier has only one side of the data, and requesting the variant from Steam returns unsupported_variant.

Both price fields are nullable, for different reasons. Steam's is null when its native bucket omits the value. CSFloat's is null when the day recorded volume but no usable price. Neither is a zero, and a day where either side is missing should leave the join rather than default.

Volume is the evidence behind the ratio. A day with three CSFloat sales and two Steam purchases produces a ratio that carries almost no information. Filter on a minimum volume on both sides, or at minimum display both counts wherever the ratio appears.

Steam's series reaches back to 2013 and CSFloat's begins in 2022. The overlap is the comparable window; the earlier Steam history is still useful on its own, but it has no CSFloat counterpart.

Worked example: a rolling cash-to-Wallet ratio#

Pull both series at daily granularity for a liquid item, join on date, and drop any day where either price is null or either volume falls below a threshold you choose and record.

Compute the daily ratio, then take a rolling median across seven or thirty days rather than reading single days. A rolling median is resistant to the one-expensive-sale problem that moves CSFloat's average, which is exactly the failure mode of a daily reading. Plot the number of contributing days alongside the ratio so thin stretches are visibly thin.

Full references: POST /v1/archive/steam, POST /v1/archive/csfloat. Both need a Scale or Enterprise key.