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

How to Get Current BUFF Prices for CS2 Items

Updated

Endpoints used: GET /v1/prices/latest & GET /v1/market/buff/latest

Related pages: BUFF price API

The buff source in cs2.sh's GET or POST /v1/prices/latest carries ask, bid, ask_volume, and bid_volume for every tracked CS2 item. GET /v1/market/buff/latest goes further and splits each item into float ranges, fade ranges, and combined ranges with their own prices.

BUFF is the largest CS2 marketplace by listing count, and it is one of only three sources that publish both order counts. It is also the only source where cs2.sh exposes prices segmented by float band, which matters because a Factory New listing at 0.01 and one at 0.06 are not the same product.

What cs2.sh provides for BUFF#

Property Value
Item prices buff source in GET / POST /v1/prices/latest
Fields ask, bid, ask_volume, bid_volume
Range prices GET /v1/market/buff/latest
Refresh Items about every 5 minutes; BUFF variants about every 3-5 minutes; ranges every 10 minutes
Variants Doppler, Gamma Doppler, and Case Hardened
Currency Always USD
Access Both available on all plans

Read the item price#

bash
curl -X POST https://api.cs2.sh/v1/prices/latest \
  -H "Authorization: Bearer <<YOUR_API_KEY>>" \
  -H "Accept-Encoding: gzip" --compressed \
  -H "Content-Type: application/json" \
  -d '{"items": ["USP-S | Printstream (Factory New)"]}'
json
"buff": {
  "updated_at": "2026-07-26T18:50:53Z",
  "collected_at": "2026-07-26T18:53:10.67Z",
  "ask": 109.72,
  "ask_volume": 463,
  "bid": 106.17,
  "bid_volume": 41
}

ask is the lowest active sell listing and bid is the highest generic buy order. ask_volume and bid_volume are the counts of active listings and active buy orders behind them, so unlike CSFloat, a BUFF buy order arrives with depth attached.

Read prices by float and fade range#

GET /v1/market/buff/latest returns every item split into buckets:

bucket_type Meaning
base Aggregated across the entire item or variant.
float A float range. float.min and float.max describe it.
fade A fade percentage range. fade.min and fade.max describe it.
float_fade A combined float range and fade range.
json
{
  "bucket_id": "float:0.15:0.18",
  "bucket_type": "float",
  "float": { "min": 0.15, "max": 0.18 },
  "updated_at": "2026-07-26T18:46:12Z",
  "collected_at": "2026-07-26T18:50:54.164Z",
  "ask": 218.55,
  "avg_ask": 231.47,
  "bid": 203.78,
  "ask_volume": 219,
  "bid_volume": 10
}
Field Type Description
bucket_id string Range identity, stable between this snapshot and range history.
bucket_type string base, float, fade, or float_fade.
float / fade object Range bounds, present on the matching bucket types.
ask, bid number Lowest sell listing and highest buy order inside the range.
avg_ask number Average sell listing inside the range.
ask_volume, bid_volume integer Active listing and buy-order counts inside the range.
items.<name>.variants object Per-variant ranges in the same shape.

Use bucket_id to match the same range across requests and against POST /v1/market/buff/history. Matching on the decimal bounds instead is fragile, because the labels can be reformatted while the identity does not change.

Reading the data correctly#

BUFF range buckets are commercial segments, not the item's physical definition. They describe how BUFF groups its listings, which is narrower and more volatile than the item's real float limits. Those limits live in GET /v1/schema as float_range and wear_float_range. Do not replace schema bounds with observed bucket edges: a bucket can be absent even though the item physically supports that float.

Bucket boundaries are half-open in the usual direction. A float exactly on a boundary belongs to the range that begins at it, because min is inclusive and max is exclusive.

Everything here is an active order. ask_volume and bid_volume count resting listings and buy orders, not sales, and a fall in either can come from a purchase, a cancellation, or a reprice into an adjacent range. For completed activity, the aggregate series in POST /v1/archive/history carries an approximate hourly_volume.

Base item source objects are dense, so buff is present whenever any source has data for the item, with null where BUFF supplied nothing. Variant source objects are sparse and appear only where BUFF has data for that exact phase or tier.

When items are missing or fail#

Item-level failures arrive in errors[] alongside successful results in a 200 response, one entry per requested item: unknown_item, invalid_format, or not_in_cache for a valid item with no current data.

Request-level failures carry error, message, and a request_id. 403 means the endpoint is not included in your plan and 429 means the per-second limit was exceeded.

Worked example: pricing an exact float#

Take the item's real bounds from GET /v1/schema, then request GET /v1/market/buff/latest and find the bucket whose float.min is at or below your float and whose float.max is above it. That bucket's ask is the cheapest listing you could actually buy at that float, which is usually well above the item's headline ask from prices/latest.

Keep avg_ask beside it. A wide gap between ask and avg_ask inside one narrow band means the cheapest listing is an outlier rather than the going rate for that float. Check ask_volume for the same reason, and record collected_at with whatever you compute.

Full range reference: GET /v1/market/buff/latest. Range history: POST /v1/market/buff/history. Item float limits: GET /v1/schema.