How to Compare CS2 Variant Liquidity

Updated

API reference: GET /v1/liquidity/items

GET /v1/liquidity/items scores supported Doppler, Gamma Doppler, and Case Hardened variants independently from their base item, with a liquidity bucket and estimated sale time for each.

A base item's sale activity can hide large differences between phases or tiers. Variant-aware screening should use the nested variant result rather than copying the parent's classification.

Variant liquidity data#

The endpoint returns one of eight absolute buckets: unknown, extremely_illiquid, very_illiquid, illiquid, moderate, liquid, very_liquid, or extremely_liquid.

Each result also includes estimated_sale_time, ranging from under 1 hour through 2+ months, with unknown when evidence is insufficient. The estimate is the 80th-percentile sale time for a competitively priced listing.

Liquidity is recomputed daily from sale volume and traded value on BUFF, Steam, and CSFloat over rolling 30- and 90-day windows, weighted toward recent activity. It is absolute and deterministic, not a relative percentile rank.

Comparing phases and tiers#

Locate the base item by exact market_hash_name, then traverse its variants map. Variant maps are keyed by display labels such as Phase 1, Ruby, or Tier 1. Within each variant, name is the full identity and version is the stable code.

Compare both liquidity and estimated_sale_time. Two variants can share a bucket but have different sale-time bands, while unknown should remain a separate insufficient-evidence state. Keep the snapshot's run_date with the comparison.

Applicable endpoint#

Endpoint Returns Plans
GET /v1/liquidity/items Daily item and variant liquidity snapshot Scale, Enterprise

Interpretation limits#

  • The sale-time estimate assumes competitive pricing. A phase listed far above comparable asks can take longer.
  • The classification does not price an individual item's exact float, stickers, or paint seed.
  • An unknown variant should not pass a maximum-sale-time filter unless the application defines an explicit uncertainty policy.
  • Liquidity updates daily, so store run_date when comparing results across time.

Use variant price data beside liquidity when the comparison also needs acquisition cost.