How to Get BUFF163 Price History with an API

BUFF history comes in three separate datasets: intraday ask and bid OHLC from December 24, 2025, long-term archive prices from 2023, and float-range and fade-range history from May 19, 2026. They have different shapes and different collection behaviour, so pick one per question rather than concatenating them silently.

BUFF is the largest CS2 marketplace by listing count and publishes both order counts, which makes its history the most complete of any source. The cost of that completeness is that it arrives in four places.

Pick the BUFF series by purpose#

The listing series carry ask, bid, ask_volume, and bid_volume, because BUFF publishes both sides with depth. The sale archive is the exception: each point is a sale_price sampled from BUFF's transaction chart with the total_supply BUFF reported that day, and there is no volume field.

Request intraday candles#

curl -X POST https://api.cs2.sh/v1/prices/history \
  -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-07-20",
  "sources": ["buff"],
  "interval": "1h"
}'

"buff": {
  "open_ask": 115.16,
  "high_ask": 115.16,
  "low_ask": 115.16,
  "close_ask": 115.16,
  "ask_volume": 466,
  "open_bid": 112.21,
  "close_bid": 112.21,
  "bid_volume": 42,
  "sample_count": 75,
  "open_time": "2026-07-20T00:00:51Z",
  "close_time": "2026-07-20T00:58:51Z"
}

Request the long-term archive#

The archive defaults to the aggregate source only, so BUFF must be named:

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

"buff": {
  "time": "2026-04-27T23:53:24Z",
  "ask": 133.12,
  "ask_volume": 405,
  "bid": 130.19,
  "bid_volume": 45,
  "sample_count": 24
}

Archive values are the last observed reading inside the bucket, not an aggregation. time records when that observation happened.

Request float and fade range history#

POST /v1/market/buff/history tracks each BUFF range bucket independently from May 19, 2026, at 30m (90 days), 1h (365 days), or 1d (unlimited). Join it to GET /v1/market/buff/latest on bucket_id, which is stable across both. Matching on the decimal bounds is fragile because labels can be reformatted while the identity does not change.

In range history, prices are OHLC while the volumes are last-observed counts within each point. Treat a count as a snapshot near the end of that window rather than orders added during it.

Reading the data correctly#

An OHLC close and a last-observed archive value are different statistics. A chart crossing December 24, 2025 that plots both as one line will show a step that is a dataset handoff rather than a market move. Mark the boundary, or pick one series.

Archive history updates about 1-2x per day, so hourly archive buckets do not imply hourly collection. The interval is the bucket width, not the collection rate.

Everything across all three series is an active order. ask_volume and bid_volume count resting listings and buy orders, and a fall in either can come from a purchase, a cancellation, or a reprice into a different range. None of it is completed sales; for approximate sale activity, the aggregate source in the archive carries hourly_volume.

BUFF range buckets describe how BUFF segments its listings commercially. They are not the item's physical float limits, which live in GET /v1/schema as float_range and wear_float_range. A range can be absent even though the item supports that float.

When items and variants fail#

Item-level failures arrive in errors[] beside successful results. unknown_item and invalid_format cover naming, unsupported_variant covers a phase or tier BUFF does not carry, and not_in_archive appears on archive requests for a valid item with no rows.

Request-level failures carry error, message, and a request_id. A 403 means the endpoint is not in your plan, and a 400 covers more than 100 items or a range wider than the interval allows.

Worked example: whether a float band moved on its own#

Request 1d range history for the item and take one bucket_id such as a narrow Factory New band, then request 1d intraday candles for the whole item over the same window.

Compare the band's ask against the item's close_ask. If the band rose while the item's headline listing did not, demand concentrated in that float range rather than the item broadly. Keep the volume counts from both sides visible, since a band with eight listings can move on a single reprice.

Full references: POST /v1/prices/history, POST /v1/archive/history, POST /v1/archive/buff, POST /v1/market/buff/history. All four need a Scale or Enterprise key.