Pazaryeri API Limitleri: Rate Limit, Kuyruk ve Yeniden Deneme Yönetimi

Kısa cevap

Pazaryeri API'leri sınırsız hızda çağrı kabul etmez. Sağlam entegrasyon; istekleri kuyruğa alır, kanal bazlı limit uygular, 429 ve timeout gibi geçici hatalarda kontrollü backoff yapar ve aynı işlemi körlemesine çoğaltmaz.

Pazaryeri API Limitleri neden önemli?

Bin ürünün stok güncellemesini aynı anda başlatmak, pazaryerinin istek limitini aşabilir. Doğru çözüm isteği kaybetmek değil, kontrollü partilere bölmek ve sonuç kimliğiyle takibi sürdürmektir.

Teknik dayanıklılık, normal günlerde değil API yavaşladığında, rate limit oluştuğunda veya bir görev yarıda kaldığında belli olur. Entegrasyonun tekrar deneme ve gözlemlenebilirlik tasarımı bu nedenle ürün özelliği kadar önemlidir.

2026 itibarıyla pazaryerleri katalog ve sipariş servislerini düzenli olarak güncelliyor. Bu nedenle entegrasyon kararını yalnız bir kez yapılan kurulum gibi değil, izlenen ve güncellenen bir operasyon sistemi gibi ele almak daha sağlıklıdır.

Doğru çalışma mantığı nasıl kurulmalı?

İstek üretimi ile API çağrısını kuyruk üzerinden ayırmak, kanal bazlı hız limiti ve yeniden deneme uygulamak daha güvenli bir mimaridir. Log ve metrikler, hangi işin nerede kaldığını kullanıcıya ve geliştiriciye gösterebilmelidir.

Ürün veya sipariş kaydında yerel kimlik ile pazaryerinin uzak kimliğini birlikte saklamak, tekrar deneme ve durum sorgularında kritik önem taşır. İşlem geçmişi kaybolmadığında aynı kaydın neden beklediği veya reddedildiği daha hızlı bulunur.

Adım adım uygulama planı

Her kanalın resmi rate limit ve toplu işlem kurallarını ayrı konfigürasyonda tutun. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.
Ürün, stok-fiyat ve sipariş görevlerini farklı kuyruklarda sınıflandırın. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.
429 yanıtında Retry-After gibi resmi geri dönüş sinyallerini dikkate alın. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.
Timeout'u kesin başarısızlık saymadan önce işlemin uzak tarafta gerçekleşip gerçekleşmediğini sorgulayın. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.
Exponential backoff ve maksimum deneme sayısı tanımlayın. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.
Idempotency veya işlem anahtarıyla aynı güncellemeyi tekrar tekrar üretmeyin. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.
Batch/tracking ID dönen API'lerde sonucu ayrı görevle poll edin. Bu adımın sonucunu ekran görüntüsü, işlem kimliği veya kısa kontrol notuyla doğrulayın; sonraki aşamaya doğrulama tamamlandıktan sonra geçin.

Kontrol ve ölçüm noktaları

429/5xx oranı, timeout, kuyruk yaşı, ortalama görev süresi, deneme sayısı ve kalıcı hata oranı takip edilirse sorun büyümeden fark edilir.

İşlem hangi mağaza ve kanal için çalıştı?
Yerel SKU/barkod ile uzak ürün kimliği eşleşiyor mu?
Son durum ilk API yanıtından mı, nihai sonuç servisinden mi geliyor?
Başarısız işlem için kullanıcıya anlaşılır hata nedeni gösteriliyor mu?
Tekrar deneme mükerrer ürün veya sipariş oluşturmadan çalışıyor mu?
Canlı kanalda örnek ürün/sipariş ile sonuç doğrulandı mı?

Sık yapılan hatalar ve düzeltme yaklaşımı

429 hatasında gecikmeden tekrar tekrar aynı isteği göndermek.

Bu durum görüldüğünde önce etkilenen kayıtları ayırın, otomatik kuyruğu gerekirse durdurun ve kök nedeni netleştirin. Veri düzeltildikten veya geçici API sorunu sona erdikten sonra yalnız ilgili kayıtları kontrollü biçimde yeniden deneyin.

Timeout sonrası aynı ürünü kontrol etmeden yeniden oluşturmak.

Bütün kanallara tek hız limiti uygulamak.

Bekleyen görevi sonsuza kadar pending durumda bırakmak.

2026 için güncellik notları

Pazaryeri API dokümanları, endpoint sürümleri, zorunlu alanlar ve işlem limitleri zaman içinde değişebilir. Bu yazıdaki operasyon mantığını uygularken ilgili kanalın güncel geliştirici veya satıcı destek dokümanını esas alın. Özellikle ürün oluşturma, toplu güncelleme ve sipariş durum servislerinde sürüm notlarını takip etmek gerekir.

Canlı sistemlerde değişiklik yapmadan önce küçük ürün grubu, düşük riskli stok-fiyat değeri ve test edilebilir sipariş senaryosu kullanmak; geniş kataloğa geçmeden önce hata davranışını görmeyi sağlar.

3E Entegrasyon tarafında hangi akışlar değerlendirilebilir?

3E Yazılım’ın pazaryeri entegrasyonu sayfasında XML, Excel, manuel ürün ekleme, desteklenen bağlantılardan ürün alma, tekil/toplu ürün gönderimi, kategori-özellik eşleştirme, stok-fiyat senkronizasyonu ve sipariş takibi gibi operasyon başlıkları yer alıyor. İhtiyacınız bu akışlardan biriyse önce gerçek ürün verinizle demo senaryosu oluşturmak en sağlıklı karşılaştırma yöntemidir.

Pazaryeri entegrasyonu özelliklerini inceleyin veya demo talebi oluşturun.

Sık sorulan sorular

429 hatası ne anlama gelir?

Genellikle kısa sürede izin verilenden fazla istek gönderildiğini gösterir; resmi limit ve Retry-After bilgisi izlenmelidir.

Timeout işlemin başarısız olduğu anlamına gelir mi?

Her zaman değil. Uzak sistem isteği işlemiş olabilir; durum sorgusu veya idempotent yeniden deneme gerekir.

Kuyruk neden gereklidir?

Yoğun işi kontrollü parçalara bölmek, API limitlerine uymak ve başarısız görevleri izlemek için kullanılır.