DexScreener API: endpoints, limits, examples — and what it won't tell you

What the DexScreener API is (and is not)

The DexScreener API is a plain HTTPS/JSON interface with a handful of GET endpoints and no authentication. You call a URL, you get JSON back. It is meant for bots, dashboards, Telegram alert channels and research scripts that need current DEX data without scraping the website.

It is not a full market-data platform. There are no historical candles, no trade-by-trade feed, no account and no SLA; the only push channel is a set of WebSocket streams mirroring the "latest" lists (see below). Every response reflects "now" (with a short server-side cache), so anything you want to know about the past — what a token's market cap was an hour ago, when a badge appeared — you have to record yourself, which is the gap DXT Tools fills for paid activity.

Data coverage is the same as the site: every pair with liquidity on a supported DEX across 100+ chains, identified by a chainId (for example solana, ethereum, bsc, base) plus a pair or token address.

Every public endpoint

The reference groups the endpoints into two families. The "latest lists" (and the per-token orders lookup) — what is currently on the profile, boost, ad and CTO pages — share the smaller limit. The pair and token lookups share the larger one. All paths are relative to https://api.dexscreener.com.

Two more "latest" lists exist for the other two paid products — active ads and community takeovers — at /ads/latest/v1 and /community-takeovers/latest/v1 (both documented at 60 requests per minute, checked 23 Aug 2026); they behave like the boost list and our collector polls them on the same budget. The reference also lists /metas/trending/v1 and /metas/meta/v1/{slug} for DexScreener's "metas" (narrative tags), at the same limit. The 300-per-minute figure for the pair and token lookups is as published in the OpenAPI blocks of the reference and as our collector budgets for it; re-read the reference before relying on it.

One legacy path, /latest/dex/tokens/{addresses}, still answers without a chain, but the chain-scoped /tokens/v1/{chainId}/… form is the documented one and is faster because it does not have to guess the chain.

DexScreener API rate limits, in practice

The DexScreener API rate limit is per endpoint group, not per endpoint: the profile, boost, order, ad and CTO lists share a 60 requests per minute budget, and the pair, token and search lookups share a 300 requests per minute budget. Exceed one and you get HTTP 429 on that group while the other keeps working.

What the limit means for a real bot:

• Polling the "latest" lists in a round-robin at one request every 1.5 seconds uses about 40 of the 60 — the setting our own collector runs with. One per second is the absolute ceiling and leaves no room for retries.
• Responses are cached server-side for a short moment, so two calls inside the same second usually return the same JSON; polling faster than the cache refreshes just burns budget.
• Back off on 429 — wait 20–30 seconds before the next request to that group. Hammering through it extends the block.
• Batch token lookups: one /tokens/v1/{chainId}/… call with 30 addresses costs one request, not thirty.
• Limits are per client IP. A shared office, a NAT or a cloud function with a recycled egress IP shares one bucket.

There is no way to buy a higher limit. If 60 and 300 are not enough, the answer is caching and batching on your side, or reading a tracker such as DXT Tools that already does the polling (status page shows how the API is behaving right now).

DexScreener API pricing and API key: is it free?

Yes. There is no DexScreener API key, no registration and no paid plan; every endpoint in the reference is open to anyone who respects the rate limit. Searches for "dexscreener api pricing" usually end up on the marketplace, but that page sells products for token teams — Enhanced Token Info, boosts, ads — not API access. Paying for a profile or a boost changes what the API returns about that token; it does not change your limits.

The practical consequences: keep your own cache, expect the occasional 429 during busy launches, and do not put anything that needs a guaranteed feed behind a single anonymous endpoint. The terms of use on docs.dexscreener.com cover acceptable use; read them once if you run something commercial.

Example requests: curl, JavaScript, Python

Every call is a plain GET; no headers are required beyond a sensible User-Agent. The examples below are complete.

curl — the latest boost purchases across all chains:

curl -s https://api.dexscreener.com/token-boosts/latest/v1

curl — every pair of one token on Solana (replace the address):

curl -s https://api.dexscreener.com/token-pairs/v1/solana/TOKEN_ADDRESS

JavaScript (fetch, Node 18+ or browser) — price and market cap for a batch of tokens:

const r = await fetch("https://api.dexscreener.com/tokens/v1/solana/ADDR1,ADDR2"); const pairs = await r.json(); console.log(pairs[0].priceUsd, pairs[0].marketCap);

Python (requests) — search, then pick the most liquid pair:

import requests; pairs = requests.get("https://api.dexscreener.com/latest/dex/search", params={"q": "SOL/USDC"}, timeout=10).json()["pairs"]; best = max(pairs, key=lambda p: (p.get("liquidity") or {}).get("usd", 0))

Python — poll new Dex Paid profiles every 5 seconds (stay well inside the 60/min group):

import requests, time; URL = "https://api.dexscreener.com/token-profiles/latest/v1"; seen = set()

while True: items = requests.get(URL, timeout=10).json(); print([i["tokenAddress"] for i in items if i["tokenAddress"] not in seen]); seen.update(i["tokenAddress"] for i in items); time.sleep(5)

That is the whole mechanism behind a Dex Paid alert bot, and behind the DXT Tools collector: fetch the list, diff it against what you saw before, treat every new address as an event. Everything else — market cap at that second, ATH afterwards, "seen before" — is what you add on top.

Field names worth knowing in a pair object: chainId, dexId, pairAddress, baseToken.address, priceUsd, priceNative, liquidity.usd, fdv, marketCap, volume.h24, txns.h24.buys, priceChange.h1, pairCreatedAt, plus info (socials, images) once the team has bought a profile and boosts.active when boosts are running.

Common gotchas

• Pairs, not tokens. Almost every lookup returns pairs. A token with five pools returns five objects with five different prices and liquidities; pick the deepest one (highest liquidity.usd) before you display "the" price.
• chainId is a slug, not a number. Use solana, ethereum, bsc, base, arbitrum, polygon, avalanche, pulsechain, ton, tron, hyperevm and so on — the same segment you see in a dexscreener.com URL. EVM chain numbers like 1 or 56 do not work.
• Addresses are case-sensitive on Solana and checksummed-or-lowercase on EVM chains; both are accepted, but compare them consistently in your own code.
• Search is fuzzy. /latest/dex/search?q= matches symbol, name and address; a query by ticker returns every copycat. Resolve by contract address whenever you can.
• The "latest" lists are snapshots, not streams. They hold the most recent entries only; if you poll slower than the list turns over on a busy day, you miss items. totalAmount on a boost entry is the running total, amount is that purchase.
• Sub-second caching. Calling the same URL repeatedly within the cache window returns identical data; a cache-buster query parameter gets you past intermediate proxies, not past DexScreener's own cache.
• Null fields are normal. marketCap, fdv, info and boosts are absent or null for brand-new or unpaid tokens. Guard every access.
• No pagination. The endpoints return a fixed window; there is no page or offset parameter, and no way to ask for "boosts from yesterday".

Does the DexScreener API show paid tokens?

Partly. The DexScreener API shows which tokens are currently on the paid lists — the latest profiles, the latest and top boosts, active ads and community takeovers — and, per token, the /orders/v1 endpoint reports whether a profile, ad or takeover order exists, with its status and payment timestamp. That is the full extent of it, and it answers "is this token Dex Paid right now?".

It does not expose:

• a history — who paid last week, last month, or how many times the same team paid before;
• the market cap at the moment of payment, which is the number that tells you whether a team bought a boost at $40K or at $4M;
• what happened after — the ATH reached, whether the token held or flopped;
• boost purchases as events with timestamps (the boost lists give amounts and totals, not when each was bought);
• any cross-chain or per-hour aggregate — how much paid activity Solana had today versus Base.

All of that has to be recorded continuously by a third party. DXT Tools polls the lists above around the clock, stores every first-time profile, boost, ad and CTO as an event with the market cap at that second, tracks the ATH afterwards and labels flops — then serves it in a live feed on the home page, an insights page and a token check where you paste a contract and get its paid history. The paid services guide explains what each product costs and what our data says about outcomes.

Check a token's paid history →

DexScreener websocket and historical data

The reference now documents WebSocket streams at wss://api.dexscreener.com for the "latest" lists only — token profiles (latest and recent updates), community takeovers, ads, and boosts (latest and top) — pushing the same objects the REST lists return (websockets page, checked 23 Aug 2026). There is no documented stream for pair prices or trades: the website's own chart socket is undocumented and unsupported, and anything built on it breaks eventually. For price data the supported pattern is still polling the REST endpoints inside the limits; for paid-activity lists, the streams or polling both work.

For DexScreener historical data — candles, past prices, the state of the boost list an hour ago — you need another source or your own archive. Price history per pool is available from on-chain indexers and from APIs such as GeckoTerminal (which is what DXT Tools uses for the ATH-after-payment calculation), and paid-activity history is exactly what our archive keeps. If your question is "what was this token worth when it paid DexScreener", the token check already has the answer.