Skip to main content
The Intelligence API turns raw demand and pricing into ready-to-act answers. Where the Demand & Intent endpoints report first-party behaviour, Intelligence blends categories — demand signals combined with catalog pricing — to score how readily a title should move (liquidity_score). The endpoints on this page answer “across the catalog, what will actually move?”, “for this specific title, how liquid is it and why?”, and “here’s my pile — score every title for me.” To decide how to sell a copy (loose, CIB, or new), see Intelligence: Conditions. All endpoints require the intelligence.read scope and a valid Authorization: Bearer <token> header.
Provenance caveat. liquidity_score blends a demand component (first-party intent, reach, and watch demand) with a price component (catalog pricing). Supply is not directly observed, so liquidity is a turnover proxy — demand strength adjusted for price accessibility — not a measured sell-through rate. Treat it as a relative ranking signal, not a guaranteed sale rate.

Common query parameters

The leaderboard and profile endpoints share the following query parameters.
string
default:"7d"
The time window to aggregate over. One of day, 7d, or 30d.
string
Override the target window-end date. Defaults to the latest computed date for the selected period. Format: YYYY-MM-DD.
integer
Restrict results to games belonging to this console. Omit to score across all consoles. (Leaderboard only.)
integer
default:"25"
Page size. Capped by your plan’s max_page_size. (Leaderboard only.)

Derived fields

Several response fields are computed by blending demand and pricing rather than stored directly. Understanding how each is derived helps you interpret what it signals.

demand.index

A 0.01.0 blend of three demand signals — intent (redirect clicks), reach (distinct users), and watch demand (watchlist alerts) — each normalised against the highest value in the current period and console scope. The most-demanded title in scope approaches 1.0; every other title is scored relative to it.

price_accessibility

A 0.01.0 score that is higher for cheaper titles, on the principle that lower-priced games turn over faster:
A title with no catalog price falls back to a neutral 0.5, so missing pricing never masquerades as high liquidity.

liquidity_score

A single 0100 index combining demand with price accessibility:
The two weights (w_demand and w_access) sum to 1 and are set in the API’s serving configuration. A high score means a title is both in demand and priced to move.

momentum

Whether interest is accelerating or fading, measured as the trailing 7-day daily pace against the 30-day baseline. This is the same calculation used across Demand & Intent. When a title has no 30-day baseline, value is null and label is "unknown".

GET /api/v1/intelligence

Returns a ranked liquidity leaderboard for the selected period. The result is anchored on titles with redirect demand, left-joining watch demand and catalog pricing. Use this to answer “across the catalog, what will actually move, and how should I weigh demand against price?”

Query parameters

In addition to the common parameters:
string
default:"liquidity"
Sort order for the leaderboard. One of:
  • liquidity — by liquidity_score descending (default)
  • demand — by demand.index descending (ignores price)
  • value — by complete-in-box price descending (highest-margin first); liquidity_score breaks ties

Response

Returns a paginated array of liquidity rows. The meta object includes the resolved period, period_date, and sort.
array
Array of liquidity rows, each representing one game ranked by the selected sort.
integer
The game’s rank within the current period and sort.
object
Game identity fields.
integer
Unique game ID.
string
Display name of the game.
string
URL slug for the game.
integer
ID of the console this game belongs to.
string
Display name of the console.
object
Demand signals and the normalised blend used for scoring.
integer
Purchase-intent clicks in the period.
integer
Unique users who clicked through.
integer
Active watchlist alerts in the period.
float
The 0.01.0 blended demand index (see Derived fields).
object
Acceleration of interest relative to the 30-day baseline.
float
Computed ratio. null when no 30-day baseline exists.
string
rising, steady, cooling, or unknown.
object
Current market prices from the catalog.
string
Loose (cartridge/disc only) price as a decimal string.
string
Complete-in-box price as a decimal string.
string
Sealed/new price as a decimal string.
float
The 0.01.0 price-accessibility score (higher = cheaper/faster-moving; see Derived fields).
integer
Composite 0100 liquidity index blending demand and price accessibility.
object
string
The resolved period (day, 7d, or 30d).
string
The window-end date the data was computed for (YYYY-MM-DD).
string
The active sort (liquidity, demand, or value).
object
Standard pagination metadata (see Pagination).
Example response:

GET /api/v1/intelligence/

Returns a per-game intelligence profile in the same row shape as the leaderboard. Unlike the leaderboard — which is anchored on titles that have redirect demand — this endpoint is anchored on the catalog, so any enabled game resolves even with zero demand. The score is normalised against the whole period population, so it stays comparable to the leaderboard. Use this to answer “for this specific title, how liquid is it, and why?”

Path parameters

integer
required
The numeric ID of the game. You can resolve IDs from the Games catalog endpoints.

Query parameters

string
default:"7d"
The time window to aggregate over. One of day, 7d, or 30d.
string
Override the target window-end date. Defaults to the latest computed date. Format: YYYY-MM-DD.

Response

Returns a single liquidity row with the same fields as a leaderboard entry (rank, game, demand, momentum, pricing, price_accessibility, liquidity_score).
Returns 404 not_found only when the id does not correspond to a real, enabled game in the catalog. A valid game with no demand still returns a row — with low demand metrics and a correspondingly low liquidity_score.
To decide which condition to list a copy in — loose, CIB, or new — use GET /api/v1/intelligence/{id}/conditions, documented on the Intelligence: Conditions page.

POST /api/v1/intelligence/batch

Score an entire lot or inventory in one request. Submit a list of game IDs and each is scored with the same liquidity logic as the leaderboard, against one shared period scope resolved once for the whole batch. Unknown IDs are returned as { "found": false } rather than failing the batch. The API returns a 200 when every item succeeds and a 207 when there is a mix of outcomes — always inspect the status field of each item in data.

Authentication

Send your API key as a bearer token. The key must carry the intelligence.read scope.

Query parameters

string
default:"7d"
The period scope applied to every item in the batch. One of day, 7d, or 30d.
string
Override the target window-end date for the whole batch. Format: YYYY-MM-DD.

Request body

array
required
An array of request objects, each identifying a game by game_id (the key id is also accepted). The number of items must be at least 1 and no more than your plan’s max_batch_size.

Request example

Response

200 OK — all items succeeded.
207 Multi-Status — at least one item failed. Check each item’s status field.
array
One entry per item submitted, in the same order as your requests array.
integer
HTTP status code for this individual item (200 on success, 422 on per-item validation failure, etc.).
object
Present when the item succeeded. Contains the game’s liquidity row (same shape as a leaderboard entry). For an ID with no matching enabled game, the row is { "game_id": <id>, "found": false }.
object
Present when the item failed. Follows the standard error envelope with code, message, and optional details.
object
Aggregate counts for the batch.
integer
Total number of items submitted.
integer
Number of items that returned a 2xx status.
integer
Number of items that returned a non-2xx status.
Example response:

Idempotency

Add an Idempotency-Key header to make your batch request safely retryable. If a network error prevents you from receiving the response, resend the same key and identical payload — the original response is replayed verbatim and the Idempotency-Replayed: true header is set. Stored responses expire after 24 hours.
Reusing an Idempotency-Key with a different request body returns 422 idempotency_key_reuse. Generate a fresh key for each logically distinct request.

Usage metering

Each object in the requests array counts as one usage unit against your monthly quota. A batch of 50 items consumes 50 units, regardless of whether individual items succeed, fail, or resolve to found: false.

Error reference

Batch too large — example error response: