Live-streamed filter token updates for the current filterTokens result set. onFilterTokensUpdated subscription reference: arguments and payload fields.
onFilterTokensUpdated is the live counterpart to filterTokens. It accepts the same filter and ranking inputs, sends the current matching set on the first message, then re-evaluates every 30 seconds and pushes updates as the matching set changes. Use it anywhere you would otherwise re-run filterTokens on a timer.
Boolean filtering: The filters input supports an optional boolFilter field that accepts and, or, and not operators (nestable up to 4 levels). Use it when you need different filter conditions for a subsets of tokens, such as per-network thresholds, or across different fields. For example, you might want different filter conditions depending on whether tokens are on Solana or Base. See Advanced Filtering for details.
This endpoint requires a Growth or Enterprise plan. Learn more.
The list of updated token results matching the subscription parameters. When the subscription’s result set is refreshed, also includes full results for tokens that newly match.
See TokenFilterResult
The list of exchange contract IDs to filter by. Applied in conjunction with network filter using an OR condition. When used together, the query returns results that match either the specified exchanges or the specified network.
The token’s cumulative route-backed liquidity in USD, summed across the token’s pairs with valid routing liquidity. Distinct from liquidity, which covers the top pair only.
See NumberFilter
The list of network IDs to filter by. Applied in conjunction with exchangeId filter using an OR condition. When used together, the query returns results that match either the specified exchanges or the specified network.
Whether to ignore pairs/tokens not relevant to trending. This is done checking against a few factors and ignoring uninteresting tokens like stables / network tokens. If you want all tokens regardless of these checks, then don’t include this field. (default) If you want only tokens that fail the trending ignore checks, then set it to true. (i.e. stablecoins, rugs, network base tokens) If you want only tokens that pass the trending ignore checks, then set it to false.
Where in the list the server should start when returning items. Use count+page from the previous query to request the next page of results.
The first message delivers all tokens matching your filters. Subsequent messages only include tokens with updated data, returned at the interval you set via updatePeriod. Every 30 seconds, the filter itself re-evaluates: if tokens start or stop meeting your filters, the result set updates automatically.
Accepts the same filters, rankings, and limit arguments as the filterTokens query. If you’ve already built a filterTokens request, you can reuse it here as a subscription.
The first message delivered contains the current state of the filtered set, so there’s no need to run a one-off filterTokens query first.
Matched tokens push data updates on a configurable interval via updatePeriod (defaults to 500ms if not specified, accepts any value in ms from 0ms to 60s).
The filter itself re-evaluates the token list every 30 seconds. If the set of matching tokens changes (a token starts meeting the filters, or stops meeting them), you’ll automatically receive updates reflecting the new set. This re-evaluation interval is not currently configurable.
Ideal for keeping trending lists, leaderboards, or filtered dashboards live without manual polling.
For ultra-low-latency token discovery (e.g. memescope-style interfaces) our Launchpad subscriptions may be a better fit for that use case.
Apply the same quality filters (trendingScore, minimum volume, mcap range, liquidity, holders, etc.) you would on filterTokens to avoid low-quality tokens in the stream.
Response limit remains 200 tokens per subscription.
Do I still need to call filterTokens first to get the initial state?
No. The first message delivered after subscribing contains the current filtered result set. You can treat the subscription as a full replacement for polling filterTokens for most use cases.
Why am I not receiving any updates after the first message?
Tokens that match your filters will push data updates on a set updatePeriod (default 500ms). If that period is set high (e.g. 60000 for 60s), pushes will be less frequent. The filter itself also re-evaluates every 30 seconds, so if the set of matching tokens hasn’t changed and no tokens in the set have new data in your updatePeriod window, you may see quiet stretches. Broadening your filters or lowering updatePeriod will confirm the stream is live.
Can I make updates push faster than 500ms?
Yes. Set updatePeriod to any value between 0ms and 60s. Note that 0ms means “as fast as events arrive,” which can mean high message volume on busy filter sets.
Can I make the filter re-evaluate faster than every 30s?
Not currently. The 30-second filter re-evaluation is fixed. For very low-latency token discovery (e.g. memescope-style UIs), our launchpad subscriptions offer lower-latency streams for newly launched tokens.
Should I use this instead of polling filterTokens on an interval?
It depends on your use case for filterTokens, but in most instances, yes. This subscription is the intended replacement for poll-based refresh patterns on filterTokens.
Can I change filters on an active subscription?
No. To change filters or rankings, close the current subscription and open a new one with the updated arguments.