How to Get Current BUFF Prices for CS2 Items
Updated
The
buffsource in cs2.sh'sGETorPOST /v1/prices/latestcarriesask,bid,ask_volume, andbid_volumefor every tracked CS2 item.GET /v1/market/buff/latestgoes 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
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)"]}'"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. |
{
"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.