How to Scrape DexScreener Pairs by LP Address for a Live Watchlist in 2026

If you already know exactly which liquidity pools you care about — the LPs your bot trades, the pools your fund is exposed to, the positions on your dashboard — you don’t want to search or discover anything. You want to take a list of pair addresses and get back fresh price, liquidity and volume for all of them, fast, on a schedule. That’s the watchlist problem, and it’s distinct from token search or discovery. This guide covers how DexScreener’s pairs endpoint serves that, its batching behavior, and why a managed bulk resolver beats a hand-rolled poller.

What’s worth extracting

Per pool (keyed by its pair/LP address), the watchlist fields that drive trading and monitoring:

• Prices — USD price and native price (in the quote token).
• Liquidity — USD liquidity plus the base/quote token amounts in the pool.
• Valuation — FDV and market-cap estimates.
• Volume windows — 24h, 6h, 1h and 5m USD volume.
• Transactions — buy/sell counts across the same windows.
• Price change — windowed percentage change (5m / 1h / 6h / 24h).
• Identity — base/quote token symbols, addresses, names; pool creation timestamp; DEX label (v2/v3/stable); images and social links.

The 5-minute and 1-hour windows are what make this useful for bots and alerts — they catch liquidity drains and fast moves that a 24h number smooths over.

How the data is exposed

DexScreener’s documented public pairs endpoint takes pair addresses directly and, critically, batches up to 30 addresses per request:

GET https://api.dexscreener.com/latest/dex/pairs/{chainId}/{pairAddress1,pairAddress2,...,pairAddress30}

That batching is the key efficiency lever: 300 watched pools is 10 requests, not 300. It’s free and needs no API key. The constraint is that addresses must be batched per chain — you can’t mix chains in one batch — and the public endpoint is rate-limited around 300 requests/minute.

Rate limits and batching strategy

Done naively (one request per pool, no batching), a 500-pool watchlist refreshed every minute is 500 req/min — over the limit, instant 429s. Done right:

• Group addresses by chain, pack 30 per request, fire controlled-concurrency batches.
• Back off exponentially on HTTP 429.
• Optionally pre-filter by liquidity/volume so you’re not spending requests on dead pools.

A 500-pool, multi-chain watchlist done with batching is ~17 requests per refresh — trivially within limits. This batching-and-backoff orchestration is exactly what a managed scraper handles so your bot code stays clean.

▶ Run the DexScreener Pair Watchlist Scraper — bulk-resolves hundreds of LP/pool addresses across Solana, Ethereum, Base, BSC and 30+ chains in one run, batched 30 per request with 429 backoff. Real-time price, liquidity, FDV, volume and transactions as flat rows. No API key, pay per row.

Build it yourself vs. use a managed scraper

• Building from scratch — group by chain, pack batches of 30, manage concurrency and backoff, flatten the nested multi-window volume/txns/price-change objects, and maintain it. The batching math and the 429 tuning are the annoying parts.
• Using a managed actor — paste your address list, run, get a flat refreshed snapshot. Schedule it every minute/5-min/hour for a live feed your bot or dashboard reads.

For a handful of pools you can hit the endpoint directly. For a real watchlist refreshed on a tight cadence, the batching/backoff layer is what you’re really buying.

Schema design for downstream use

A flat per-pool snapshot row:

{
  "chain": "solana",
  "pair_address": "58oQ...Whirlpool",
  "dex": "orca",
  "label": "v2",
  "base_symbol": "SOL",
  "quote_symbol": "USDC",
  "price_usd": 168.42,
  "price_native": 168.42,
  "liquidity_usd": 12400000,
  "liquidity_base": 36800,
  "liquidity_quote": 6200000,
  "fdv_usd": null,
  "volume_24h_usd": 89000000,
  "volume_5m_usd": 142000,
  "txns_24h_buys": 41200,
  "txns_24h_sells": 39800,
  "price_change_5m": -0.3,
  "price_change_24h": 2.1,
  "pair_created_at": "2024-03-11T00:00:00Z",
  "scraped_at": "2026-05-25T12:00:00Z"
}

Decisions worth making early:

• Key everything on pair_address. A watchlist is about specific pools, not tokens — the LP address is your join key and dedup key.
• Store the short windows. 5m/1h volume and price change are what trigger alerts; don’t drop them to save columns.
• Stamp scraped_at per snapshot. Watchlist data is a time series of point-in-time readings; the timestamp is what makes diffing (liquidity drains, P&L) possible.
• Keep liquidity_base/liquidity_quote. USD liquidity hides composition; the token amounts let you detect one-sided drains.

Typical use cases

• Trading-bot watchlists — refresh price, liquidity, volume and txn counts for the specific LPs your algos trade.
• Cross-DEX arbitrage detection — compare the same token’s pools across DEXes to spot spreads.
• Cross-chain arbitrage — compare bridged-token pools across chains in one run.
• Portfolio dashboards — resolve held LPs into USD value, P&L and 24h change.
• Alert & notification services — detect liquidity drains, rapid moves or inactivity on watched pools.
• Risk monitoring — track liquidity on pools where a fund or protocol holds exposure.
• Compliance & accounting — snapshot pool price/liquidity for end-of-period valuation and audit trails.
• Smart-contract integration testing — verify LP state before deploys or upgrades.

Cost math for the managed approach

You pay per row (per pool snapshot), and batching keeps request volume tiny. A 300-pool watchlist refreshed every 5 minutes is 300 rows × 288 refreshes/day ≈ 86k rows/day — a fraction of a cent each lands it in the low hundreds of rows-per-dollar range, comfortably affordable for a production feed. A smaller 50-pool watchlist on a 5-minute cadence is pocket change. Against a self-hosted poller you skip the batching code, the backoff logic and the cron babysitting.

Common pitfalls

• No discovery here. This actor resolves addresses you already have — it does not search by symbol or find pairs for a token. Use the search or token-pairs scrapers for that; this one is the fast refresher for a known list.
• Can’t mix chains in a batch. Group by chain or your batch requests fail.
• Stale-pool noise. Dead pools return zero/low liquidity; pre-filter so they don’t clutter your watchlist.
• FDV can be null. Tokens without a clean supply figure report null FDV — guard downstream math.
• Snapshot, not stream. Even at 1-minute cadence this is polling; for sub-second needs you’d want a websocket feed, not a scraper.

Wrapping up

When you already know your pools, the job isn’t search — it’s fast, batched, scheduled refresh of a known address list. DexScreener’s 30-per-request pairs endpoint is built for exactly that, and the value of a managed scraper is the batching, backoff and flattening that keep your bot or dashboard fed without owning a poller.

▶ Open the DexScreener Pair Watchlist Scraper on Apify — schedule it on a tight cadence for a live multi-chain watchlist feed. Batched, backoff-safe, flat JSON/CSV. Pay per row, free monthly credit to start.