14 Eylül 2026’da Trendyol’un servis limitleri, tek tek endpoint’lere verilen kotalardan servis grubu bazlı ortak kotalara geçiyor. Bu, dokümantasyonda tek satırlık bir değişiklik gibi görünüyor. Pratikte ise bugüne kadar birbirinden bağımsız çalışan ürün, stok ve fiyat işlerinizin aynı havuzdan su içmeye başlaması demek — ve bunu Q4’ün stok güncelleme trafiğinin zirveye çıkmasından tam iki ay önce yapıyorlar.
Aşağıda ne değiştiğini, hangi entegrasyon tasarımının 14 Eylül sabahı 429 yemeye başlayacağını ve bu hafta içinde kapatılması gereken altı kontrolü sıraladım.
1. Eski model ile yeni model arasındaki fark
Mevcut yapıda her endpoint’in kendi tavanı vardı. Ürün oluşturma 1000 req/dk, ürün silme 100 req/dk, filtreleme 2000 req/dk gibi. Bir işin limiti dolduğunda diğerleri etkilenmiyordu.
Yeni yapıda limitler üç servis grubuna toplanıyor ve grup içindeki tüm operasyonlar aynı kotayı paylaşıyor:
| Servis grubu | Yeni limit aralığı | Kapsadığı operasyonlar |
|---|---|---|
| Ürün Entegrasyonu — Okuma | 1000 – 2000 req/dk | Ürün listeleme, filtreleme, detay sorgulama |
| Ürün Entegrasyonu — Yazma | 200 – 600 req/dk | Oluşturma + güncelleme + silme (toplamda) |
| Stok & Fiyat — Yazma | 350 – 2000 req/dk | Stok ve fiyat güncellemeleri |
2. Asıl kritik değişiklik: ortak kota havuzu
Tablodaki rakamlara bakıp “limitler yükselmiş” demek kolay. Yükselmiş gibi görünen şey aslında birleştirme.
Eskiden ürün güncelleme için 1000 req/dk’lık ayrı bir tavanınız vardı. Şimdi oluşturma, güncelleme ve silme toplam 200–600 req/dk içinde. Yani gece çalışan toplu katalog güncelleme işiniz ile gün içinde tetiklenen tekil düzeltmeleriniz artık aynı kovadan harcıyor.
Bu tasarımın kırdığı en yaygın kalıp şu: birbirinden habersiz çalışan servisler. ERP’nizden gelen ürün senkronu, panel üzerinden yapılan manuel düzeltmeler ve bir üçüncü taraf fiyat robotu aynı API anahtarını kullanıyorsa, üçünün toplamı artık tek limite tabi. Her biri tek başına limitin altındayken toplamda üstüne çıkabilir — ve 429 hatasını hangisinin tetiklediğini loglarınızdan ayırt edemezsiniz.
3. Barkod bazlı 30 req/dk fiyat limiti
Yeni kurallarda ayrıca şu madde var: fiyat güncelleme isteği için barkod bazlı 30 req/dk limiti. Bu, grup limitinden bağımsız ikinci bir tavan.
Tek bir ürünün fiyatını dakikada 30 defadan fazla güncelleyemezsiniz. Normal bir operasyonda bu limite yaklaşmak imkânsız görünür. Ancak iki senaryoda çarpar:
- Repricer kullanıyorsanız. Rekabetin yoğun olduğu bir üründe agresif ayarlanmış bir fiyat robotu, rakip her hareket ettiğinde tetiklenir. Kampanya günlerinde saniyede bir tetiklenen bir kural, dakikada 30 sınırını rahatlıkla aşar.
- Retry mantığınız kötüyse. Başarısız olan bir fiyat isteğini bekleme koymadan tekrar deneyen bir kod, aynı barkod için saniyeler içinde onlarca istek üretir. Limit dolduğu için hata alır, hata aldığı için tekrar dener — kendi kuyruğunu yiyen bir döngü.
4. Kademeler katalog ölçeğine bağlı
Limit aralıklarının tek bir sayı değil, aralık olarak açıklanmasının sebebi bu: kotanız katalog büyüklüğünüze göre belirleniyor. 50 bin ürünlük bir satıcı ile sınırsız katalog tanımlı bir satıcı aynı tavana sahip değil.
Pratik sonucu şu: bugünkü trafiğinize bakarak “bana yeter” diyemezsiniz. Hangi kademede olduğunuzu doğrulamadan kapasite planı yapmak, üst bandı varsayıp alt bantta çalışmak anlamına gelir. Bunu 14 Eylül’den önce panelden veya entegrasyon partnerinizden teyit edin.
5. 14 Eylül öncesi kapatılacak 6 kontrol
- API anahtarı envanteri çıkarın. Aynı satıcı hesabında kaç farklı sistem istek atıyor? ERP, panel, repricer, kargo entegrasyonu, raporlama aracı. Ortak kota havuzunda kimin ne kadar harcadığını bilmeden limit yönetemezsiniz.
- Dakikalık tepe trafiğinizi ölçün, ortalamanızı değil. Günlük 200 bin istek atan bir sistem, bunu 24 saate yaymıyor olabilir. Gece 03:00’te 40 dakikaya sıkışmış bir toplu iş, dakikalık limiti patlatır. Ölçüm birimi dakika olmalı.
- Yazma işlerini gruplayın. Oluşturma, güncelleme ve silme artık aynı kotada. Bu üçünü farklı saatlere dağıtın; hepsini aynı pencerede çalıştırmayın.
- Exponential backoff’u doğrulayın. 429 aldığında ne kadar bekliyorsunuz? Sabit 1 saniye yeterli değil. Her denemede katlanan bir bekleme ve üst sınırlı deneme sayısı olmalı. Retry-After başlığını okuyup ona uyan bir istemci en sağlamı.
- Repricer kurallarınızı barkod başına frekans açısından gözden geçirin. Dakikada 30 tavanına en yakın ürünlerinizi listeleyin. Genelde bu, en çok rekabet gördüğünüz 20-30 SKU’dur — yani ciro payı en yüksek olanlar.
- Kuyruk mimarisine geçin. Doğrudan API’ye yazan bir uygulama, limit değişikliğine her seferinde kodla cevap vermek zorundadır. Araya bir kuyruk koyup çıkış hızını tek yerden ayarlayabiliyorsanız, bir sonraki limit değişikliği sizin için konfigürasyon işi olur. No-code otomasyon araçlarının maliyet modeli bu kararın bütçe tarafını ayrıca ele alıyor.
6. Neden şimdi: Q4 çakışması
Tarihin kendisi tesadüf değil. 14 Eylül, Türkiye pazaryeri takviminde stok ve fiyat trafiğinin yükselmeye başladığı eşiğin hemen öncesi. 11.11, ardından 23–27 Kasım Efsane Cuma penceresi ve 30 Kasım Cyber Monday — bu üç dalga boyunca fiyat güncelleme hacminiz normal günlerin katlarına çıkar.
Yani limit değişikliğinin gerçek testi 14 Eylül’de değil, Kasım’da olacak. Eylül’de fark etmediğiniz bir mimari sorun, Efsane Cuma sabahı fiyatlarınızın güncellenmemesi olarak geri döner. Bu iki ayı, düşük trafikte hata ayıklamak için elinizdeki tek pencere olarak görün.
Fiyat güncellemelerinin gecikmesi doğrudan marja yazılır; komisyon, kargo ve iadeyi içeren birim ekonomi tablosu bu kaybın nerede biriktiğini gösteriyor. Katalog tarafındaki barkod ve varyant kuralları için ise pazaryeri katalog yönetimi yazısına bakabilirsiniz.
Limit değişikliklerinde asıl risk, limitin kendisi değil; limite takıldığınızda sisteminizin sessizce başarısız olmasıdır. 429 alan ama bunu hiçbir yere yazmayan bir entegrasyon, siz bir müşteri şikâyeti alana kadar sorunu size söylemez.
Kontrol listesi: bu hafta yapılacaklar
| Gün | İş | Çıktı |
|---|---|---|
| 10–11 Eylül | API anahtarı envanteri + dakikalık tepe trafik ölçümü | Hangi sistem, hangi saatte, kaç istek |
| 12 Eylül | Katalog kademenizi ve yeni kotanızı teyit edin | Yazılı limit değeri |
| 13 Eylül | Backoff ve retry mantığını test edin; 429 loglamasını açın | Alarm kurulu bir hata kanalı |
| 14 Eylül | Geçiş günü — toplu işleri düşük trafikte izleyin | İlk 24 saatin hata raporu |
Stok doğruluğu ve iptal oranı bu dönemde satıcı puanınıza doğrudan yansır; satıcı puanı metriklerinin nasıl hesaplandığını ayrı bir yazıda ele almıştım.
Doğrulama notu
Yukarıdaki limit değerleri Trendyol geliştirici dokümantasyonunun servis limitleri sayfasından alınmıştır. Pazaryerleri bu değerleri duyuru yapmadan güncelleyebiliyor; kritik bir kapasite planı yapmadan önce rakamları resmî dokümantasyondan tekrar teyit edin. Hepsiburada tarafında bu tarihe denk gelen bir limit değişikliği duyurusu bulunmuyor; ancak çok kanallı çalışıyorsanız kuyruk mimarisi kararınızı iki pazaryerini birlikte düşünerek verin.
Haftalık bülten
Pazaryeri ve e-ihracatta bu hafta ne değişti?
Komisyon oranları, mevzuat ve algoritma değişikliklerini haftada bir, tek e-postada özetliyorum. Reklam yok, tekrar yok — istediğiniz an tek tıkla çıkabilirsiniz.
[…] geçtiğini panelden doğrulayın; entegrasyonun “başarılı” demesi yeterli değil. 14 Eylül’de değişen API servis limitleri tam da bu noktada devreye […]