Skip to main content
WS channel: screener Enabled on your key on request: contact us. A live market screener, filtered and sorted for you: the full list on subscribe, then every token that enters, changes or leaves, as it happens. The list is the active market of REST /v1/screener, with no top-300 cut: every token that traded in the last 24 hours above the quality floor is in it, on every chain you ask for. One subscription is one view: one or more chains, a timeframe, a sort, your filters and a size. Rows are the cards of the Pulse Stream, with the same fields and the same null rules. For one row per pool instead of one row per token, use the Screener Pools Stream: same parameters, same messages.

​
Delivery model

  • Snapshot, then deltas. Right after the ack you receive a snapshot: the complete view, in order. From then on you receive a delta each time the view changes.
  • At your pace. A change is pushed as soon as it happens. Changes that follow within your updatePeriod (100 ms by default) are grouped into the next message, so a busy view sends at most one message per period.
  • A fresh copy every minute. Every 60 s, if the view moved, you receive its complete snapshot again ("reason": "periodic"), free: replace your view with it, like any snapshot. A view sorted or filtered on the 1m window gets it every 10 s.
  • Filters run on our side. You receive only the rows of your view, already ranked. You never sort and never filter.
  • Always consistent. Messages of a view are numbered (seq, prev). Whenever the exact sequence cannot be delivered, you receive a fresh snapshot instead: replace your view with it.

​
The active market

A token is in the list while one of its pools passes the quality floor on its last 24 hours: not a stable, wrapped or blocked asset; a minimum of volume, trades and distinct traders; a real liquidity that its volume does not turn over more than a thousand times; and, on EVM chains, a fees-to-volume ratio in line with the chain. A token enters at the trade that takes it over the floor, and leaves when it no longer passes, or 24 hours after its last trade. The row shows the token’s most active pool.

​
Parameters

​
string[]
required
1 to 8 public chain ids, evm:<id> or solana. EVM chains and Solana can be mixed in one view. A comma-separated string is accepted too. Example: ["solana", "evm:8453"]
​
string
The window the view works on, one of 1m, 5m, 15m, 30m, 1h, 4h, 6h, 12h, 24h. Default 24h. It sets the window behind sortBy: "volume", behind the bare counters in sortBy and filters (volumeUsd, feesUsd, buys, sells, txns, priceChangePct), and the window the rows carry by default. See Timeframe.
​
string
trending (default: our 24 h relevance ranking, wash-penalized), volume (USD volume of the timeframe; top is an alias), marketCap, createdAt, or any numeric card field, for example liquidityUsd, txns, windows.5m.volumeUsd. A bare counter reads the timeframe window.
​
string
asc or desc. Default desc.
​
number
View size, 1 to 100. Default 50.
​
object
A filter tree: { "<field>": { "<operator>": <value> } }, combined with AND, OR and NOT at any depth. Same grammar and same fields as the Pulse Stream. A bare counter (txns, volumeUsd, feesUsd, buys, sells, priceChangePct) and the flat REST parameters volumeMin, volumeMax, txnsMin, txnsMax, feesMin, feesMax read the timeframe window.
​
integer
Milliseconds, 0 to 60000, default 100: at most one delta per period, carrying every change of the period. The ack carries the value applied (snapped up to 0, 100, 250, 500, 1000, 2000, 5000, 10000, 30000, 60000); maxUpdatesPerMinute is accepted as an alias. See Choosing your pace.
​
string[]
The rolling windows to include in each row, among 1m, 5m, 15m, 30m, 1h, 4h, 6h, 12h, 24h (a comma-separated string is accepted too). Default: the timeframe. Filters and sortBy accept windows.<window>.<field> whether or not the window is in the rows. Example: ["5m", "1h", "24h"]
There is no model parameter: the list is the active market.

​
Timeframe

timeframe is a shorthand. It never changes the view’s identity: two subscriptions that spell the same view differently share one view. Read your figures in windows.<timeframe> of each row: that is what the view sorts and filters on. The top-level counters of a row (txns, volumeUsd, …) are the token’s 24 h figures, or the figures of its launchpad column when the token is also in a Pulse column.

​
Messages

Every message is the data of an event frame.
  • enter: full cards entering the view. Each carries rank, its position in the view (0 is the top) once the message is applied. Entries are listed by increasing rank.
  • update: { "key": "<chain>:<address>", … } with only the fields that changed. A field that became null is sent as null.
  • leave: the keys of the rows leaving the view.
  • order: every key of the view, in order. Present only when rows you already hold changed place.

​
Applying a delta

  1. Remove every key listed in leave.
  2. Apply every update: the fields present replace those of the row.
  3. Insert every row of enter at its rank, in the order given.
  4. If order is present, arrange your rows in that order.
A snapshot replaces everything you hold for the view.

​
The row

The card of the Pulse Stream, field for field: identity, price, market cap, liquidity, pool (the token’s most active pool), lifecycle, the top-level counters, metadata, creator, the holders (holdersCount, top10HoldersPct, devHoldingsPct: EVM chains, null on Solana rows; filtering or sorting on them in a Solana-only view is refused with UNAVAILABLE_FIELD), pools, and windows with the windows requested (the timeframe by default), each with volumeUsd, feesUsd, buys, sells, txns, uniqueBuyers, uniqueSellers, traders, snipers, proTraders and priceChangePct. The trending rank is a ranking score, not a field: it is never in a row and cannot be filtered on. Rows arrive in order; you never sort.

​
From REST /v1/screener to the stream

​
Resume

Events carry a cursor. After a reconnect, send the same subscribe with "since": "<cursor>": you receive the deltas you missed, or a snapshot of the current view followed by what comes next. Either way, applying what you receive is all there is to do. See Reconnect & resume in the Streams overview. When a client reads too slowly for its view, the pending messages of that view are replaced by one snapshot as soon as the connection catches up.

​
Billing

1 credit per message delivered. The snapshot of a subscription ("reason": "subscribe") costs 1, whatever its size; every delta costs 1, whatever it carries. Snapshots sent on our own after that first one ("reason": "periodic" every 60 s, "reason": "resync" after a hiccup) and deltas flagged "replay": true are free; the snapshot sent when you resume with since costs 1, like the one of a new subscription. A view where nothing happens costs nothing, and the connection is free. A longer updatePeriod means fewer messages, and fewer credits. GET /v1/usage/breakdown reports this channel under WS screener, where requests is the number of messages delivered.

​
Errors

​
Close codes

Ack
type:object

Server acknowledgement: the subscription is live.

Snapshot
type:object

The complete view, in order: right after the ack ("reason": "subscribe", 1 credit), every 60 s if the view moved (periodic, free) and whenever the view has to be replaced (resync, free).

Delta
type:object

Each change of the view, at most one per updatePeriod: 1 credit per message.

Subscribe
type:object

Client frame opening the subscription (additive, ack is explicit).