# Webhooks, WebSocket veya RPC Yoklama Arasında Seçim Yapın > Source: https://docs.blockvectra.com/tr/guides/webhook-vs-websocket/ Bir HTTPS alıcısına teslimat için adres Webhook'larını, desteklenen canlı abonelikler için WebSocket'i ve iş akışının kendi imlecine ve kurtarma mantığına ihtiyaç duyduğu durumlarda sınırlı yoklamayı kullanın. Geliştiriciler ve AI Agent'lar için zincir üstü olay dinleyicileri oluşturmak; uygulama mimarisini ağ yetenekleri, teslimat garantileri, alıcı kısıtlamaları ve operasyonel maliyetlerle eşleştirmeyi gerektirir. ## Karar matrisi Aşağıdaki tablo, desteklenen ağ yetenekleri, altyapı gereksinimleri, kurtarma stratejileri ve faturalandırma modelleri genelinde her üç entegrasyon mekanizmasını karşılaştırmaktadır: | Boyut | Adres Webhook'ları | WebSocket Abonelikleri | Sınırlı RPC Yoklaması | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Birincil mekanizma** | Genel bir uç noktaya HTTPS POST yoluyla iletilen push bildirimi | Kalıcı TLS bağlantısı (`wss://`) üzerinden akış (pull-stream) aboneliği | İstemci tarafından başlatılan HTTP JSON-RPC toplu veya zamanlanmış sorguları | | **Zincir kullanılabilirliği** | [GET /v1/push/chains](https://api.blockvectra.com/v1/push/chains) içinde bildirilen desteklenen tüm ağlar | Robinhood Chain üzerinde desteklenir (robinhood\_mainnet ve robinhood\_testnet); hizmet verilmeyen ağlar `ws: false` değerine sahiptir ve HTTP 404 döndürür | [GET /v1/chains](https://api.blockvectra.com/v1/chains) içindeki anahtarsız genel RPC veya kimliği doğrulanmış JSON-RPC aracılığıyla desteklenen tüm ağlar | | **Alıcı gereksinimleri** | Herkese açık HTTPS URL'si, geçerli TLS sertifikası, zaman aşımı içinde 2xx yanıtı, ham gövde HMAC SHA-256 imza doğrulaması | Giden TCP/TLS istemci bağlantısı (`wss://`); ping/pong sinyallerini ve yeniden bağlanma geri çekilmesini (backoff) yönetir | Durumsuz HTTP istemcisi veya zamanlanmış worker; yerel blok imlecini depolar | | **Teslimat ve sıralama** | Üstel yeniden deneme geri çekilmesi ile en az bir kez (at-least-once) teslimat; alıcı olay `id` değerine göre veya abonelikler genelinde `ref` + `type` ile tekilleştirmelidir | Tek bir etkin sokette kesin olarak sıralanmış çerçeveler; bağlantı kopmaları sırasında bildirimler bırakılır | Onaylanmış blok yükseklikleri için belirleyici çekme (pull) yanıtları; istemci yürütme hızını belirler | | **Zincir yeniden düzenlemeleri (reorg)** | `chain.reorg` için yayınlanan kontrol bildirimleri; alıcı kanonik yeniden oynatmaları uygulamadan önce değiştirilen olayları atar | Log bildirimleri, yeniden düzenlenen loglar için `"removed": true` taşır; `newHeads`, üst blok karması (parent hash) kontrolü gerektirir | İstemci, reorg'ları tespit etmek için yoklama döngüleri genelinde `parentHash` zincir sürekliliğini izler | | **Arıza kurtarma** | Sunucu saklama penceresi `POST /v1/push/subscriptions/{id}/replay` aracılığıyla yeniden oynatmaya izin verir; etkinleştirme bloğundan önceki boşluklar `eth_getLogs` ile geriye dönük doldurma gerektirir | Sunucu tarafında kuyruk yoktur; istemci yeniden bağlanır ve `(blockHash, transactionHash, logIndex)` ile tekilleştirilmiş olarak `eth_getLogs` ile kaçırılan aralıkları doldurur | Depolanan `last_synced_block` üzerinden sorgulamayı sürdürür; [GET /v1/chains](https://api.blockvectra.com/v1/chains) içindeki ağın `max_logs_block_range` değerine göre parçalara böler | | **Faturalandırma modeli** | UTC günü boyunca çevrimiçi durumdayken en yüksek adres sayısına dayalı olarak grup başına günlük adres ücreti, artı teslim edilen veri olayları için CU; bkz. [Webhook faturalandırması](https://docs.blockvectra.com/tr/guides/webhook-push/#billing-and-example) | El sıkışma ve bağlantı sinyalleri faturalandırılmaz; `eth_subscribe` / `eth_unsubscribe` ve sokete aktarılan bildirim birimleri CU cinsinden faturalandırılır | Compute Units cinsinden istek başına ölçülür: `eth_blockNumber`, `eth_call`, `eth_getLogs`; yöntem ağırlıkları ve 1 USD başına CU [GET /v1/plans](https://console-api.blockvectra.com/v1/plans) üzerinden alınır, aşağıda gösterilmiştir | | **En uygun kullanım alanı** | Kullanıcı yatırma takibi, sıcak cüzdan adresi izleme, satıcı ödeme noktaları, eşzamansız olay webhook'ları | Canlı `newHeads` ve filtrelenmiş `logs`, reaktif botlar, desteklenen ağlarda etkileşimli kullanıcı arayüzleri | Toplu mutabakat, cron işleri, ETL işlem hatları, WebSocket desteği olmayan zincirler (HyperEVM gibi) | **Aktif Dönüşüm Parametreleri** 1 USD = 10,000 faturalandırma birimi, 1 faturalandırma birimi = 1,000 CU (1 USD = 10,000,000 CU). **Formül**: CU ağırlığı × 1,000,000 ÷ (10,000 × 1,000) USD. | Yöntem | Çağrı başına CU | 1M çağrı başına fiyat (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 | ## Ne zaman adres Webhook'ları seçilmeli Arka uç sisteminiz gelen HTTPS isteklerini alabilen standart bir web hizmeti olarak çalıştığında [Blockchain Webhook API'sini](https://docs.blockvectra.com/tr/guides/webhook-push/) seçin: * **Büyük adres listeleri**: Cüzdan başına kalıcı soketler tutmadan binlerce müşteri adresi genelinde para yatırma veya çekme işlemlerini izleyin. * **Sunucusuz (serverless) veya konteynerli alıcılar**: Sunucusuz işlevler (AWS Lambda, Cloudflare Workers) gelen webhook'lar üzerine ayağa kalkar ve sürekli bağlantıları canlı tutmaları gerekmez. * **Otomatik yeniden denemeler ve yeniden oynatma**: Geçici alıcı kesintileri, otomatik yeniden deneme geri çekilmesi ile hafifletilir. Sunucu saklama penceresi içinde, kaçırılan teslimatlar yeniden oynatma uç noktası kullanılarak tekrar iletilebilir. * **Etkinleştirme sınırı hususları**: Eşleştirme yalnızca abonelik değişikliği uygulandıktan sonra başlar (`applied_from_block`). Bir adres eklenmeden önce veya bir abonelik `offline` durumundayken meydana gelen olaylar, geçmiş RPC logları aracılığıyla sorgulanmalıdır. Üretim webhook alıcılarını kullanıma sunmadan önce [imza doğrulama ve yeniden oynatma iş akışlarını](https://docs.blockvectra.com/tr/guides/webhook-push/#verify-signatures) gözden geçirin. ## Ne zaman WebSocket abonelikleri seçilmeli Düşük gecikme süresi gerektiğinde ve süreciniz uzun süre çalışan giden bir soketi koruyabildiğinde [WebSocket Aboneliklerini](https://docs.blockvectra.com/tr/guides/websocket-subscriptions/) seçin: * **Canlı blok başlıkları**: Her blok zincir tepesine eklendikçe `newHeads` akışını alın. * **Sözleşme olay filtreleri**: Bir adresle veya belirli bir `topic0` ile eşleşen gerçek zamanlı sözleşme `logs` akışını alın. * **Özel ortamlar**: Gelen genel HTTPS bağlantı noktasını açığa çıkaramayan NAT veya güvenlik duvarları arkasındaki yerel betikler, CLI araçları veya arka uç hizmetleri için idealdir. * **Ağ kullanılabilirliği kontrolü**: WebSocket, Robinhood Chain üzerinde desteklenir (ağ kısa adı `robinhood_mainnet`, Chain ID 4663 ve `robinhood_testnet`). HyperEVM şu anda WebSocket desteğine sahip değildir (`ws: false`); hizmet verilmeyen bir zincire WebSocket bağlantısı kurma girişimi HTTP 404 ([`unknown_chain`](https://docs.blockvectra.com/tr/errors/#unknown_chain)) döndürür. * **Bağlantı kesilme disiplini**: WebSocket bildirimleri bağlantı kesilmeleri boyunca sunucuda tutulmaz. Soket koptuğunda, istemciler rastgele üstel geri çekilme ile yeniden bağlanmalı ve kaçırılan blokları `eth_getLogs` ile geriye dönük doldurmalıdır. Filtre sınırları, bağlantı üst sınırları (anahtar başına 20, hesap başına 50) ve viem bağlantı örnekleri için [WebSocket Abonelikleri rehberini](https://docs.blockvectra.com/tr/guides/websocket-subscriptions/) inceleyin. ## Ne zaman sınırlı RPC yoklaması seçilmeli Zamanlanmış işleri, veri işlem hatlarını çalıştırırken veya WebSocket'in bulunmadığı ağlarda işlem yaparken sınırlı JSON-RPC yoklamasını seçin: * **WebSocket bulunmayan ağlar**: HyperEVM (`hyperevm_mainnet`) şu anda JSON-RPC HTTP erişimi sağlar ancak WebSocket sağlamaz (`ws: false`). Desteklenen blok aralıkları dahilinde `eth_blockNumber` yoklamak ve `eth_getLogs` sorgulamak, HyperEVM olay işlemeyi destekler. * **Kontrollü sorgu hızı**: Yoklama, geliştiricilerin ve AI Agent'ların istek sıklığını yönetmelerine, anahtar başına hız sınırlarına karşı Compute Unit tüketimini idare etmelerine ve uzun süren görevler sırasında soket düşmelerini önlemelerine olanak tanır. Anahtar başına sınırlar — varsayılanlar 400 CU/s ve ani artış (burst) 1,600 CU. * **Blok aralığı sınırları**: Kimliği doğrulanmış `eth_getLogs` sorguları, ağın [GET /v1/chains](https://api.blockvectra.com/v1/chains) içindeki `max_logs_block_range` değeriyle sınırlandırılmıştır. Bu sınırın aşılması `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/tr/errors/#logs_range_too_large)) hata kodunu döndürür. Daha geniş aralıkları, hedef ağın `max_logs_block_range` değerini aşmayan ardışık parçalara bölün. | Zincir | Zincir slug | max_logs_block_range (blok) | | --- | --- | --- | | 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 | Parçalama algoritmaları için [HyperEVM log geriye dönük doldurma rehberine](https://docs.blockvectra.com/tr/guides/hyperevm-backfill/) ve [eth\_getLogs blok aralığı rehberine](https://docs.blockvectra.com/tr/guides/getlogs-block-range/) bakın. Eksiksiz bir iş yükü kontrol listesi ve kendi kendine testler için [Bir RPC sağlayıcısı nasıl seçilir](https://docs.blockvectra.com/tr/guides/choose-rpc-provider/) ile başlayın. Düşük hacimli yoklama için bir sağlayıcı seçerken, [standart RPC faturalandırması ve kapsamı için sağlayıcıları karşılaştırın](https://docs.blockvectra.com/tr/guides/quicknode-alternative/). Kullanım faturalandırmasını deneme ve abonelik maliyetleriyle karşılaştırın; bildirim ve geriye dönük doldurma maliyetleri, RPC okumalarından farklı ölçüm birimleri kullanır. ## Uygulama rehberleri ### Robinhood Chain üzerinde WebSocket Robinhood Chain üzerinde canlı `newHeads` veya filtrelenmiş `logs` için kimlik doğrulama ve abonelik istekleri konusunda [WebSocket Abonelikleri rehberini](https://docs.blockvectra.com/tr/guides/websocket-subscriptions/) takip edin. Bağlantı kesildikten sonra geri çekilme ile yeniden bağlanın, yeniden abone olun ve `eth_getLogs` ile kaydedilmiş bir imleçten kaçırılan blokları geriye dönük doldurun; logları `(blockHash, transactionHash, logIndex)` ile tekilleştirin. ### HyperEVM üzerinde sınırlı yoklama HyperEVM (`hyperevm_mainnet`) için sınırlı yoklama ve kurtarma konusunda [HyperEVM log geriye dönük doldurma rehberini](https://docs.blockvectra.com/tr/guides/hyperevm-backfill/) takip edin. Kaydedilen imleçten `max_logs_block_range` içindeki parçalar halinde sorgulayın, başarılı işlemenin ardından olayları ve ilerlemeyi birlikte kalıcı kılın ve tamamlanmamış aralıkları yeniden deneyin. Yeniden düzenlemeleri (reorg) ele almak için zincir sürekliliğini kontrol edin ve örtüşen aralıkları tarayın. ## Sonraki adımlar * BlockVectra'nın indekslediği tüm veri kümelerini görmek için [veri kümeleri dizinine göz atın](https://blockvectra.com/tr/data/). * Hesabınızın neleri içerdiğini kontrol etmek için [ücretsiz planı ve fiyatlandırmayı inceleyin](https://blockvectra.com/tr/pricing/#free). * Bir API key oluşturmak için [konsolda oturum açın](https://console.blockvectra.com/login/?next=%2Fkeys%2F).