DexScreener Scraper — DEX Pairs, Prices & Liquidity

Reads DexScreener's public API: DEX trading pairs across every indexed chain, plus the token-profile and boosted-token discovery feeds. No key, no auth.

What you get

recordType	One per	Carries
PAIR	trading pair	chain, DEX, pair address, base/quote token, price (parsed and raw), FDV, market cap, liquidity in USD/base/quote, volume and price change for 5m/1h/6h/24h, buy and sell counts, creation date, socials, websites, boost state
TOKEN_PROFILE	profiled or boosted token	chain, address, description, icon, links, boost amounts, rank
SEARCH_SUMMARY	query	pairs returned, the 30-pair cap, whether paging is supported, and how many rows this actor filtered out locally
ERROR	failed input	a named reason — every input maps to at least one row

Four ways in, combinable in one run: searchQueries, tokenAddresses, pairs, and the discovery feeds.

Search returns 30 pairs and there is no way past it

Nothing in the payload says how many pairs actually matched — no total, no count, no more flag. USDC has thousands of pairs; you get thirty.

And the three obvious paging parameters are accepted and silently ignored:

?q=USDC&limit=100   ->  30 pairs, first pair 0x6c9A33E3...
?q=USDC&page=2      ->  30 pairs, first pair 0x6c9A33E3...   identical
?q=USDC&offset=30   ->  30 pairs, first pair 0x6c9A33E3...   identical

HTTP 200 every time. A scraper that pages by incrementing page collects the same thirty rows over and over and reports them as growing coverage.

So this actor does not paginate search at all — one request per query, and pagingSupported: false on every summary. To get real breadth, use more queries, or address tokens directly: tokenAddresses is the surface that returns a token's full pair set, and addresses on the same chain are batched 30 per request, so thirty tokens cost one call.

FDV and market cap are different numbers

They differ on 17 of 30 pairs in a single measured response, and not subtly:

USDC    fdv  6,338,247,859     marketCap 60,893,794,316     9.6x apart

Note the direction — FDV is the smaller one, backwards from the usual "fully diluted ≥ current" intuition, so substituting either for the other is wrong in a way that also defies the sanity check. Both are emitted verbatim, neither is derived from the other, and fdvEqualsMarketCap records which pairs happen to agree.

Prices are strings; everything else numeric is not

In the same object: priceUsd "105.96" (string), fdv 23434953 (int), liquidity.usd 435995.74 (float).

Sorting priceUsd as delivered is a lexicographic sort, where "9.5" ranks above "105.96". Both forms are emitted — priceUsd parsed to a float for arithmetic, priceUsdRaw exactly as sent, because a very small token price carries significant digits a float rounds away.

Optional fields are absent, not null

Measured on one 30-pair response: boosts missing on 30/30, info on 28/30, labels on 20/30, pairCreatedAt on 4/30. So pair["info"] raises where pair.get("info") returns None, and a consumer assuming a stable schema breaks on the majority of rows.

Every row here has the same shape, with hasInfo and hasBoosts recorded explicitly so "absent" stays distinguishable from "present but empty".

Filtering happens here, not upstream

DexScreener's API has no filter parameters at all. chainFilter and minLiquidityUsd are applied by this actor after fetching, and the summary reports filteredOutLocally so a small result set is explained rather than mysterious. A pair with no liquidity figure is dropped by the floor rather than treated as zero.

Honest failures

Rare enough to be worth stating: nothing on this API silently widens.

• unknown chain or token address → HTTP 200 with an empty list (raised here as no_pairs, never a silent zero-row success)
• nonsense search term → zero pairs, not an unfiltered baseline
• unknown pair → zero pairs, not a 404
• one-character search term → a real HTTP 400 (refused up front here)

Notes

• api.dexscreener.com/robots.txt is HTTP 404, which RFC 9309 §2.3.1.3 treats as no restrictions. No WAF: 6 of 6 TLS profiles returned identical JSON.
• DexScreener sends no rate-limit headers on any endpoint. Its published limits (300/minute for pairs, search and tokens; 60/minute for profiles and boosts) are real but invisible, so pacing is the only defence. The two tiers are paced separately.
• Boosted tokens are a promotion signal, not a quality one.