Trendyol’da stok ve fiyat güncelleme: toplu istek ve sessiz hatalar

Trendyol’da stok ve fiyatı API ile güncellemenin tam akışı: uç nokta, 1.000 kalemlik sınır, toplu işlem sonucunun sorgulanması ve sessizce başarısız olan güncellemelerin yakalanması.

Stok ve fiyat güncellemesi, entegrasyonun en sık çalışan parçasıdır — ve en sessiz şekilde bozulanıdır. İstek 200 döner, kod “güncellendi” diye loglar, ama ürünün fiyatı değişmemiştir. Sebebi şu: Trendyol’da bu uç nokta isteği kabul eder, işlemi sonra yapar. Gerçek sonucu ayrı bir çağrıyla sormanız gerekir.

Uç nokta ve sınırlar

Güncelleme POST ile yapılır:

PROD   https://apigw.trendyol.com/integration/inventory/sellers/{sellerId}/products/price-and-inventory
STAGE  https://stageapigw.trendyol.com/integration/inventory/sellers/{sellerId}/products/price-and-inventory

Tek istekte en fazla 1.000 kalem gönderilebilir. Gövde alanları:

Alan	Tip	Zorunlu	Not
barcode	metin	Evet	Ürünü tanımlar
quantity	tam sayı	Koşullu	Satılabilir stok, en çok 20.000 adet
salePrice	ondalık	Koşullu	Satış fiyatı (TSF)
listPrice	ondalık	Koşullu	İndirimliyken gösterilen üstü çizili fiyat (PSF)

Fiyat ve stok alanlarının en az biri bulunmalıdır. Yalnızca stok güncelleyecekseniz fiyat alanlarını hiç göndermeyin — eski fiyatı aynı değerle tekrar göndermek, az sonra anlatacağımız tekrar kontrolüne takılır.

Aynı isteği 15 dakika içinde tekrarlamayın

Trendyol, birebir aynı isteğin 15 dakika içinde tekrar gönderilmesini kabul etmiyor ve hata üretiyor. Bu, kulağa küçük bir ayrıntı gibi geliyor ama mimariyi doğrudan etkiliyor.

Pratikte şu anlama gelir: her çalışmada tüm katalogu toptan göndermeyin. “Her 10 dakikada bir 5.000 ürünü yolla” tarzı bir kurgu, ürünlerin çoğunda hiçbir değer değişmediği için hem bu kontrole takılır hem de kotanızı boşa harcar. Doğrusu, bir önceki gönderimdeki değerleri yerelde tutup yalnızca gerçekten değişenleri göndermektir.

İstek kabul edildi — ama güncellendi mi?

Başarılı bir istek size bir batchRequestId döner:

{
  "batchRequestId": "fa75dfd5-6ce6-4730-a09e-97563500000-1529854840"
}

Bu kimlik “işlem tamamlandı” demek değil, “işlem kuyruğa alındı” demektir. Sonucu öğrenmek için:

GET https://apigw.trendyol.com/integration/product/sellers/{sellerId}/products/batch-requests/{batchRequestId}

Yanıtta şu alanlar bulunur:

• status — toplu işlemin genel durumu (ör. COMPLETED)
• itemCount — gönderilen kalem sayısı
• failedItemCount — başarısız kalem sayısı
• items — her kalem için requestItem, status ve hata hâlinde failureReasons

Buradaki asıl tuzak

Toplu işlemin genel durumu COMPLETED olabilir ve içindeki kalemlerin bir kısmı yine de başarısız olmuş olabilir. “Tamamlandı” ifadesi “hepsi başarılı” demek değil, “kuyruk işlendi” demektir.

Trendyol dokümanı bu konuda açık bir uyarı veriyor: stok ve fiyat güncellemelerinden sonra kalem bazındaki status alanlarını kontrol etmeniz gerekir. Yalnızca üst seviyedeki duruma bakan bir entegrasyon, 1.000 üründen 40’ının güncellenmediğini hiç fark etmez.

Doğru kontrol sırası:

• Önce failedItemCount değerine bakın — sıfır değilse bir sorun var.
• Sonra items dizisini dolaşıp başarısız kalemlerin failureReasons alanını loglayın.
• Başarısız barkodları bir sonraki çalışmada tekrar deneyin; hepsini baştan göndermeyin.

Ne zaman sorgulamalı

Güncellemeden hemen sonra sorgularsanız işlem henüz bitmemiş olabilir. Doküman beklemeyi öneriyor. Toplu işlem sonucu 4 saate kadar sorgulanabiliyor, yani acele etmenize gerek yok.

Makul bir kurgu: isteği gönder, batchRequestId değerini bir kuyruğa yaz, ayrı bir iş olarak birkaç dakika sonra sonucu sorgula. Döngü içinde bekleyip aynı kimliği saniyede bir sorgulamak, hem kotanızı yer hem de sonucu daha hızlı getirmez.

Hız planlaması

Stok ve fiyat çağrıları Inventory & Price Write grubuna girer; bu grubun kotası satıcı kademesine göre dakikada 350 ile 2.000 istek arasındadır. Ayrıca fiyat güncellemelerinde barkod başına dakikada 30 istek sınırı vardır.

1.000 kalemlik paketler kullanırsanız bu kota pratikte sorun çıkarmaz: 50.000 ürünlük bir katalog, kalem sınırına göre 50 istek demektir. Sorun, kalem sınırını kullanmayıp ürün başına bir istek atan kurgulardadır — aynı iş 50.000 istek olur ve en üst kademede bile kotayı aşar.

Limitlerin 14 Eylül 2026’da değiştiğini ve Authorization sayfasındaki eski “10 saniyede 50 istek” bilgisiyle çeliştiğini hata kodları yazısında ayrıntılı anlattık.

Özetle doğru akış

• Değişen kalemleri tespit et — değişmeyeni gönderme.
• En çok 1.000 kalemlik paketler hâlinde POST et.
• Dönen batchRequestId değerini sakla.
• Birkaç dakika sonra sonucu sorgula.
• failedItemCount ve kalem bazındaki status alanlarını kontrol et.
• Başarısız barkodları logla ve yalnızca onları tekrar dene.

Fiyatı değiştirmeden önce o fiyatın gerçekten kâr bırakıp bırakmadığını görmek isterseniz komisyon ve kâr hesabı yazısına ya da doğrudan kâr hesaplayıcıya bakabilirsiniz.

Güncelleme kalemleri “barkod bulunamadı” diye düşüyorsa sorun senkronizasyonda değil eşleştirmededir — barkod ve stok kodu eşleştirme yazısı bu tarafı ele alıyor.

N11’de de aynı desen geçerli: orada batchRequestId yerine taskId dönüyor ve kalem sınırı yine 1.000. Ondalık biçimi gibi N11’e özgü kurallar ayrı yazıda.

Kaynak

Uç nokta adresleri, 1.000 kalem sınırı, alan tanımları ve 15 dakikalık tekrar kuralı Stok ve Fiyat Güncelleme; toplu işlem sorgulama akışı ve 4 saatlik pencere Toplu İşlem Kontrolü; servis grubu kotaları Servis Limitleri sayfasından alınmıştır.

Son kontrol: 6 Ekim 2026.