TradingView Webhook Çalışmıyor mu? 8 Yaygın Neden ve Düzeltme Kontrol Listesi

TradingView'da bir uyarı kurdunuz, webhook URL'nizi yapıştırdınız ve sonra… hiçbir şey. Ya da daha kötüsü: bazen çalışıyor, bazen çalışmıyor ve belirgin bir desen yok.

Bunların hepsini kendim yaşadım ve başkaları için de bolca debug ettim. Sonuç: "webhook çalışmıyor" vakalarının %90'ı sihir değil — birkaç sabit nedene düşer. Aşağıda en sık olandan en nadire doğru sıralandılar. Tek tek ilerleyin, neredeyse her zaman suçluyu bulursunuz.

1. TradingView planınız webhook içermiyor

En yaygın neden ve kaçırılması en kolay olanı. Ücretsiz (Basic) plan webhook desteklemez — Essential veya üzeri gerekir.

Nasıl kontrol edilir: uyarı oluştururken iletişim kutusunun altındaki Notifications sekmesine kaydırın. Hiç "Webhook URL" seçeneği yoksa sorun planınızdadır — başka her şeyi debug etmeyi bırakın.

2. URL HTTPS değil veya garip bir port kullanıyor

TradingView'ın alıcı URL için birkaç katı kuralı vardır. Birini bile ihlal ederseniz hiçbir şey gitmez:

• https:// olmalı — http:// doğrudan reddedilir;
• Yalnızca 80 ve 443 portları kabul edilir — başka portlu URL (ör. :3000, :8080) reddedilir;
• IPv6 yok — alan adı IPv4 adresine çözülmelidir;
• Yerel adresler yok — TradingView sunucuları localhost, 127.0.0.1 veya 192.168.x.x adreslerine ulaşamaz.

Kendi makinenizde bir script test ediyorsanız bu neredeyse her zaman ısırır — yerelde çalıştığını varsayarsınız, ancak TradingView dışarıdan kutunuza ulaşamaz.

3. İki faktörlü kimlik doğrulama etkin değil

Gizli bir neden: TradingView webhook uyarılarına yalnızca iki faktörlü kimlik doğrulama (2FA) etkin hesaplarda izin verir. 2FA olmadan uyarı webhook URL'sini kaydetmeyi reddedebilir veya kaydedip hiç göndermeyebilir. Önce hesap güvenlik ayarlarında 2FA'yı açın.

4. 403 / 401 görüyorsanız: kendi sunucunuz engelliyor

Kendi barındırdığınız bir script veya hizmet çalıştırıyorsanız ve uyarı günlüğünde 403 veya 401 görüyorsanız hızlıca daraltabilirsiniz:

• 403: sunucu TradingView'ı "tanıyor" ama engelliyor. Genelde güvenlik duvarı kuralı, CSRF kontrolü veya TradingView'ı içermeyen IP izin listesi. TradingView webhook'ları sabit bir IP kümesinden gelir — bunları izin listenize ekleyin.
• 401: kimlik doğrulama başarısız. Büyük olasılıkla yanlış/süresi dolmuş secret veya token, ya da yukarıdaki 2FA sorunu.

Saldırı sırası: secret'ın iki tarafta eşleştiğini doğrulayın, güvenlik duvarı/izin listesinin TradingView'a izin verdiğini doğrulayın, sonra endpoint'inize doğrudan curl ile vurun ve yanıt verip vermediğine bakın.

5. 3 saniyelik zaman aşımı: aralıklı düşmelerin gizli nedeni

TradingView'ın gözden kaçan katı bir kuralı var: sunucunuz 3 saniye içinde yanıt vermeli, aksi halde teslimat başarısız sayılır.

Bu, "bazen çalışıyor, bazen çalışmıyor" raporlarının gerçek nedeni. Sunucunuz genelde hızlıdır, ancak ara sıra yavaşlar — yavaş DB sorgusu, downstream API çağrısı, soğuk başlangıç — 3 saniyelik çizgiyi geçer ve o uyarı gider. TradingView sizin için yeniden denemez.

Doğru yaklaşım: alındığında hemen 200 dönün, yönlendirmeyi arka planda asenkron işleyin. Bu adım el yapımı scriptlerde sürekli atlanır; yoğun dönemlerde aralıklı düşmeler başlar.

6. Uyarı günlüğünde 4xx / 5xx: sorun alıcı tarafta

TradingView uyarı panelinde webhook durumu sütunu vardır; tam hatayı görmek için üzerine gelin. Durum koduna göre kabaca:

• 400: payload bozuk — genelde hatalı JSON veya alıcının gerektirdiği eksik alan. JSON doğrulayıcıdan geçirin.
• 404 / 410: yanlış URL veya hedef (ör. Discord webhook) silinmiş.
• 5xx: alıcının kendisi çöktü veya geçici hata verdi — loglarına bakın.

Faydalı bir numara: webhook URL'sini geçici olarak webhook.site gibi herkese açık bir test endpoint'ine yönlendirin. Oraya geliyor ama kendi URL'nize gelmiyorsa sorun %100 alıcı tarafınızdadır, TradingView değil.

7. Payload formatı: düz metin vs JSON

Varsayılan olarak TradingView uyarı gövdesini düz metin olarak gönderir; yalnızca Message alanında geçerli JSON varsa application/json content-type ekler.

Alıcınız yalnızca JSON kabul ediyorsa ama Message'a düz cümle yazdıysanız ayrıştırma başarısız olur. Alan şablonlaması (symbol, action, price vb.) için JSON kullanın:

{
  "symbol": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "price": "{{close}}"
}

8. Düşmedi — "spam" veya "hayalet" uyarılar

Farklı bir sorun sınıfı: "hiçbir şey gelmedi" değil, "çok fazla geldi" veya "gelmemesi gereken şeyler":

• Yinelenen spam: uyarı koşulu once_per_bar kullanıyor, mum kapanmadan tekrar tekrar tetikleniyor. Çoğu strateji uyarısı once_per_bar_close (kapanmış mumda bir kez) kullanmalıdır.
• Hayalet / geçmiş uyarılar: Bar Replay veya yeniden başlatmadan sonra geçmiş mumlar yeniden hesaplanır ve eski sinyaller seli gelir.
• Aynı uyarı iki kez: ağ kesintisinde TradingView ara sıra aynı uyarıyı yeniden gönderir; alıcıda dedup yoksa iki kez iletirsiniz.

İşaretleyebileceğiniz bir kontrol listesi

Sırayla gidin — çoğu sorun ilk birkaç maddede çözülür:

1. ☐ Plan Essential veya üzeri mi? (uyarıda Webhook URL seçeneği görünüyor)
2. ☐ Hesapta iki faktörlü kimlik doğrulama (2FA) etkin mi?
3. ☐ URL https:// ve standart dışı port yok mu?
4. ☐ URL herkese açık bir alan adı mı, localhost / özel IP değil mi?
5. ☐ webhook.site ile test edildi — geliyor mu? (evet → sorun alıcınızda)
6. ☐ Alıcı "önce 200 dön, sonra asenkron işle" ile 3 saniyenin altında mı kalıyor?
7. ☐ Kendi barındırma: güvenlik duvarı/izin listesi TradingView sabit IP'lerine izin veriyor mu?
8. ☐ Message geçerli JSON mu? (alıcı JSON bekliyorsa)
9. ☐ Tetikleyici spam önlemek için once_per_bar_close mı?
10. ☐ Başarısız uyarılar yeniden deneniyor ve loglanıyor mu — yoksa iz bırakmadan kayboluyor mu?

Her seferinde debug etmekten iyisi: kırılmayan bir alıcı

Yukarıdaki 5–10. maddelerin hepsi aynı köke işaret eder: alıcınız (yönlendirme scripti/hizmeti) yeterince sağlam değil. Kendi Cloudflare Worker veya VPS scriptiniz genelde "çalışır", ancak güvenilirliği gerçekten belirleyen ayrıntıları atlar — 3 saniyelik yanıt, hatada yeniden deneme, dedup ve denetim izi.

Tam da bunu SignalTo halleder: kullanıma hazır bir alıcı URL'si verir — HTTPS yerleşik, anında yanıt (önce kabul eder, asenkron yönlendirir, 3 saniyelik sınırda takılmaz), otomatik gelen dedup, hatada otomatik yeniden deneme ve her mesaj için tam teslimat kaydı. Kontrol listesindeki en zor maddeler sizin için çözülmüş olur.

Ücretsiz kararlı bir alıcı URL'si alın →