Universal Search - POST (advanced filters)
Metacore
Universal Search - POST Method
Run a token search with advanced, pulse-v2-style filtering. The POST body mirrors a single pulse view — top-level chainId/poolTypes/sortBy/limit, with filters reserved for a Prisma-like AND/OR/NOT tree.
POST
Universal Search - POST (advanced filters)
POST Method Overview
POST /api/2/fast-search accepts the same payload shape as a single pulse v2 view, plus one extra field — input — that carries the search term. Any filters block you can send to POST /api/2/pulse is a valid filters block here.
Use POST when you need:
- AND / OR / NOT logic (e.g. per-chain conditional constraints).
- Rich Prisma operators (
gte,lte,in,notIn,contains,startsWith,endsWith,mode: "insensitive"). - A structured JSON body instead of URL-encoded query strings.
Base Endpoint
Endpoint
Body Shape
input
The search term. Prefix match on tokenName / tokenSymbol / asset_name / asset_symbol, or exact address match if the value is a valid address > 26 chars. Wrap in double quotes for Google-style exact-symbol match (e.g. "W" matches only tokens with symbol “W”).
chainId (optional)
Single chainId or array. Mirrors pulse view.chainId. Translated to chainId: { in: [...] } and ANDed with filters. When you need per-chain conditional logic (e.g. different constraints per chain), skip this field and express the chain constraint inside filters using OR.
poolTypes (optional)
Single poolType or array. Mirrors pulse view.poolTypes. Translated to source: { in: [...] }.
sortBy / sortOrder
Accepts both camelCase (volume24h, feesPaid24h, …) and snake_case (volume_24h, fees_paid_24h, …) — same list as the GET variant. Default volume_24h desc.
sortBy: "searchScore" is GET-only (derived ranking that isn’t part of the Prisma model). On POST it falls back to volume_24h. Use GET when you need searchScore ranking.filters
A Prisma-like where tree — identical syntax to pulse view.filters. Supported operators:
- Logical:
AND,OR,NOT - Comparison:
equals,not,gte,gt,lte,lt,in,notIn - String:
contains,startsWith,endsWith, withmode: "insensitive"
TokensStatsRealTime, same as pulse — chainId, tokenName, tokenSymbol, volume_24h, volume_1h, fees_paid_24h, fees_to_volume_ratio_24h, totalFeesPaidUSD, holders_count, bonded, bonded_at, shadow_ban, bundlers_holdings_percentage, dev_holdings_percentage, source, factory, deployer, market_cap, created_at, trending_score_24h, etc.
🔍 Complete Filter Reference
The pulse stream docs list every filterable field — they apply 1:1 here.
Examples
Example 1 — Basic: chain scope + min 24h volume
chainId is the simplest way to restrict to a few chains — same shorthand as pulse view.chainId.
Example 2 — AND / NOT: high-liquidity tokens, exclude shadow-banned
Example 3 — OR per-chain: Solana requires a min fees-to-volume ratio, EVM doesn’t
Use case: on Solana you want tokens that generate real fee revenue relative to their volume (filters out wash-traded tokens); on EVM chains fee-tracking is less reliable so you don’t want that constraint to exclude legitimate results. BecausechainId is expressed inside the tree, the constraint applies per OR branch — exactly what the top-level chainId shorthand cannot do.
filters block pasted under a pulse view’s filters field works identically — fast-search POST and pulse POST share the same filter surface.
GET vs POST
Use POST when:
- You need
AND/OR/NOTlogic. - You need per-chain conditional constraints.
- You want a structured JSON body instead of URL-encoded query strings.
- You want the
searchScore-independent Prisma orderBy (all other sort fields work).
Use GET when:
- Your filter is a flat set of constraints (chain list + min/max on a few numeric fields).
- You want
searchScoreranking (the compositefees_paid_24h × largest_pool_reserve_usdrank). - Your client can’t easily POST JSON (simple scripting / shell).
🔗 GET Method
Simple search with URL-encoded
filters query string.📡 Pulse POST
Same filter surface, but returning live pool/token views rather than search hits.
Body
application/json
Search query string
Chain ID(s) to filter — same shorthand as pulse view.chainId
Pool type(s) to filter — same shorthand as pulse view.poolTypes
Prisma-like where tree (AND/OR/NOT + leaf operators equals, not, gte, gt, lte, lt, in, notIn, contains, startsWith, endsWith). Same surface as view.filters on POST /2/pulse.
Sort field for search results (default: volume24h; searchScore falls back to volume_24h on POST)
Available options:
volume24h, marketCap, createdAt, volume1h, feesPaid5min, feesPaid1h, feesPaid24h, volume5min, holdersCount, organicVolume1h, totalFeesPaidUsd, searchScore, trendingScore24h Sort order (default: desc)
Available options:
asc, desc Maximum number of results (1-20, default: 5)
Offset for pagination (default: 0)
Response
200 - application/json
Universal Search response