Rankings

The screener as an API: every pair sorted by any metric the engine computes: seven categories, thirty-plus rankable fields, one request.

GET/v1/rankings/{category}

Rankings answer the screening question directly: "which pairs score highest on X right now?" Instead of pulling metrics for 500 pairs and sorting client-side, you name a category and a metric and receive the sorted list: the exact same rankings that power the Osiris screener grid, at the same freshness (the 30-second metrics sweep).

Request

Parameter	In	Description
`category`	path	One of the seven categories below.
`metric`	query	Field to rank by, from the category's whitelist. Defaults to the category's headline metric. An invalid value answers `422` listing the allowed set.
`interval`	query	Timeframe for windowed categories. Default `5m`. Ignored by `funding` and `trend`.
`limit`	query	1-500 rows. Default 50.
`exchange`	query	Venue whose board is ranked. See Exchanges. Default: Binance. The `trades` category ranks meaningfully on Binance only (the other venues publish no trade tape).

Categories & metrics

Category	Metrics (default first)	Ordering
`volatility`	`NATR` RR PK GK RS YZ SURGE	highest first
`volsurge`	`SCORE` VOL_RATIO TR_RATIO RET_ZSCORE	highest first
`volume`	`USDT_VOLUME` AVG_VOLUME VOL_STDDEV VOL_GROWTH VWAP OBV	highest first
`trades`	`TC_GROWTH` QV_GROWTH TC_ZSCORE QV_ZSCORE FLOW BUY_RATIO SIZE_GROWTH AVG_TRADE_SIZE	highest first
`correlation`	`retCorr` realTimeVol natrRatio surgeRatio	highest first
`funding`	`RATE` PREMIUM AVG_24H TREND APR	by magnitude: extremes in either direction first
`trend`	`LOCAL_SCORE` GLOBAL_SCORE ALIGNMENT DIVERGENCE CONSENSUS MOMENTUM	by magnitude: strongest trends of either sign first

Every metric's meaning is documented in depth on the Metrics page; rankings and per-pair metrics are two views of the same engine output. The magnitude ordering on funding and trend is deliberate: a −0.09% funding rate is more interesting than a +0.02% one, and a strong downtrend is as rankable as a strong uptrend; check the value's sign to tell direction.

Examples

Top 10 surging pairs on 5m

curl "https://osiristrader.com/api/v1/rankings/volsurge?metric=SCORE&interval=5m&limit=10" \
  -H "Authorization: Bearer osk_YOUR_KEY"

{
  "category": "volsurge",
  "metric": "SCORE",
  "interval": "5m",
  "data": [
    { "symbol": "WIFUSDT", "value": 2.41 },
    { "symbol": "SOLUSDT", "value": 1.87 },
    { "symbol": "ORDIUSDT", "value": 1.55 }
  ]
}

Most extreme funding: squeeze candidates (note: interval-independent)

curl "https://osiristrader.com/api/v1/rankings/funding?metric=RATE&limit=20" \
  -H "Authorization: Bearer osk_YOUR_KEY"

Where the whales are: biggest average trade size on 1h

curl "https://osiristrader.com/api/v1/rankings/trades?metric=SIZE_GROWTH&interval=1h&limit=15" \
  -H "Authorization: Bearer osk_YOUR_KEY"

Building multi-factor screens

Rankings are single-factor by design; multi-factor screens compose them client-side. The idiomatic pattern is rank-intersect: pull two or three rankings (one request each), intersect the top-N symbol sets, then hydrate the survivors with one bulk metrics call. A complete "decoupled surgers with real size behind them" screen costs 4 requests:

JavaScript: three-factor screen in 4 requests

const [surge, size] = await Promise.all([
    osiris("/v1/rankings/volsurge?metric=SCORE&limit=100"),
    osiris("/v1/rankings/trades?metric=SIZE_GROWTH&limit=100"),
]);
const surging = new Set(surge.data.map(r => r.symbol));
const candidates = size.data.filter(r => surging.has(r.symbol)).map(r => r.symbol);

// hydrate + final filter: only pairs NOT glued to BTC
const { data } = await osiris("/v1/metrics?symbols=" + candidates.slice(0, 50).join(","));
const picks = Object.entries(data).filter(([, m]) => (m.correlation?.retCorr ?? 1) < 0.4);

Rows only include symbols for which the metric currently exists; young listings without enough window drop out naturally rather than appearing with fake zeros. The list you get is always honestly rankable.

Levels

Funding