Як обійти rate limits на NFT-майданчиках? OpenSea, Blur, Magic Eden

Як обійти rate limits на OpenSea?

При зборі даних з NFT-маркетплейсів розробники стикаються з різними підходами: OpenSea надає HTTP API з rate limit 2 req/sec безкоштовно, Blur не має публічного API взагалі, а Magic Eden вимагає окремої інтеграції для Solana та EVM. Команди витрачають тижні на імплементацію, не отримуючи стабільного результату. Ми вирішуємо це завдання більше 10 років: реалізували понад 40 проектів зі збору NFT даних, знайшли обхідні шляхи для кожного маркетплейсу. Економія часу розробки — до 40%, стабільність збору — в 10 разів вища. Наприклад, на проекті зі збору історії продажів колекції BAYC на OpenSea використання паралельних воркерів з Pro API ключем скоротило час збору з 2 тижнів до 3 годин. Замовте налаштування зараз — і через 5 днів дані будуть збиратися автоматично.

Rate limits та паралельний збір

OpenSea Developer API v2 — єдиний офіційний шлях. Методи: GET /api/v2/events/collection/{slug} для історії подій, GET /api/v2/listings/collection/{slug}/all для активних лістингів, GET /api/v2/collections/{slug}/stats для floor price та обсягів. Проблема: events endpoint віддає максимум 50 подій за запит, rate limit не задокументований, але на практиці 3 req/sec призводять до 429. Збір історії колекції з 100k+ продажами займає тижні при послідовному запиті. При 2 req/sec збір 5000 подій займає близько 42 хвилин; з Pro-ключем (20 req/sec) — 4 хвилини.

Оптимізація: паралельні воркери з token bucket алгоритмом та розбивка діапазону подій за occurred_after/occurred_before. З Pro API ключем ліміти зростають до 20 req/sec — збір тієї ж історії займає години. Для realtime використовуємо WebSocket Stream API на Phoenix Channels.

Відсутність публічного API на Blur

Дані Blur доступні через недокументований GraphQL (core-api.prod.blur.io/graphql) або через Reservoir Protocol. Reservoir в 10 разів стабільніший за прямий парсинг, оскільки обробляє rate limit та реорганізації ланцюга. SDK має вбудований retry з exponential backoff (1s, 2s, 4s, 8s) та rate limit 1 req/sec за замовчуванням.

import { createClient } from "@reservoir0x/reservoir-sdk" const client = createClient({ apiBase: "https://api.reservoir.tools", apiKey: KEY }) const sales = await client.getSales({ collection: "0x...", limit: 100 }) 

Розрив Solana/EVM в Magic Eden

Magic Eden має два несумісних API:

Developer API базується на Reservoir, Solana API v2 вимагає окремої інтеграції з пагінацією через offset. Для повної історії використовуємо on-chain парсинг через Helius з фільтрацією за program ID MEisE1HzehtrDpAAT8PnLHjpSSkRYakotTuJRPjTpo8. Середній час парсингу однієї колекції — 3 хвилини при 5 req/sec.

Чому Reservoir Protocol кращий за прямий парсинг Blur?

Прямий парсинг Blur через недокументований GraphQL загрожує блокуваннями та вимагає постійної адаптації. Reservoir Protocol агрегує дані on-chain, надаючи задокументований API з вбудованими retry та rate limit management. Економія часу розробки становить до 40%, а стабільність збору зростає в 10 разів.

Як налаштувати збір даних NFT за 5 днів

1. Отримати API ключі цільових маркетплейсів та налаштувати схеми зберігання.
2. Розробити HTTP воркери з retry/backoff та token bucket rate limiter.
3. Інтегрувати WebSocket для realtime оновлень.
4. Нормалізувати дані під єдину схему PostgreSQL з JSONB.
5. Розгорнути моніторинг (Grafana дашборд, алерти при падінні rate limit).

Антидетект та обхід лімітів

Якщо маркетплейс не дає API і потрібен browser scraping, використовуємо Playwright + rotating residential proxies + stealth plugin. Для rate limit менеджменту — token bucket з Redis як distributed rate limiter.

Що входить у налаштування збору даних

• Розробка архітектури та вибір стеку (Foundry/Hardhat для тестів, PostgreSQL для зберігання)
• Інтеграція WebSocket та HTTP воркерів з token bucket rate limiter та retry/backoff
• Нормалізація даних під єдину схему з JSONB полем для raw даних
• Моніторинг через Grafana з алертами при падінні rate limit
• Документація по розгортанню та оновленню
• Навчання вашої команди (1 година онлайн)
• Гарантія працездатності 30 днів

Зберігання та нормалізація даних

Схема для sales даних в PostgreSQL:

CREATE TABLE nft_sales ( id BIGSERIAL PRIMARY KEY, blockchain VARCHAR(20) NOT NULL, marketplace VARCHAR(20) NOT NULL, contract_address VARCHAR(42), token_id VARCHAR(78), seller_address VARCHAR(42), buyer_address VARCHAR(42), price_raw NUMERIC(38,0), price_usd DECIMAL(20,6), currency_symbol VARCHAR(10), transaction_hash VARCHAR(66) UNIQUE, block_number BIGINT, event_timestamp TIMESTAMPTZ NOT NULL, raw_data JSONB, created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX ON nft_sales (contract_address, event_timestamp DESC); CREATE INDEX ON nft_sales (marketplace, event_timestamp DESC); 

JSONB поле raw_data зберігає оригінальну відповідь API — при зміні структури даних маркетплейсу дані не втрачаються.

Процес та строки

День 1: Аналіз цільових маркетплейсів, отримання API ключів, розробка схеми зберігання даних, реалізація базових HTTP клієнтів з retry/backoff.

День 2–3: Воркери для історичного збору, WebSocket інтеграція для realtime, нормалізація даних між форматами різних площадок, документація та базовий моніторинг.

Результат: система збирає повну історію та тримає актуальні дані із затримкою до 30 секунд. Збір під ключ — 3–5 днів залежно від кількості маркетплейсів та глибини історії.

Отримайте консультацію по архітектурі збору даних — оцінимо ваш проект та запропонуємо оптимальне рішення.