# Вибір між вебхуками, WebSocket або опитуванням RPC > Source: https://docs.blockvectra.com/uk/guides/webhook-vs-websocket/ Використовуйте вебхуки для адрес для доставки на HTTPS-отримувач, WebSocket — для підтримуваних підписок у реальному часі, та обмежене опитування — коли робочий процес потребує власного курсора та відновлення. Побудова слухачів ончейн-подій для розробників та AI-агентів вимагає узгодження архітектури застосунку з можливостями мережі, гарантіями доставки, обмеженнями отримувача та операційними витратами. ## Матриця рішень У наведеній нижче таблиці порівнюються всі три механізми інтеграції за підтримуваними можливостями мережі, вимогами до інфраструктури, стратегіями відновлення та моделями тарифікації: | Критерій | Вебхуки для адрес | Підписки через WebSocket | Обмежене опитування RPC | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Основний механізм** | Push-сповіщення, що доставляються через HTTPS POST на публічний ендпоінт | Підписка на потік через постійне з'єднання TLS (`wss://`) | Пакетні або заплановані HTTP JSON-RPC запити, що ініціюються клієнтом | | **Доступність у мережах** | Усі підтримувані мережі, зазначені в [GET /v1/push/chains](https://api.blockvectra.com/v1/push/chains) | Підтримується на Robinhood Chain (robinhood\_mainnet та robinhood\_testnet); непідтримувані мережі мають `ws: false` та повертають HTTP 404 | Усі підтримувані мережі в [GET /v1/chains](https://api.blockvectra.com/v1/chains) через публічний RPC без ключа або автентифікований JSON-RPC | | **Вимоги до отримувача** | Публічно доступна URL-адреса HTTPS, дійсний сертифікат TLS, відповідь 2xx у межах таймауту, перевірка підпису сирого тіла HMAC SHA-256 | Вихідне клієнтське з'єднання TCP/TLS (`wss://`); обробка пульсу ping/pong та затримка перед повторним підключенням | Безстанний HTTP-клієнт або запланований воркер; зберігає локальний курсор блоку | | **Доставка та порядок** | Доставка «щонайменше один раз» з експоненціальною затримкою повторних спроб; отримувач повинен дедуплікувати за `id` події або за `ref` + `type` між підписками | Суворо впорядковані фрейми в межах одного активного сокета; сповіщення втрачаються під час розриву з'єднання | Детерміновані pull-відповіді для підтверджених висот блоків; клієнт самостійно регулює швидкість виконання | | **Реорганізації мережі** | Керуючі сповіщення надсилаються для `chain.reorg`; отримувач відкидає замінені події перед застосуванням канонічних повторних відтворень | Сповіщення логів містять `"removed": true` для реорганізованих логів; `newHeads` вимагає перевірки хешу батьківського блоку | Клієнт відстежує неперервність ланцюжка `parentHash` між тактами опитування для виявлення реорганізацій | | **Відновлення після збоїв** | Серверне вікно збереження дозволяє повторне відтворення через `POST /v1/push/subscriptions/{id}/replay`; прогалини до блоку активації вимагають заповнення через `eth_getLogs` | Немає черги на боці сервера; клієнт перепідключається та відновлює пропущені діапазони через `eth_getLogs` із дедуплікацією за `(blockHash, transactionHash, logIndex)` | Відновлює запити зі збереженого `last_synced_block`; розбиває діапазон на частини відповідно до `max_logs_block_range` мережі з [GET /v1/chains](https://api.blockvectra.com/v1/chains) | | **Модель тарифікації** | Щоденна плата за групу адрес на основі найбільшої кількості адрес під час перебування онлайн за добу UTC, плюс CU за доставлені події даних; див. [Тарифікація вебхуків](https://docs.blockvectra.com/en/guides/webhook-push/#billing-and-example) | Рукостискання та перевірки пульсу не тарифікуються; `eth_subscribe` / `eth_unsubscribe` та скинуті одиниці сповіщень сокета тарифікуються в CU | Оплата за кожен запит у Compute Units: `eth_blockNumber`, `eth_call`, `eth_getLogs`; вага методів та CU за $1 з [GET /v1/plans](https://console-api.blockvectra.com/v1/plans), наведені нижче | | **Найкраще підходить для** | Моніторингу депозитів користувачів, відстеження гарячих гаманців, розрахунків мерчантів, асинхронних вебхуків подій | Отримання `newHeads` та відфільтрованих `logs` у реальному часі, реактивних ботів, інтерактивних інтерфейсів у підтримуваних мережах | Пакетної звірки, завдань cron, конвеєрів ETL, мереж без підтримки WebSocket (таких як HyperEVM) | **Активні параметри конвертації** 1 USD = 10,000 розрахункових одиниць, 1 розрахункова одиниця = 1,000 CU (1 USD = 10,000,000 CU). **Формула**: Вага CU × 1,000,000 ÷ (10,000 × 1,000) USD. | Метод | CU на виклик | Ціна за 1M викликів (USD) | | --- | --- | --- | | `eth_blockNumber` | 1 | $0.10 | | `eth_call` | 15 | $1.50 | | `eth_getLogs` | 30 | $3.00 | | `debug_traceTransaction` | 100 | $10.00 | | `data.block` | 5 | $0.50 | ## Коли обирати вебхуки для адрес Обирайте [Blockchain Webhook API](https://docs.blockvectra.com/en/guides/webhook-push/), коли ваш бекенд працює як стандартний вебсервіс, здатний приймати вхідні HTTPS-запити: * **Великі списки адрес**: моніторинг депозитів або виведення коштів на тисячах адрес клієнтів без підтримки постійних сокетів для кожного гаманця. * **Serverless або контейнеризовані отримувачі**: безсерверні функції (AWS Lambda, Cloudflare Workers) запускаються під час отримання вебхуків і не потребують підтримки постійного з'єднання. * **Автоматичні повторні спроби та відтворення**: короткочасні збої отримувача згладжуються автоматичними повторними спробами з експоненціальною затримкою. У межах серверного вікна збереження пропущені доставки можна отримати повторно за допомогою ендпоінта відтворення. * **Врахування межі активації**: зіставлення починається лише після застосування змін підписки (`applied_from_block`). Події, що відбулися до додавання адреси або під час перебування підписки в статусі `offline`, потрібно запитувати через історичні логи RPC. Ознайомтеся з [перевіркою підпису та процесами повторного відтворення](https://docs.blockvectra.com/en/guides/webhook-push/#verify-signatures) перед розгортанням отримувачів вебхуків у продакшені. ## Коли обирати підписки через WebSocket Обирайте [Підписки через WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/), коли потрібна низька затримка і ваш процес може підтримувати довготривалий вихідний сокет: * **Заголовки блоків у реальному часі**: потокова трансляція `newHeads` одразу після додавання кожного блоку до вершини ланцюга. * **Фільтри подій контрактів**: потокова трансляція `logs` контрактів у реальному часі, що відповідають адресі або певному `topic0`. * **Приватні середовища**: ідеально підходить для локальних скриптів, CLI-агентів або бекенд-сервісів за NAT чи фаєрволами, які не можуть відкрити вхідний публічний HTTPS-порт. * **Перевірка доступності мережі**: WebSocket підтримується на Robinhood Chain (слаг мережі `robinhood_mainnet`, Chain ID 4663 та `robinhood_testnet`). HyperEVM наразі не має підтримки WebSocket (`ws: false`); спроба підключення через WebSocket до непідтримуваної мережі повертає HTTP 404 ([`unknown_chain`](https://docs.blockvectra.com/en/errors/#unknown_chain)). * **Дисципліна відключення**: сповіщення WebSocket не зберігаються на сервері під час розриву з'єднання. Коли сокет закривається, клієнти повинні перепідключитися з рандомізованою експоненціальною затримкою та заповнити пропущені блоки через `eth_getLogs`. Перегляньте [Посібник із підписок через WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) щодо лімітів фільтрів, обмежень з'єднань (20 на ключ, 50 на акаунт) та прикладів підключення за допомогою viem. ## Коли обирати обмежене опитування RPC Обирайте обмежене опитування JSON-RPC під час запуску запланованих воркерів, конвеєрів даних або роботи в мережах, де WebSocket недоступний: * **Мережі без WebSocket**: HyperEVM (`hyperevm_mainnet`) наразі надає доступ до JSON-RPC через HTTP, але не підтримує WebSocket (`ws: false`). Опитування `eth_blockNumber` та запити `eth_getLogs` у підтримуваних діапазонах блоків забезпечують обробку подій HyperEVM. * **Контрольована швидкість запитів**: опитування дозволяє розробникам та AI-агентам регулювати частоту запитів, керувати споживанням Compute Units у межах лімітів швидкості на кожен ключ та уникати обривів сокета під час довготривалих завдань. Ліміти на ключ — за замовчуванням 400 CU/s і burst 1,600 CU. * **Ліміти діапазону блоків**: автентифіковані запити `eth_getLogs` обмежені значенням `max_logs_block_range` мережі з [GET /v1/chains](https://api.blockvectra.com/v1/chains). Перевищення цього ліміту повертає код помилки `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/en/errors/#logs_range_too_large)). Розбивайте ширші інтервали на послідовні частини, що не перевищують `max_logs_block_range` цільової мережі. | Мережа | Слаг мережі | max_logs_block_range (блоків) | | --- | --- | --- | | Arbitrum One | `arb_mainnet` | 1,000 | | Base | `base_mainnet` | 1,000 | | BNB Smart Chain | `bsc_mainnet` | 1,000 | | Ethereum | `eth_mainnet` | 1,000 | | Ethereum Sepolia | `eth_sepolia` | 1,000 | | HyperEVM | `hyperevm_mainnet` | 1,000 | | Polygon | `polygon_mainnet` | 1,000 | | Robinhood Chain | `robinhood_mainnet` | 1,000 | | Robinhood Chain Testnet | `robinhood_testnet` | 1,000 | Алгоритми розбиття на частини див. у [посібнику із заповнення логів HyperEVM](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) та [посібнику з діапазонів блоків eth\_getLogs](https://docs.blockvectra.com/en/guides/getlogs-block-range/). Повний контрольний список робочих навантажень та самотестування див. у посібнику [Як обрати RPC-провайдера](https://docs.blockvectra.com/en/guides/choose-rpc-provider/). Обираючи провайдера для опитування з низьким обсягом трафіку, [порівняйте провайдерів за тарифікацією стандартного RPC та покриттям](https://docs.blockvectra.com/en/guides/quicknode-alternative/). Порівняйте тарифікацію за фактичне використання з вартістю пробних періодів та підписок; витрати на сповіщення та відновлення використовують інші одиниці обліку, ніж читання RPC. ## Посібники з реалізації ### WebSocket на Robinhood Chain Для отримання `newHeads` або відфільтрованих `logs` у реальному часі на Robinhood Chain дотримуйтесь інструкцій з [Посібника з підписок через WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) щодо автентифікації та запитів на підписку. Після відключення перепідключіться із затримкою, відновіть підписку та довантажте пропущені блоки зі збереженого курсора за допомогою `eth_getLogs`; дедуплікуйте логи за `(blockHash, transactionHash, logIndex)`. ### Обмежене опитування на HyperEVM Для HyperEVM (`hyperevm_mainnet`) дотримуйтесь інструкцій з [посібника із заповнення логів HyperEVM](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) щодо обмеженого опитування та відновлення. Виконуйте запити зі збереженого курсора частинами в межах `max_logs_block_range`, зберігайте події та прогрес разом після успішної обробки і повторюйте спроби для незавершених діапазонів. Перевіряйте неперервність ланцюжка та скануйте діапазони, що перекриваються, для обробки реорганізацій. ## Наступні кроки * [Переглянути каталог наборів даних](https://blockvectra.com/en/data/), щоб ознайомитися з кожним набором даних, який індексує BlockVectra. * [Ознайомитися з безкоштовним планом та цінами](https://blockvectra.com/en/pricing/#free), щоб дізнатися, що включено у ваш акаунт. * [Увійти в консоль](https://console.blockvectra.com/login/?next=%2Fkeys%2F), щоб створити API key.