Webhook mu Polling mi? Tıklama Takibi Karşılaştırması

Bir kişinin ya da iş akışının saniyeler içinde tepki vermesi gerekiyorsa webhook kullanın; birkaç dakikalık gecikme sorun değilse ve genel bir uç nokta işletmek istemiyorsanız polling yapın. Elido'da seçimin bir püf noktası var: tıklama takibi webhook'ları henüz yok. Webhook'lar bağlantı, alan adı, üye ve çalışma alanı olaylarını kapsar; tıklama başına bir click.created olayı planlanıyor ama yayımlanmıyor. Bugün tıklama verisi, analitik API'sini sorgulayarak gelir.

Bu yazı gecikme ve istek hacmi üzerinden hesap yapar, her kalıbın neyi garanti ettiğini (yeniden denemeler, yinelenenler, sıralama, imzalar) ele alır ve bir karar tablosuyla biter. Kod, yazıya girmeden önce Node 22'de yerel sahte sunuculara karşı çalıştırıldı. Tam bağlantı olayı kataloğu için bağlantı olayları için webhook'ları; tıklama uç noktaları için bağlantı analitiği API rehberini okuyun.

Webhook ve Polling: Her Biri Bir Paragrafta

Polling, kodunuzun yeni veriyi bir takvime göre istemesi demektir. Bir cron işi GET /v1/workspaces/{workspace_id}/analytics/clicks/recent çağırır, yeni olanı işler ve uyur. Her isteği siz başlatırsınız. Genel bir URL gerekmez.

Webhook'lar yönü tersine çevirir. Bir olay tetiklendiğinde Elido, HTTPS uç noktanıza JSON zarflı imzalı bir POST gönderir ve 2xx yanıtı teslimi tamamlanmış sayar. Erişilebilir bir uç noktaya ihtiyacınız var. TLS. Yinelenenlerden sağ çıkan bir işleyici. Bugün olaylar link.created, link.updated, link.expired, domain.verified ve webhook belgelerindeki listenin geri kalanıdır.

Gecikme ve Maliyet Hesabı

Polling gecikmesi aralıkla belirlenir. I dakikalık bir aralıkta bir olay ortalama I/2 dakika, en kötü durumda I dakika bekler; buna verinin sorgulanabilir olmadan önceki gecikmesi eklenir. Günlük istek sayısı 1.440 / I'dır.

• 1 dakika: günde 1.440 istek, ortalama 30 saniye gecikme, en kötü durumda 1 dakika.
• 5 dakika: 288 istek, ortalama 2,5 dakika, en kötü durumda 5 dakika.
• 15 dakika: 96 istek, ortalama 7,5 dakika, en kötü durumda 15 dakika.
• 60 dakika: 24 istek, ortalama 30 dakika, en kötü durumda 60 dakika.

Maliyet, hız sınırı baskısı olarak değil, boşa giden istekler olarak ortaya çıkar. Free planda yayımlanmış çalışma alanı sınırı saniyede 10 istektir; bu günde 864.000 eder (API hız sınırları ve idempotency yazısına bakın). 1 dakikalık aralıkta tek bir sorgulayıcı bunun 1.440 / 864.000 = yüzde 0,17'sini kullanır. Sınırlara, yüzlerce bağlantıda bağlantı başına sorgu yaptığınızda veya çalışma alanını başka otomasyonlar paylaştığında takılırsınız; tek bir akışla takılmazsınız.

Önemli olan sayı israftır. Bir çalışma alanının günde 40 bağlantıyı değiştirdiğini ve bunu her dakika sorgulayarak izlediğinizi varsayın. 1.440 istekten en fazla 40'ı yeni bir şey döndürür; yani en az 1.400'ü (yüzde 97) boştur. Bir webhook alıcısı aynı 40 olay için 40 istek alır. En kötü durumda, her biri için üç deneme ile bu 120'dir.

Webhook'lar gecikmede kazanır; teslim işçisi bekleyen satırları sürekli aldığı için gecikme tipik olarak saniyelerdir. Polling'in bedavaya aldığı şeyde kaybederler: kaçırılan bir çalışma bir sonraki çalışmayla onarılır, çünkü veri hâlâ API'dedir. Kaçırılan bir webhook ise yalnızca onu onaracak bir şey kurduysanız onarılır.

Teslim Garantileri: Elido Neyi Vaat Ediyor?

Bu davranışlar teslim kodundan ve yardım belgelerinden gelir ve 1 Ekim 2026'da kontrol edilmiştir.

Yeniden denemeler. Bir teslim üç deneme alır: biri hemen, biri bir başarısızlıktan 5 dakika sonra, biri ondan 15 dakika sonra; baştan sona yaklaşık 20 dakika. 2xx olmayan herhangi bir durum, ağ hatası veya 10 saniyeden yavaş bir yanıt başarısızlıktır. Üçüncüden sonra teslim başarısız olarak işaretlenir; panodaki Yeniden dene veya POST .../deliveries/{delivery_id}/retry onu yeni bir üç deneme bütçesiyle yeniden kurar. Karşılaştırma için, Stripe canlı mod olaylarını üç güne kadar yeniden dener. Yirmi dakika kısadır. Bir alıcı kesintisinin karşılanacağını varsaymayın.

Idempotency. Teslim en az bir kez gerçekleşir. X-Webhook-Delivery başlığı bir uç noktaya yapılan bir teslimi tanımlar ve otomatik ya da elle yeniden denemeler boyunca değişmez; dolayısıyla tekilleştirme anahtarınızdır.

Sıralama. Sıralama sözü yoktur. Erken bir olayın yeniden denemesi, daha sonraki bir olaydan sonra gelebilir; bu yüzden herhangi bir şeyin üzerine yazmadan önce data.updated_at değerini sakladığınızla karşılaştırın.

İmzalar. Her imzalı teslim, v1= artı {timestamp}.{raw_body} değerinin onaltılık HMAC-SHA256'sını içeren X-Webhook-Signature (takma ad X-Elido-Signature) ve zaman damgasını X-Webhook-Timestamp içinde taşır. Zaman damgası her denemede tazedir, dolayısıyla meşru bir yeniden deneme asla bayat olmaz. Bir gizli anahtar döndürme sırasında, X-Elido-Signature-Previous yedi gün boyunca eski gizli anahtardan bir imza taşır. Webhook imzalarını doğrulama Python'u, Go'yu ve uyuşmazlığı ayıklamayı kapsar.

Aktarım ve duraklatma. Yeni olay uç noktaları https kullanmalıdır; düz http yalnızca localhost ve 127.0.0.1 için kabul edilir. is_active değerini false yapmak bir uç noktayı duraklatır. 22 Eylül düzeltmesinden beri bu, kuyruktaki teslimleri de durdurur.

Node'da Bir Webhook Alıcısı

Bu alıcı imzayı ham baytlar üzerinde doğrular, beş dakikalık bir pencere uygular, döndürme sırasında önceki gizli anahtar başlığını kabul eder ve teslim kimliği üzerinden tekilleştirir. Beş dakikalık tolerans sizin seçiminizdir, Elido'nun değil ve Stripe varsayılanıyla eşleşir. Yerel bir imzalayıcıya karşı çalıştırdım: geçerli bir istek 200 döndürdü, aynı teslim kimliğiyle bir tekrar "duplicate" döndürdü, yanlış bir gizli anahtar ve 400 saniye eski bir zaman damgası ikisi de 401 döndürdü.

import http from "node:http";
import { createHmac, timingSafeEqual } from "node:crypto";

const SECRET = process.env.WEBHOOK_SECRET; // the whsec_... value
const seen = new Set(); // use a unique index in a real database

export function verify(secret, headers, rawBody, toleranceSec = 300) {
  const ts = headers["x-webhook-timestamp"] ?? "";
  if (!/^\d+$/.test(ts)) return false;
  if (Math.abs(Date.now() / 1000 - Number(ts)) > toleranceSec) return false;
  const mac = createHmac("sha256", secret).update(`${ts}.`).update(rawBody);
  const expected = Buffer.from("v1=" + mac.digest("hex"));
  return ["x-elido-signature", "x-elido-signature-previous"].some((name) => {
    const got = Buffer.from(headers[name] ?? "");
    return got.length === expected.length && timingSafeEqual(got, expected);
  });
}

http
  .createServer((req, res) => {
    const chunks = [];
    req.on("data", (c) => chunks.push(c));
    req.on("end", () => {
      const raw = Buffer.concat(chunks);
      if (req.method !== "POST" || !verify(SECRET, req.headers, raw)) {
        return res.writeHead(401).end();
      }
      const id = req.headers["x-webhook-delivery"];
      if (seen.has(id)) return res.writeHead(200).end("duplicate");
      seen.add(id);
      const event = JSON.parse(raw.toString("utf8"));
      queueMicrotask(() => console.log("handled", event.type)); // do the work after replying
      res.writeHead(200).end("ok");
    });
  })
  .listen(8787);

timingSafeEqual öncesindeki uzunluk kontrolü önemlidir. Node, farklı boyutlardaki tamponlarda hata fırlatır. Önce yanıtlayın, işi sonra yapın. 10 saniyelik kesme noktası, yavaş ama başarılı bir işleyicinin yinelenene dönüştüğü yerdir.

Node'da Bir Tıklama Sorgulayıcısı

click.created yayına çıkana kadar tıklama yolu budur. clicks/recent en yeniyi başa getirir, 500'e kadar limit kabul eder (varsayılan 100) ve bir sayfa dolu geldiğinde next_cursor döndürür. Her çalışma en üstten okur ve zaten işlediği en yeni tıklamaya ulaştığında durur. İki satırı bir seferde sayfalayan bir sahte sunucuya karşı çalıştırdım: ilk çalışma 5 tıklamayı işledi, ikincisi yalnızca 2 yeni olanı işledi, üçüncüsü hiçbirini işlemedi.

const BASE = "https://api.elido.app";
const WS = process.env.ELIDO_WORKSPACE_ID;
const KEY = process.env.ELIDO_API_KEY;

// Newest click already handled; clicks/recent is newest first.
let lastSeen = null;
const keyOf = (c) => `${c.ts}|${c.link_id}`;

export async function pollOnce(handle) {
  let cursor = null;
  let newest = null;
  for (;;) {
    const url = new URL(`${BASE}/v1/workspaces/${WS}/analytics/clicks/recent`);
    url.searchParams.set("limit", "500");
    if (cursor) url.searchParams.set("cursor", cursor);
    const res = await fetch(url, {
      headers: { Authorization: `Bearer ${KEY}` },
      signal: AbortSignal.timeout(10_000),
    });
    if (!res.ok) throw new Error(`clicks/recent returned ${res.status}`);
    const { items, next_cursor } = await res.json();
    for (const click of items) {
      if (keyOf(click) === lastSeen) {
        if (newest) lastSeen = newest;
        return;
      }
      newest ??= keyOf(click);
      await handle(click);
    }
    if (!next_cursor) break;
    cursor = next_cursor;
  }
  if (newest) lastSeen = newest;
}

// setInterval(() => pollOnce(handleClick).catch(console.error), 60_000);

İki sınır, açıkça belirtilmiş. İmleç zaman damgasına ve bağlantı kimliğine göre sıralar; bu yüzden aynı saniyede aynı bağlantıdaki iki tıklama aynı anahtarı paylaşır. Nadir bir atlanan veya tekrarlanan tıklamayı göze alamıyorsanız handle işlevini tam satır üzerinden idempotent yapın. Ve lastSeen bellekte yaşar; bu yüzden yeniden başlatmalar arasında kalıcı hale getirin, yoksa yeniden başlatma yakın geçmişi yeniden oynatır.

İkisini de kurmaya hazır değil misiniz? Sorun değil. Panoyu açın ve önce pano analitiğini kullanın, ardından hangi sayıları bir takvimle istediğinizi öğrendiğinizde API'yi ekleyin.

Karar Tablosu

Örneklenmiş click.created akışı yayına çıktığında, canlı sayaç ve CRM satırları webhook sütununa geçer ve sorgu mutabakat geçişi olur. O zamana kadar Mixpanel bağlantı tıklama olayları gibi olay yönlendiricileri, tıklama verisi için itme tarzı seçenektir.

Hibrit Kalıp

Kaybetmeyi göze alamayacağınız her şey için ikisini de çalıştırın. Webhook hızlı yoldur. Zamanlanmış bir sorgu toplamları karşılaştırır ve boşlukları bulur: bir kesinti sırasında üç denemesini tüketen teslimler veya sırasız gelen olaylar.

summary ve timeseries raporları bir tarih aralığı için toplamları ve günlük kovaları tek çağrıda döndürür; bu da gecelik karşılaştırmayı ucuz yapar. Bot filtresinin, tıklamalar kaydedilmeden önce tarayıcıları ve izleyicileri kaldırdığını unutmayın; bu yüzden toplamlarınız ham sunucu günlükleriyle eşleşmez. Analitik rehberi nelerin hariç tutulduğunu açıklar. Güvenlik kontrol listesi gerisini kapsar. Kendi webhook'larınızı tasarlıyorsanız, Standard Webhooks belirtimi faydalı bir referanstır.

Örnek verili bir DEMO çalışma alanının API belge ekranı; bir müşteri hesabı değildir.

Blogda İlgili Yazılar

• Bağlantı olayları için webhook'lar: yükler, imzalar, yeniden denemeler
• Webhook imzalarını doğrulama: Node, Python, Go'da HMAC-SHA256
• URL kısaltıcı API hız sınırları, yeniden denemeler ve idempotency
• Bağlantı analitiği API'si: bir API anahtarıyla tıklama istatistikleri çekin
• Ateşle ve unut tıklama alımı
• URL kısaltıcı API + SDK hızlı başlangıç