Почему в API DexScreener нет эндпоинта трендов

Трендовый список DexScreener — это рейтинг, который сайт считает сам и наружу не отдаёт. Ближайшие маршруты API возвращают забустенные токены, то есть оплаченное продвижение: оно коррелирует с трендом, но списком тренда не является, — и от понимания этой разницы зависит, измеряет ваш сканер рынок или маркетинговые бюджеты.

Что показывает сайт и что возвращает API

Трендовый список на сайте ранжирует токены по Trending Score, который считается из ончейн- и оффчейн-метрик. Маршрута для него в API нет. Ни эндпоинта трендов, ни ленты трендовых пар, ни параметра сортировки по рангу ни на одном документированном маршруте.

Вместо этого есть /token-boosts/: latest/v1 для токенов, которые только что забустили, и top/v1 для токенов с наибольшим числом активных бустов. Оба документированы с лимитом 60 запросов в минуту — дефицитный уровень из нашего руководства по лимитам DexScreener. Документация эндпоинта трендов, которую ищут, на практике оказывается документацией бустов — и подмена срабатывает не всегда.

Прежде чем говорить о связи этих двух вещей, стоит посмотреть, из чего складывается сам счёт, — это объясняет, почему никакая работа с публичным API его не восстановит. DexScreener называет входные сигналы, но не формулу:

Два входа из этого списка — посещения страницы и реакции сообщества — вообще не ончейн и не отдаются ни одним маршрутом API, поэтому даже идеальная реплика ончейн-половины останется без части слагаемых. Это структурная причина, по которой рейтинг нельзя пересобрать через публичный API, а не просто «его там нет».

Вот связь, сформулированная настолько точно, насколько позволяет документация. Бусты не создают рейтинг — они умножают уже существующий Trending Score. DexScreener говорит об этом прямо: бусты применяют множитель к имеющемуся счёту токена и не заменяют прочие ончейн- и оффчейн-метрики алгоритма ранжирования, поэтому токен со слабыми показателями не попадёт наверх одной лишь покупкой. Отсюда два следствия, направленных в разные стороны. Сильно забустенный токен вероятно виден в трендовом списке, так что top/v1 — неплохой прокси для «что сейчас проталкивают в поле зрения». Но в трендовом списке есть и токены, ничего не покупавшие, а в лентах бустов — токены, которых показатели никуда не подняли. Считайте бусты сигналом о расходах на продвижение, а не рейтингом.

Ещё одно различие, которое стоит держать в голове, потому что выдача их смешивает. У DexScreener есть отдельный продукт Metas — курируемые тематические нарративы, каждый из которых агрегирует множество токенов, — и это снова не то же самое, что трендовый список пар. Открывает ли публичный справочник API маршрут для Metas прямо сейчас, со временем менялось: справочник правят на месте, маршруты появлялись и исчезали без смены версии, поэтому сверяйтесь с живой страницей, а не со статьями, включая эту.

Две мелкие ловушки, которые встречаются в реальных логах запросов. /latest/dex/search?q=trending вернёт токены, в названии или символе которых буквально есть слово «trending», — поиск сопоставляет текст, а не ранг. А /orders/v1/{chainId}/{tokenAddress} перечисляет типы заказов, среди которых есть trendingBarAd: это купленное рекламное размещение на трендовой панели, а не Trending Score и не органическое место в рейтинге. Токен с оплаченным заказом trendingBarAd — это токен, купивший баннерный слот, и знать об этом стоит до того, как принимать его за сигнал ранжирования.

Как на самом деле устроены бусты

Понимание продукта объясняет данные. Буст покупается пакетами, действует от 12 до 24 часов в зависимости от пакета, а число активных бустов показывается рядом с токеном по всей платформе. При 500 и более активных бустах токен получает Golden Ticker, который окрашивает его символ в золотой по всему сайту. Забустить можно не всё: токены, неактивные более 24 часов, и токены, помеченные партнёрами по аудиту как рискованные, недоступны для бустов; покупки не возвращаются; а сами бусты могут быть сняты, если модераторы или аудиторы признают токен вредоносным.

Объекты API отражают эту модель. Оба буст-маршрута возвращают одну форму — поля профиля токена (url, chainId, tokenAddress, icon, header, description, links) плюс два числа:

Эта пара и есть вся аналитическая ценность эндпоинта забустенных пар — правда, схема только называет поля, не определяя их. В живой ленте поведение читается однозначно: amount соответствует величине конкретного буст-события, а totalAmount отражает активный итог по токену — один и тот же токен может появиться несколько раз со значениями amount 10 и 30 при едином totalAmount 70, тогда как другой показывает amount 500 при totalAmount 550. Считайте это наблюдаемым поведением, а не документированным контрактом, — и оно всё равно поддерживает полезный вывод: повторяющиеся мелкие события означают видимость, купленную порциями, одно крупное — единичный рывок. А переход totalAmount через 500 — порог Golden Ticker, то есть вычислимое событие, в отличие от самого рейтинга.

Чего в объектах бустов нет — так это отметки времени, цены, ликвидности и объёма. Они идентифицируют токен и его продвижение, и только. Чтобы понять, стоит ли продвигаемый токен чего-нибудь, его обогащают через маршруты пар с лимитом 300 запросов в минуту:

import requests

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

def top_boosted():                                    # уровень 60 запросов/мин
    r = requests.get(f"{BASE}/token-boosts/top/v1", headers=HEAD, timeout=15)
    r.raise_for_status()
    data = r.json()
    return data if isinstance(data, list) else data.get("data", [])

def enrich(chain_id, addresses):                      # уровень 300 запросов/мин, по 30 за вызов
    out = []
    for i in range(0, len(addresses), 30):
        batch = ",".join(addresses[i:i + 30])
        r = requests.get(f"{BASE}/tokens/v1/{chain_id}/{batch}", headers=HEAD, timeout=15)
        r.raise_for_status()
        out.extend(r.json() or [])
    return out

boosts = {b["tokenAddress"]: b for b in top_boosted() if b["chainId"] == "solana"}
for pair in enrich("solana", list(boosts)):
    b = boosts[pair["baseToken"]["address"]]
    liq = (pair.get("liquidity") or {}).get("usd") or 0
    print(f"{pair['baseToken']['symbol']:<12} бустов={b['totalAmount']:>5.0f}  ликв.=${liq:>12,.0f}")

На что смотреть: бусты берутся с дефицитного уровня, обогащение — со щедрого, пачками по 30 адресов на вызов. Объект liquidity допускает null — отсюда защитное or {}. А связывание идёт по baseToken.address: забустенный токен может присутствовать в нескольких парах, поэтому решите, нужен вам самый ликвидный пул или все.

Чего пример не делает: нет дедупликации между опросами, нет персистентности, нет отступления при упоре в лимит и нет группировки по сетям — фильтр выше по построению работает с одной сетью за раз, о чём следующий раздел.

Как отфильтровать забустенные токены по сети

Ни один из буст-маршрутов не принимает параметр сети. Оба возвращают смешанный список по всем сетям, которые индексирует DexScreener, поэтому «трендовые токены в Solana» — как и в Base, и где угодно ещё — означает фильтрацию chainId на клиенте, ровно как в сниппете выше.

У этого есть бюджетное следствие, которое стоит закладывать. Раз попросить API об одной сети нельзя, вы платите те же 60 запросов в минуту независимо от узости интереса: мультисетевой сканер и сканер только под Solana расходуют одинаковый бюджет обнаружения. Экономия появляется на стороне обогащения: /tokens/v1/{chainId}/{tokenAddresses} привязан к сети, поэтому группируйте отфильтрованные адреса по сетям и отправляйте каждую группу отдельными пачками — та же двухуровневая схема, что в нашем руководстве по новым парам для опроса профилей и запроса пар.

Практическая форма получается такой: один вызов за цикл к буст-маршруту, разделение по chainId на клиенте и один пакетный вызов обогащения на каждую сеть на каждые тридцать адресов.

Поток бустов вместо опроса

Вот часть, которую пропускает большинство обзоров: DexScreener публикует WebSocket API на отдельной странице документации — docs.dexscreener.com/api/websockets, вне REST-справочника, и заметить её трудно, потому что со страницы справочника на неё ничего не ведёт. Заголовок её OpenAPI-спеки — «DEX Screener Websocket API», база — wss://api.dexscreener.com, а пути зеркалят REST: /token-boosts/latest/v1, /token-boosts/top/v1, /token-profiles/latest/v1, /token-profiles/recent-updates/v1, /community-takeovers/latest/v1, /ads/latest/v1.

Форма сообщения отличается от REST, и это нужно обработать. При подключении сервер отвечает объектом рукопожатия, а не голым массивом:

{ "limit": 90, "data": [ { "chainId": "solana", "tokenAddress": "...", "amount": 10, "totalAmount": 520, "url": "..." } ] }

То есть полезная нагрузка — это {limit, data}, где в data лежат те же объекты Boost, что возвращает REST-маршрут. Код, написанный под REST-ответ, сломается на лишней обёртке: разбирайте защитно, как в сниппете выше.

Для монитора бустов это лучший транспорт, и не из-за лимитов. Поток снимает задачу диффа: при опросе вы сравниваете каждый ответ с собственным хранилищем, чтобы найти изменения, и всё, что успело появиться и исчезнуть между двумя опросами, для вас невидимо. При подписке обновления приходят по факту — а для ленты, весь смысл которой «кто только что заплатил за видимость», это разница между «поймать покупку» и «догадаться о ней».

Две оговорки, прежде чем переписывать сканер. Самого трендового списка здесь всё равно нет: поток бустов транслирует бусты, а не рейтинг сайта. И документация вебсокета описывает подключение и полезную нагрузку, но не семантику переподключения, — поэтому считайте обрыв разрывом в состоянии: переподключитесь, примите нагрузку рукопожатия за новую точку отсчёта и сверьтесь с хранилищем вместо предположения о непрерывности.

Где здесь появляется инфраструктура? Для этой задачи — почти нигде. Одно вебсокет-соединение полностью заменяет цикл опроса, а сторона обогащения группирует по тридцать адресов на вызов. Масштаб становится вопросом, только когда независимых мониторов много — разные сети, разные стратегии, разные клиенты, — и даже тогда первый ход состоит в том, чтобы свести их к одному потоку и одному воркеру обогащения, а не размножать поллеры. Если и после этого нужны параллельные воркеры с раздельными бюджетами, наши персональные прокси дают выделенные IPv4-адреса, статичные на весь срок плана, по одному на воркера, — но сначала измерьте область действия ограничителя, поскольку документация её не определяет, и прочитайте условия использования API: коммерческое применение разрешено, а вот продукт, напрямую конкурирующий с DexScreener, и перепродажа API третьим лицам — нет.