eBay API Rate Limit 2026: Queue, Batch ve Retry ile Güvenli Otomasyon

eBay API rate limit, entegrasyon büyüdüğünde karşılaşılan basit bir “daha fazla kota iste” problemi değildir. Aynı queue içinde stok kapatma, sipariş çekme, trafik raporu alma ve düşük öncelikli açıklama güncellemesi yarışıyorsa yüksek kota bile yanlış işe harcanabilir. Güvenli otomasyon önce iş önceliğini tanımlar, sonra her API için ayrı bütçe ve retry davranışı uygular.

Dropshipping operasyonunda bir stok sıfırlama çağrısının dakikalarca beklemesi overselling ve seller cancellation riski yaratır. Buna karşılık dünün trafik raporu birkaç dakika geç alınabilir. İki işi FIFO kuyruğuna koymak teknik olarak kolay, işletme açısından yanlıştır. eBay otomasyon hata yönetimi genel kill switch ve audit log çerçevesini verir; bu rehber kota ve kuyruk tasarımına odaklanır.

eBay API kotası tek bir sayı değildir

eBay'in API Call Limits sayfasına göre limitler API ailesi ve kaynağa göre değişir. 4 Temmuz 2026 itibarıyla erişilen varsayılan tabloda örneğin Inventory API için günlük 2 milyon, Fulfillment API order kaynakları için 100 bin, Taxonomy API için 5 bin çağrı gösterilir. Analytics API içinde traffic report ve seller standards profile kaynakları ise günlük 100 çağrı gibi çok daha dar bir bütçeye sahiptir. Bu değerler zamanla değişebileceği için kod içine “eBay kotası 5.000'dir” şeklinde global sabit yazılmamalıdır.

Günlük limit tek sınır olmayabilir. Bazı media POST işlemlerinde kısa zaman pencereli kullanıcı seviyesi limitler bulunur; Sell Feed görevlerinde dosya türüne ve seller token'a bağlı ayrı sınırlar vardır. OAuth token üretimi de kendi rate-limit ve best practice kurallarına tabidir. Uygulamanın Developer hesabındaki kullanım raporu, hata yanıtı ve ilgili API dokümanı gerçek kaynak kabul edilmelidir.

Polling, notification, batch ve feed karşılaştırması

Pratik mimari hibrittir. Sipariş ve kritik event notification ile gelir; kaçırılan olayları bulmak için düşük frekanslı reconciliation polling çalışır. Taxonomy ve policy metadata uygun süreyle cache edilir. Toplu listing bakımı batch veya feed'e gider. Anlık stok-out ise öncelikli küçük yazma çağrısı olarak kalır. Webhook vs polling rehberi event katmanındaki trade-off'ları detaylandırır.

Öncelikli queue tasarımı

Tek queue yerine en az dört iş sınıfı tanımlayın:

1. P0 hesap koruma: Stok sıfırlama, yanlış fiyatı durdurma, riskli ilanı kapatma
2. P1 sipariş: Yeni order ingest, acknowledgement, tracking ve cancellation istisnaları
3. P2 katalog bakımı: Fiyat güncelleme, quantity yenileme, item specifics düzeltme
4. P3 analitik: Traffic report, performans export ve yeniden indeksleme

P0 her zaman bütün kotayı tüketmemelidir; aksi halde hatalı supplier feed milyonlarca stok kapatma işi üretip sistemi kilitler. Her sınıfta tenant/seller başına adil paylaşım, maksimum concurrency ve circuit breaker olmalıdır. Bir satıcının bozuk token'ı diğer mağazaların kuyruğunu durdurmamalıdır.

Queue kaydı yalnız endpoint ve payload içermez. Seller ID, iş türü, idempotency anahtarı, ilk oluşturma zamanı, son deneme, deneme sayısı, bağımlı veri sürümü ve deadline saklanır. Stok kapatma işi 20 dakika sonra hâlâ yapılmadıysa “başarısız değil, kuyrukta” demek operasyon açısından kabul edilemez; deadline alarmı gerekir.

Kota bütçesini matematikle yönetin

Günlük limitin tamamını planlı işlere ayırmayın. Örneğin bir kaynak için gözlenen limit L ise bunun bir kısmı gerçek zamanlı işler, bir kısmı mutabakat, bir kısmı manuel düzeltme ve kalan kısmı hata/retry rezervi olarak ayrılır. Oranlar mağaza riskine göre belirlenir; amaç %100 kullanım değil, P0 olay geldiğinde kullanılabilir kapasite bırakmaktır.

Her dakika şu değerler ölçülmelidir:

• API ve resource bazında kullanılan ve kalan tahmini kota
• Queue depth, en eski iş yaşı ve deadline ihlali
• Başarı, retry, throttle ve kalıcı hata oranı
• Seller/token bazında tüketim payı
• Bir iş sonucu güncellenen kayıt sayısı; yani request verimliliği
• Cache hit oranı ve reconciliation tarafından bulunan kaçak event sayısı

Yalnız toplam çağrı sayısı yetmez. 10 bin request ile 10 bin SKU güncellemek ile aynı sayıda request kullanıp değişmeyen veriyi tekrar okumak aynı kalite değildir.

Retry: her hata yeniden denenmez

Network timeout, geçici 5xx veya açıkça throttle bildiren yanıtlar kontrollü retry adayıdır. Validation hatası, policy ihlali, eksik scope veya geçersiz ürün verisi ise aynı payload ile tekrarlandığında düzelmez. Bunlar dead-letter veya insan inceleme kuyruğuna gitmelidir.

Geçici hata için akış şöyledir:

1. HTTP durumu ve eBay error ID sınıflandırılır.
2. Varsa Retry-After veya endpoint rehberi uygulanır.
3. Exponential backoff üzerine jitter eklenir; bütün worker'lar aynı anda geri dönmez.
4. Maksimum deneme ve toplam yaş sınırı kullanılır.
5. Yazma işi idempotency veya önce-sonra doğrulamasıyla tekrar edilir.
6. Başarıdan sonra sonuç okunur; yalnız 2xx görmek iş durumunun doğru olduğunu garanti etmeyebilir.

Örneğin price update timeout verdiğinde server isteği işlemiş olabilir. Aynı işi kontrolsüz tekrar göndermek çoğu zaman aynı değeri yazsa da log, sıra ve sonraki kural açısından çift etki yaratabilir. İşin istenen state'i “fiyatı £24.99 yap” olarak tutulmalı, “fiyata £2 ekle” gibi tekrarlandığında sonucu değiştiren komutlardan kaçınılmalıdır.

Batch büyüklüğü nasıl seçilir?

En büyük desteklenen batch her zaman en iyi batch değildir. Büyük batch request sayısını azaltır fakat tek kaydın validation hatasını ayıklamayı, deadline'a uymayı ve kısmi başarıyı yönetmeyi zorlaştırabilir. Küçük batch hızlı geri bildirim verir ama overhead ve kota tüketimini yükseltir.

Batch büyüklüğü payload boyutu, endpoint sınırı, ortalama latency, hata yoğunluğu ve iş deadline'ına göre dinamik seçilebilir. Temiz ve düşük riskli katalog bakımında daha büyük; yeni supplier'dan gelen kirli veride daha küçük batch kullanılır. Her item sonucu ayrı kaydedilir. “Batch tamamlandı” ifadesi, içindeki bütün SKU'ların başarılı olduğu anlamına gelmemelidir.

Feed kullanan akışlarda create task, upload, process ve result download aşamaları ayrı state'lerdir. Task oluşturulduktan sonra sık status polling yaparak kazanılan kota avantajı geri verilmemelidir. Poll aralığı task yaşına göre açılabilir; tamamlanma notification'ı varsa değerlendirilir.

Token ve çoklu mağaza izolasyonu

Rate limit ile authentication hatası aynı kuyruğa atılmamalıdır. Access token süresi dolduysa refresh kontrollü ve tekil yapılmalı; onlarca worker aynı kullanıcı için aynı anda token yenilemeye çalışmamalıdır. Refresh başarısızsa o seller'ın işleri park edilir, diğer seller'lar devam eder.

Çoklu hesap sisteminde seller başına concurrency ve bütçe görünürlüğü gerekir. Bir mağazanın iki milyon SKU güncellemesi küçük mağazanın acil tracking çağrısını bekletmemelidir. Global app limiti, API limiti ve user/seller düzeyi limiti ayrı sayaçlarla izlenir. Kesin sınır bilinmiyorsa konservatif limiter ve gerçek hata telemetrisiyle kalibre edilir.

Growth Check istemeden önce verimlilik kanıtı

eBay, daha yüksek limitler için Application Growth Check süreci sunar. Ancak ilk çözüm limit artırımı olmamalıdır. Önce değişmeyen veriyi sorgulayan polling, tekrarlanan taxonomy çağrıları, küçük batch'ler, bozuk retry loop ve kullanılmayan raporlar temizlenir. İstenen kapasite iş hacmiyle gerekçelendirilir ve kullanıcı verisi/policy uyumu gösterilir.

TurkoLister free trial ile hazır listing ve monitoring akışını deneyebilirsiniz. Kendi entegrasyonunu geliştiren ekip için dürüst karar şudur: özel API mimarisi esneklik sağlar fakat queue, token, retry, audit ve on-call sorumluluğunu da getirir. Sadece endpoint çağırabilmek üretim kalitesi değildir.

Üretime çıkış kontrol listesi

Sandbox testi gerçek trafik desenini tam göstermez. Üretimde önce tek seller ve sınırlı SKU ile canary açın. Rate limiter konfigürasyonu koddan bağımsız değiştirilebilmeli; kill switch yalnız tüm sistemi değil endpoint ve seller düzeyini de durdurabilmelidir. Alarm mesajı “API hata verdi” yerine etkilenen mağaza, iş türü, en eski iş yaşı ve tahmini risk içermelidir.

Son kabul ölçütü çağrıların başarılı olması değil, kritik işlerin deadline içinde tamamlanmasıdır. Stok-out hızlı kapanıyor, siparişler kaybolmuyor, analitik işler kritik trafiği boğmuyor ve her retry audit edilebiliyorsa rate-limit mimarisi görevini yapıyor demektir.