eBay Webhook vs Polling 2026: Sipariş Otomasyonunda Doğru Mimari

eBay webhook vs polling kararı, “gerçek zamanlı olan daha iyidir” cümlesiyle verilemez. Webhook bir olay olduğunda sistemi hızlıca uyandırır; polling belirli aralıkta eBay'e “ne değişti?” diye sorar. Birincisi düşük gecikme, ikincisi tekrar okunabilirlik sağlar. Dropshipping siparişinde kaçırılan tek order supplier'a geç iletilebilir; iki kez işlenen tek order ise iki ürün satın alıp marjı silebilir.

Bu nedenle mimariyi hız değil teslimat garantisi, tekrar davranışı, API limitleri ve kurtarma planıyla değerlendirmek gerekir. eBay otomasyon hata yönetimi kill switch ve retry prensiplerini anlatır; bu rehber otomasyonun değişikliği ilk kez nasıl öğrendiğini ve kaçan olayı nasıl bulduğunu tasarlar.

Webhook ve polling tam olarak ne yapar?

Webhook veya push notification modelinde eBay, abone olduğunuz desteklenen bir topic oluştuğunda HTTPS endpoint'inize payload gönderir. Uygulama isteği doğrular, olayı kalıcı kuyruğa yazar ve hızlıca başarılı yanıt verir. Ağır supplier işlemi webhook request'i açıkken yapılmamalıdır.

Polling modelinde uygulama zamanlayıcıyla eBay API'sine gider. Örneğin Fulfillment API `getOrders` çağrısı creation date, last modification date veya fulfillment status filtresiyle sipariş arayabilir. Uygulama son başarılı cursor/zaman penceresini saklar, yeni veya değişmiş order'ları işler.

eBay'in resmi Notification API genel bakışı; topic keşfi, destination endpoint, subscription, filtre ve imza doğrulama akışını açıklar. Resmî unfulfilled order keşfi ise order listesinin filtrelerle sorgulanabildiğini gösterir.

Gerçek karşılaştırma

Webhook “exactly once” teslimat olarak varsayılmamalıdır. eBay'in güncel notification topics sayfasındaki payload örneklerinde notification ID, event/publish zamanı ve publish attempt count gibi alanlar bulunur. Bu alanlar tekrar teslimatın normal bir tasarım girdisi olduğunu gösterir.

Önce olay kataloğu çıkarın

Her değişiklik aynı aciliyette değildir. Yeni ve ödemesi tamamlanmış sipariş supplier akışını hızlı başlatabilir. Tracking veya shipment değişimi alıcı iletişimini etkiler. Feedback olayı saatlik batch'e kalabilir. Fiyat raporu günlük olabilir.

Olay kataloğunda şu sütunlar bulunmalıdır:

• Business event: order created, paid, cancelled, shipped, refunded gibi
• eBay source: desteklenen notification topic veya API resource
• İstenen maksimum gecikme
• İş anahtarı ve idempotency kuralı
• Kaçırılırsa finansal/hesap sağlığı etkisi
• Reconciliation sorgusu ve saklama süresi

Önemli ayrım şudur: eBay'de “bir şey oldu” notification'ı, sizin business event'inizle bire bir aynı olmayabilir. Payload içindeki order ID alınıp Fulfillment API'den güncel order okunması gerekebilir. Notification tetikleyici, API ise otoriter state olabilir.

Webhook endpoint'i hızlı ve şüpheci olmalı

Endpoint'in görevi supplier'a sipariş vermek değil olayı güvenli kabul etmektir. İstek kaynağı ve imzası resmî yönteme göre doğrulanır. Schema version ve topic kontrol edilir. Ham payload değişmez biçimde saklanır. Notification ID daha önce görüldüyse başarılı yanıt verilip tekrar business action başlatılmaz. Yeni olay kuyruğa yazılır ve endpoint kısa sürede yanıt döner.

eBay Notification API destination kurulurken endpoint için challenge-response doğrulaması kullanır; doküman verification token ve endpoint ile challenge code'un doğrulanmasını açıklar. Canlıya çıkmadan test subscription çalıştırılmalı, başarısız doğrulama alarm üretmelidir.

Güvenlik açısından payload içindeki her alan güvenilir komut gibi alınmamalıdır. Order ID formatı, seller/marketplace bağlamı ve topic kontrol edilmeden işlem yapılmaz. Endpoint log'una token, tam alıcı adresi veya gereksiz kişisel veri yazılmamalıdır.

Idempotency: iki notification, bir supplier siparişi

En pahalı hata duplicate fulfillment'tır. Güvenli iş anahtarı yalnız notification ID olamaz; aynı business değişikliği farklı notification kimliğiyle tekrar üretilebilir. Supplier order yaratma için `ebay_order_id + line_item_id + action_type`, tracking upload için `order_id + carrier + tracking_number` gibi iş anahtarları kullanılabilir.

İşlem tablosu en az `received`, `validated`, `processing`, `completed`, `failed_retryable` ve `manual_review` durumlarını taşımalıdır. Supplier çağrısından önce idempotency kaydı transaction veya atomik unique constraint ile sahiplenilir. Çağrı zaman aşımına uğrarsa “başarısız” varsayılıp körlemesine tekrar edilmez; önce supplier tarafında order'ın oluşup oluşmadığı aranır.

Bu disiplin polling için de aynıdır. Son modified pencerelerini örtüştürmek gerekir; örneğin her tarama son başarılı zamandan birkaç dakika geriye bakabilir. Aynı order tekrar döneceği için işlem idempotent olmalıdır.

Polling penceresi nasıl tasarlanır?

`now - last_run` aralığı basit görünür ama saat kayması, başarısız run ve geç güncellenen kayıtları kaçırabilir. Daha güvenli yaklaşım, son başarı watermark'ını saklamak ve sorguyu küçük overlap ile çalıştırmaktır. Sonuçlar sayfalanır; bütün sayfalar ve işler kalıcı kuyruğa yazılmadan watermark ilerletilmez.

Örnek akış:

1. Son başarılı watermark okunur.
2. Başlangıç birkaç dakika geriye alınır; bitiş run başında sabitlenir.
3. `lastmodifieddate` veya uygun filtreyle tüm sayfalar çekilir.
4. Order'lar idempotency anahtarıyla kuyruğa yazılır.
5. Sayfa veya doğrulama hatası varsa watermark korunur.
6. Tam başarıdan sonra bitiş zamanı yeni watermark olur.

eBay API'lerinde çağrı limitleri API'ye göre değişir. Resmî API call limits sayfası varsayılan limitleri ve hacim büyüdüğünde Application Growth Check sürecini listeler. Limit büyük görünse bile her mağaza için her dakika tam tarihçe çekmek iyi tasarım değildir. Filtre, pagination, cache, exponential backoff ve jitter kullanılmalıdır.

Reconciliation neden zorunludur?

Webhook endpoint'iniz bakımdayken olay gelebilir, subscription devre dışı kalabilir veya iş kuyruğu bozulabilir. Polling job da rate limit, token expiry veya pagination hatası yaşayabilir. Kaynak eBay olduğu için yerel sistem belirli aralıkta eBay state'iyle uzlaştırılmalıdır.

Sipariş reconciliation örneğinde son 24-72 saatin paid/unfulfilled order listesi çekilir ve yerel kayıtla karşılaştırılır. eBay'de olup yerelde olmayan order yüksek öncelikli alarmdır. Yerelde “ordered from supplier” görünen ama eBay'de cancellation/refund olan kayıt para ve fulfillment incelemesine gider. Yerelde tamamlanmış fakat tracking'siz eBay order varsa shipment workflow kontrol edilir.

Reconciliation yalnız hata bulmaz; otomasyonun güvenilirliğini ölçer. “Webhook ile bulunan order oranı”, “reconciliation ile sonradan bulunan order”, “duplicate delivery”, “ortalama event-to-ingest süresi” ve “manuel kurtarma süresi” dashboard'da izlenmelidir.

Hangi hacimde hangi model?

Düşük hacimde Seller Hub ve düzenli operasyon kontrolü, özel API entegrasyonundan daha güvenli olabilir. Günde birkaç sipariş için public endpoint, secret rotation, queue ve 24/7 alarm sistemi kurmak bakım maliyetini hak etmeyebilir.

Orta hacimde 5-15 dakikalık polling, overlap ve günlük reconcile anlaşılır bir başlangıçtır. Supplier sipariş süresi çok hassassa notification ile tetikleme eklenebilir. Yüksek hacimde webhook ana yol, sık olmayan polling/reconciliation emniyet ağı ve ayrı dead-letter queue daha uygun olur.

TurkoLister nerede konumlanır?

TurkoLister kullanmak için kendi webhook altyapınızı kurmanız gerekmez. Platformun listing, ürün, kâr ve stok-fiyat workflow'u birçok satıcının asıl ihtiyacını özel entegrasyon bakımından daha düşük maliyetle karşılayabilir. Özel mimari ancak gecikme, hacim ve iş kuralları bunu gerçekten gerektiriyorsa kurulmalıdır.

TurkoLister free trial ile önce mevcut sipariş sürecinizi ölçün: siparişten görülmeye, supplier'a verilmeye ve tracking yüklemeye kadar geçen süre nedir? Darboğaz insan kontrolüyse webhook tek başına çözmez. Veri görünürlüğü ve standart workflow kurulduktan sonra teknik otomasyonun ROI'si daha doğru hesaplanır.

Sonuç

eBay webhook vs polling seçiminde webhook hız, polling yeniden keşif sağlar; ikisi de tek başına kayıpsız ve tekil işlem garantisi vermez. Kritik dropshipping siparişlerinde güçlü desen, notification ile hızlı tetikleme, idempotent queue worker, API'den otoriter state okuma ve düzenli polling reconciliation'dır. Hacim düşükse daha basit araçla başlayın; mimariyi ancak ölçülen gecikme ve hata maliyeti gerektirdiğinde büyütün.