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

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

- Источник: https://papaproxy.net/ru/blog/dexscreener-trending.php
- Опубликовано: 2026-08-09
- Автор: Alex Young
- Рубрика: API и данные · Блог PapaProxy.net

---

## Ключевые выводы

- Эндпоинта трендов нет: рейтинг сайта считается внутри и через API не публикуется.
- Бусты умножают уже существующий Trending Score, а не создают его, поэтому забустенные и трендовые токены пересекаются, но это разные списки.
- В объектах бустов поверх полей профиля есть только `amount` и `totalAmount` — ни цены, ни ликвидности, ни отметки времени.
- Буст действует 12–24 часа в зависимости от пакета, а 500 активных бустов открывают Golden Ticker — вычислимый порог.
- Ни один буст-маршрут не фильтрует по сети, поэтому сканер только под Solana тратит тот же бюджет обнаружения, что и мультисетевой.
- Входы трендового счёта названы, а веса — нет, причём два из них (посещения страницы и реакции сообщества) не отдаёт ни один маршрут API, так что рейтинг не пересобрать.
- Отдельная страница документации `docs.dexscreener.com/api/websockets` публикует WebSocket API для тех же лент, оборачивая нагрузку в `{limit, data}`.

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

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

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

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

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

| Документированные входы Trending Score | Не публикуется |
| --- | --- |
| Объём, ликвидность, транзакции | Вес каждого сигнала |
| Уникальные мейкеры и держатели | Нормализация и затухание входов |
| Посещения страницы токена | Как множитель бустов сочетается с остальным |
| Реакции сообщества | Обработка равенств и «остываний» |
| Verified / Enhanced Token Info | Частота пересчёта рейтинга |
| Сигналы безопасности и аудита |  |

Два входа из этого списка — посещения страницы и реакции сообщества — вообще не ончейн и не отдаются ни одним маршрутом 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` соответствует величине конкретного буст-события, а `totalAmount` отражает активный итог по токену — один и тот же токен может появиться несколько раз со значениями `amount` 10 и 30 при едином `totalAmount` 70, тогда как другой показывает `amount` 500 при `totalAmount` 550. Считайте это наблюдаемым поведением, а не документированным контрактом, — и оно всё равно поддерживает полезный вывод: повторяющиеся мелкие события означают видимость, купленную порциями, одно крупное — единичный рывок. А переход `totalAmount` через 500 — порог Golden Ticker, то есть вычислимое событие, в отличие от самого рейтинга.

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

PythonКопировать код

```python
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}` привязан к сети, поэтому группируйте отфильтрованные адреса по сетям и отправляйте каждую группу отдельными пачками — та же двухуровневая схема, что в нашем [руководстве по новым парам](/ru/blog/dexscreener-new-pairs.php) для опроса профилей и запроса пар.

Практическая форма получается такой: один вызов за цикл к буст-маршруту, разделение по `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, и это нужно обработать. При подключении сервер отвечает объектом рукопожатия, а не голым массивом:

JSONКопировать код

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

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

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

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

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