Trendyol ve Hepsiburada entegrasyon hatalarını çözmek: yaygın sorunlar ve kalıcı çözüm

Trendyol veya Hepsiburada entegrasyonu hata verdiğinde sorun nadiren API'nin kendisinde kalır. Barkod eşleşmez, kategori reddedilir, stok güncellemesi hız sınırına çarpar, sipariş webhook'u hiç gelmez ya da kargo bilgisi pazaryerine dönmez. Her birinin resmi bir karşılığı vardır: belirli bir HTTP hata kodu, tek bir kök neden ve her hafta geri gelmeyen, kalıcı bir çözüm.

Özet

Trendyol hata kodlarını resmi olarak dokümante ediyor: ürün ve kategori reddi için 400/409, toplu güncelleme hız sınırı için 429, geçici sunucu arızası için 500/502/503, zaman aşımı için 504. Hiçbiri entegratör markası değiştirmekle çözülmüyor. Hattaki o tek adımı düzelterek ve her toplu işlemden sonra getBatchRequestResult ile sonucu kontrol ederek çözülüyor; 200 cevabı katalogun gerçekten güncellendiği anlamına gelmiyor.

Beş hata sınıfı ve resmi kodları

Trendyol'un kendi hata kodu dokümantasyonu (developers.trendyol.com/docs/hata-kodlari) HTTP katmanını net tanımlıyor. Tanımlamadığı şey, pratikte hangi hattın hangi kodu verdiği; bu da genelde bir destek bileti ve bir gün kaybıyla öğrenilen kısım:

Barkod ve ürün kodu neden eşleşmiyor

ERP'nin kendi barkod veya SKU standardı var. Trendyol her varyant için kendi barkod alanını zorunlu tutuyor, ikisi renk veya bedende ayrıştığı an istek 400 Bad Request ile geri dönüyor ya da ürün sessizce pasif kalıyor. Çözüm tek seferlik bir temizlik değil: ERP'nin SKU'su ile pazaryerinin barkodu arasında tekil bir eşleme tablosu, ve bu tabloya düşmeden hiçbir yeni varyantın gönderilmemesi kuralı.

Kategori ve öznitelik reddi: 400 ve 409'un asıl anlamı

Trendyol kategori ağacını (getCategoryTree) düzenli güncelliyor. Bir kategori ID'si taşındığında veya yeni bir zorunlu öznitelik eklendiğinde, eski şemayla gönderilen ürün artık kabul edilmiyor. 409 Resource Conflict, kaynağın isteğin beklediği durumda olmadığı anlamına geliyor; eksik bir alan ise düz 400 ile dönüyor. Kalıcı çözüm, kategori ağacını periyodik çekmek ve zorunlu öznitelik listesini Trendyol reddetmeden önce, istek sisteminizden çıkmadan local'de doğrulamak.

Stok ve fiyat toplu güncellemesi neden 429 ile geri dönüyor

Tüm katalog tek seferde push edilince Trendyol'un belirlediği hız sınırı aşılıyor ve cevap 429 Too Many Requests olarak dönüyor. Çözüm, yalnızca değişen SKU'ları gönderen diff bazlı bir batch, en yüksek hacimli ürünler için schedule beklemeden event bazlı push, ve her batch sonrası getBatchRequestResult çağrısı. 200 cevabı isteğin kabul edildiği anlamına gelir, her satırın güncellendiği anlamına gelmez; bu fark, sonuç kontrolü olmayan bir retry döngüsünün tam olarak gözden kaçırdığı şey.

Sipariş webhook'u gelmiyor, kargo bilgisi pazaryerine dönmüyor

Sipariş webhook'ları (order.created, order.cancelled) Trendyol tarafında geçici bir 500, 502 veya 503 ile başarısız olabiliyor. Bunu tek atış kabul edip retry yapmazsanız sipariş sisteminizde hiç görünmüyor. Kargo tarafında ise updateBoxInfo ve kargo kodu tek, yavaş bir istekle birlikte gönderildiğinde 504 Gateway Timeout alınıyor, paket pazaryerinde "kargoya verildi" durumuna geçmiyor ve satıcı gecikme cezası riskini taşıyor. Kalıcı çözüm: her webhook'u 3 deneme ve dead-letter kuyruğundan geçirmek, kargo bildirimini zaten zaman aşımına açık sipariş durumu güncellemesine bağlamadan kendi retry'i olan ayrı bir adım yapmak.

Hazır entegratör mü, özel entegrasyon mu

Katalog basit ve Trendyol tek kanalsa hazır bir entegratör çalışıyor; bunun nerede bittiğini daha önce yazdığımız stok senkronu rehberi gösteriyor. Hepsiburada devreye girdiğinde veya ERP standart şablona uymadığında, bu beş hata sınıfına ne kadar görünürlüğün olduğu belirleyici hale geliyor:

Kalıcı çözüm: getBatchRequestResult ile izleme kurmak

Trendyol'un toplu işlem kontrolü servisi getBatchRequestResult, her ürün, stok veya fiyat gönderimi için satır bazında bir sonuç döndürüyor: kabul mü, reddedildi mi, hangi sebeple. Bunu her batch sonrası otomatik çekmeden entegrasyon "çalışıyor" görünürken günlerce sessizce ürün reddediyor olabilir. Stok senkronu için kurduğumuz dashboard mantığı burada da geçerli: SKU bazlı son başarılı kontrol zamanı, reddedilen satır sayısı, tam hata mesajı, iki hafta sonra mağaza skorundan fark etmek yerine otomatik kontrol.

Entegratör ne zaman hâlâ yeterli

Tek kanal, küçük katalog ve düşük hacim varsa hazır bir entegratörün standart hata bildirimi genelde yeterli; o ölçekte özel entegrasyon yatırımı önlediği hatanın maliyetinden daha fazlasına mal olur. Karar noktası, ikinci bir pazaryeri, standart dışı bir ERP veya aynı hata sınıfının her hafta tekrar etmesiyle geliyor.

Durum buysa çözüm entegratör markası değiştirmek değil, hatanın işaret ettiği kök nedeni kapatmak. Lumiasoft'un Trendyol entegrasyonu çalışması önce bu nedeni teşhis ediyor, sonra kapatıyor.

Sık sorulan sorular

Aynı Trendyol entegrasyon hatası neden tekrar ediyor? Kök neden kapatılmadığı için. 429 veya 504 geçici görünür ama altında genelde diff'siz gönderilen bir batch veya zaman aşımına karşı payı olmayan tek bir istek vardır.

Aynı hata sınıfları Hepsiburada için de geçerli mi? Evet. API şeması farklı olsa da barkod uyumsuzluğu, kategori/öznitelik reddi, hız sınırı ve kargo bildirim gecikmesi iki pazaryerinde de aynı dört sınıfta toplanıyor.

Ücretsiz bir entegratör bu hataları çözer mi? Tek kanal ve basit katalokta genelde evet. İkinci pazaryeri veya standart dışı ERP eklenince hata görünürlüğü entegratörün panelinin gösterdiğiyle sınırlı kalıyor.

Kalıcı çözüm ne kadar sürüyor? Hata sınıfına göre değişir. Tek bir kök nedeni kapatmak günler sürer; tüm hattı kapsayan bir izleme kurulumu 1-2 hafta alır.