How to Get Skinport Price History for CS2

cs2.sh's POST /v1/prices/history with sources: ["skinport"] returns ask OHLC candles from December 24, 2025. Skinport publishes no buy orders, so the series is sell-side only.

Skinport is the one source where the historical series is narrower than the current snapshot. The candles give you the cheapest listing over time; the completed-sale context lives in the rolling windows on GET /v1/prices/latest instead.

What cs2.sh provides for Skinport history#

Request the series#

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": ["skinport"],
  "interval": "1d"
}'

The skinport object inside each bucket carries open_ask, high_ask, low_ask, close_ask, ask_volume, sample_count, open_time, and close_time. No bid fields appear, because Skinport has none to report.

Pair candles with completed sales#

Because the history series is ask-only, the completed-sale side has to come from the current snapshot. GET /v1/prices/latest carries four rolling windows on the skinport source:

Each contains price, max_price, mean_price, median_price, and volume for sales in that window, and the whole object is null when Skinport has no recent sales.

These are summaries at one moment, not a series. Polling them repeatedly and storing the results builds a record of successive summaries, not a sale history: the windows overlap, so consecutive readings share most of their underlying sales and cannot be differenced into clean periods.

Reading the data correctly#

close_ask is where the cheapest listing ended the bucket. 24h_history.median_price is the middle of what actually sold in the last day. The gap between them is the distance between asking and realised prices, and it means nothing unless both sides are labelled.

sample_count is the evidence behind a candle. A one-observation bucket has identical open, high, low, and close, which is a single reading rather than a still market. Filter on it before treating small moves as signal.

Per-source objects appear only when that source had data in the bucket, so a missing skinport key is a gap and not a zero. Valid items with no buckets in the requested range are omitted from items entirely, so read count rather than assuming every requested item returns.

start is floored to the interval boundary and end is ceiled and exclusive, so the effective range can be slightly wider than requested. Label charts from the returned start and end.

When items fail#

Item-level failures arrive in errors[] beside successful results in a 200 response: unknown_item, invalid_format, or unsupported_source where an item has no Skinport identity.

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

Worked example: spotting a listing below the recent market#

Read close_ask from the most recent 1d candle and compare it against 30d_history.median_price from the current snapshot. A close_ask materially below that median is a listing priced under where the item has been selling for a month.

Before acting on it, check ask_volume on the candle and volume in the window. One active listing against three sales in thirty days is a thin item where both figures are fragile, not an opportunity. Record collected_at from the snapshot and close_time from the candle so the comparison stays traceable to when each side was observed.

Full request and response reference: POST /v1/prices/history. Current fields and windows: GET /v1/prices/latest. History endpoints need a Scale or Enterprise key.