İyi log, geliştirici için uzun ham JSON yığını değil; hangi mağazada, hangi SKU'da, hangi işlemde, ne zaman ve neden hata olduğunu hızlı gösterebilen izlenebilir kayıttır.
Pazaryeri Entegrasyonunda Log Takibi ve Hata Teşhisi neden önemli?
Kullanıcı '14 ürün API'ye gönderildi ama 1 ürün eklendi' dediğinde, iş grubu ID'si, her satırın uzak task ID'si ve sonuç durumu logda yoksa teşhis saatler sürebilir.
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 işi kanal, mağaza, işlem türü ve benzersiz job ID ile etiketleyin. 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 işlemlerinde SKU/barkod ve uzak task/batch ID'yi kaydedin. 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.
- HTTP durum kodu ile pazaryeri hata kodunu ayrı saklayı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.
- İstek süresi, timeout ve deneme sayısını ölçü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.
- Hassas token ve kişisel veriyi logda maskeleyin. 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.
- Pending görevleri yaşına göre alarm listesine 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.
- Başarısız satırları hata nedeni ve son deneme zamanı ile raporlayı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.
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ı
Sadece 'başarısız' yazıp API hata mesajını kaybetmek.
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.
Secret/token değerlerini ham request loguna yazmak.
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.
Tek bir toplu job sonucuyla ürün bazlı durumu gizlemek.
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.
Eski logları sınırsız tutup disk alanını doldurmak.
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.
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
Hangi alanlar mutlaka loglanmalı?
Zaman, kanal, mağaza, işlem, job/request ID, SKU, durum, hata kodu ve deneme sayısı temel alanlardır.
Ham API cevabı saklanmalı mı?
Teşhis için kontrollü süreyle saklanabilir; kişisel ve gizli alanlar maskelenmelidir.
Pending alarmı ne zaman verilmeli?
Normal işlem süresini aşan görevler kanal ve işlem tipine göre eşik sonrası uyarıya düşmelidir.
İyi yazılım budur