How DexScreener rate limits differ by endpoint

Two limits, not one

The rate limit documentation states the number in each endpoint's summary rather than on a separate page, which is why people miss that there are two. The rate limit per minute depends entirely on which route you call:

One caveat before you build a config around that table: the reference is edited in place, and routes have been added and removed without a version bump. Treat the list as a snapshot and re-check it against the live reference before a release. The two numbers themselves — 60 and 300 — have been stable.

Also note what the documentation states and what it doesn't. Each endpoint's summary gives its own limit; nothing says whether routes sharing a number draw on one shared bucket or on independent counters per endpoint. The 60/300 split is a useful way to talk about the API, not a documented statement about how the limiter is built.

The split has an internal logic once you see it. The 60-per-minute tier is everything that returns a curated list — profiles, boosts, ads, takeovers, trending metas — where the underlying data changes slowly and every caller wants the same response. The 300-per-minute tier is everything keyed by an address you already have. DexScreener is generous where your requests are specific and stingy where they're broad.

That inverts the economics most people assume. Discovery — finding what's new — runs on the scarce budget, while enrichment — pricing and measuring what you found — runs on the generous one. Any design that polls a discovery feed aggressively and looks up pairs sparingly has it backwards. If your goal is new pairs from the API, that two-stage pattern — poll profiles at 60, enrich at 300 — is exactly the split this table describes.

One number to keep in perspective: 60 requests per minute is one per second, and that's the ceiling you're allowed to plan around regardless of how often the underlying data actually changes. On the lookup side, requests per minute matter much more, and that's where batching comes in.

Which routes sit at 60

Worth naming the pattern rather than memorising the list: if a route returns a list you didn't parameterise, it's in the 60 tier. Profiles latest and recent-updates, community takeovers, ads, both boost routes, trending metas, meta-by-slug — none of them takes a filter for chain, age or size, so every caller gets essentially the same payload, and 60 calls a minute is plenty to stay current with it.

The one route in this tier that isn't a curated list is /orders/v1/{chainId}/{tokenAddress} — it checks paid orders for a specific token, and it's parameterised, but it sits at 60 anyway. If your pipeline verifies order status per token, that's the endpoint that will throttle you first, not the pair lookups around it.

The public API rate limit applies without any key: every route in the reference is an unauthenticated GET, and the published 60 and 300 figures come with no self-service upgrade path documented alongside them. That isn't the whole picture, though. DexScreener's API Terms & Conditions state that users may choose between a free and a paid version of the API Services, with specifications such as rate limiting and requests per second detailed at checkout. So "free tier" is a reasonable description of what the public reference exposes, but not evidence that a higher tier doesn't exist — if you need more headroom, that's a conversation with DexScreener rather than a parameter you can send.

Making 30 addresses fit in one call

Here's the lever that changes a project's arithmetic. /tokens/v1/{chainId}/{tokenAddresses} accepts, in the reference's own words, one or multiple comma-separated token addresses — up to 30 addresses — and returns the pairs for all of them in a single response. It sits in the 300-per-minute tier.

Multiply that out: 30 addresses × 300 calls per minute = 9,000 token-address inputs a minute from one caller, against 300 if you query one address at a time through /token-pairs/v1/{chainId}/{tokenAddress}. That's a thirty-fold difference for the cost of a join.

import requests

BASE = "https://api.dexscreener.com"
HEAD = {"Accept": "application/json"}

def chunks(items, size=30):                 # documented ceiling: 30 addresses per call
    for i in range(0, len(items), size):
        yield items[i:i + size]

def pairs_for_tokens(chain_id, addresses):
    out = []
    for batch in chunks(addresses):
        r = requests.get(f"{BASE}/tokens/v1/{chain_id}/{','.join(batch)}",
                         headers=HEAD, timeout=15)
        if r.status_code == 429:            # not documented, but handle it anyway
            raise RuntimeError("rate limited — back off and retry")
        r.raise_for_status()
        out.extend(r.json() or [])
    return out

# 90 tokens → 3 calls instead of 90
pairs = pairs_for_tokens("solana", token_list)
print(len(pairs), "pairs from", len(token_list), "tokens")

What to look at: the chunking is the whole point, and the batch ceiling is a hard 30 — send 31 and you're relying on undefined behaviour. Note also that one token can return several pairs, so the response length won't match your input length; key results by pairAddress rather than assuming a one-to-one mapping.

What this deliberately doesn't do: no backoff, no retry, no concurrency control. Add those before running it against a large list, because at 300 calls a minute a naive loop with parallel workers will cross the line quickly.

The planning arithmetic follows directly, with one honest label attached — these are theoretical minimums at the published limit, assuming 300 evenly available calls a minute and no burst or global limiter that the documentation doesn't describe:

Plan below these figures, not at them. Beyond roughly nine thousand token addresses at a one-minute cadence, a single caller runs out of published budget — and that's where the question stops being about code.

What happens at the limit

Here the honest answer is that the documentation doesn't say. The reference specifies the numbers and the 200 response shape for each route; it doesn't define the status code you get when you exceed a limit, whether any headers report your remaining budget, how the window resets, or — importantly — what the counter is keyed on.

Design for that uncertainty rather than around it:

Count on your side. Since nothing in the response is documented to tell you where you stand, a client-side counter is the only reliable budget — and until you've measured otherwise, count per endpoint rather than per tier, since the docs never say whether routes sharing a number share a bucket. Treat your counter as authoritative and any error as confirmation you were already over.

Handle 429 without depending on it. The conventional response is HTTP 429, and the snippet above checks for it — but since it isn't documented, don't build logic that assumes a Retry-After header will arrive with a usable value. Exponential backoff with jitter, driven by your own counter, survives whatever the server actually does.

Watch latency as well as status codes. Some platforms throttle before they reject, and a client that only alerts on error codes will look healthy while its data goes stale. Track the p95 of your request duration per route.

Don't assume the scope. With no API key, there's no account for usage to attach to, so the count can only key on something at the network level — but the reference doesn't state that, doesn't promise an independent budget per address, and describes no burst model. Measure the actual behaviour before designing a fleet around an assumption about it.

That last point is where infrastructure enters, and only after the software levers are spent: batch to 30, cache the profile feeds instead of re-polling them, poll discovery no faster than the data changes, and enrich by address rather than by broad sweep. Past those, if your measurements confirm that separate callers really do get separate budgets, our proxies for crypto projects provide dedicated IPv4 addresses, static for the full plan term — one per worker, so a burst in one job can't consume another's allowance. And read the API Terms before scaling, because they're specific rather than vague: commercial use is permitted, but you may not use the API to build or market a product whose primary purpose competes directly with DexScreener, and you may not resell, sublicense or otherwise make the API Services available to third parties.