Pazaryeri entegrasyonu için teklif toplayan bir firma genellikle iki tür cevap alır. Biri aylık abonelikle çalışan entegrasyon programlarından gelir: "Yarın başlarsınız." Diğeri bir yazılım firmasından: "Sizin yapınıza göre geliştiririz." İkisi de doğru söyler. Ama karşılaştırma çoğu zaman yanlış soruyla yapılır: "Hangisi daha ucuz?" Doğru soru şudur: Entegrasyonun içindeki iş kuralları kimin?
Bu yazıda iki yolu da dürüst biçimde tartıyoruz. Teknik tarafı tahminle değil, Trendyol'un resmi geliştirici dokümantasyonundaki kurallarla anlatıyoruz. Sonunda da kendi durumunuzu puanlayabileceğiniz bir tablo var.
Kısa cevap: Pazaryeri entegrasyonu, ürün, stok, fiyat, sipariş ve iade bilgisinin ERP'niz ya da e-ticaret siteniz ile Trendyol, Hepsiburada, n11 gibi pazaryerleri arasında API üzerinden otomatik taşınmasıdır. Ürünleriniz ve süreçleriniz standartsa hazır entegratör neredeyse her zaman daha hızlı ve ucuzdur. Kanal bazlı fiyat kuralları, firmaya özel ERP alanları, on binlerce SKU ya da aynı veriyi kullanan başka iç sistemler varsa kendi entegrasyon katmanınız uzun vadede daha az ödün verir. Pek çok firma için en iyi cevap ikisinin karışımıdır.
Neden Bu Karar Artık Daha Önemli?
Ticaret Bakanlığı'nın 12 Mayıs 2026'da yayımladığı Türkiye'de E-Ticaretin Görünümü Raporu'na göre 2025'te e-ticaret hacmi yüzde 52,2 artarak 4,5 trilyon lirayı aştı. E-ticaretin genel ticaret içindeki payı yüzde 19,3'e çıktı ve e-ticaret yapan işletme sayısı 634.611'e ulaştı (ETBİS duyurusu).
Kaynak: Ticaret Bakanlığı, Türkiye'de E-Ticaretin Görünümü Raporu 2025 (ETBİS)
Öbür tarafta bir yoğunlaşma var: ETBİS 2025 verilerine dayanan haberlere göre pazaryerlerinde satış yapan işletmelerin yaklaşık yüzde 79'u tek bir pazaryerinde satıyor (Ticaret Gazetesi, 22 Ağustos 2026). Yani satıcıların büyük kısmı ikinci, üçüncü kanala hiç açılmamış. Bunun en sık sebebi talep eksikliği değil, operasyon yükü: İkinci kanal, aynı stoğu iki yerde doğru tutmak demek. Entegrasyon tam olarak bu yükü taşıyan parçadır.
"Entegrasyon" Tek Bir Şey Değil, Dört Ayrı Akış
Teklifleri karşılaştırmadan önce neyi satın aldığınızı parçalara ayırmak gerekir. Bir pazaryeri entegrasyonu pratikte dört farklı veri akışından oluşur ve her birinin zorluğu farklıdır:
| Akış | Yön | Ne sıklıkla? | En sık sorun |
|---|---|---|---|
| Ürün aktarımı | Sizden pazaryerine | Ürün eklendiğinde / değiştiğinde | Kategori ve özellik eşleştirmesi, görsel kuralları, onaya takılan ürünler |
| Stok ve fiyat | Sizden pazaryerine | Gün içinde sürekli | Gecikme, aşırı satış (overselling), kanal bazlı fiyat farkı |
| Sipariş | Pazaryerinden size | Gün içinde sürekli | Siparişin ERP'ye iki kez yazılması ya da hiç yazılmaması |
| İade, iptal, fatura | İki yönlü | Sipariş sonrası | İadenin stoğa dönmemesi, faturanın pazaryerine iletilmemesi |
Hazır entegratörlerin satış sayfaları genellikle ilk satırı öne çıkarır: "Ürünlerinizi tek tıkla aktarın." Oysa canlıda sorun çıkaran akışlar çoğunlukla ikinci ve üçüncü satırlardır. Ürün aktarımı bir kez yapılan bir iştir. Stok ve sipariş ise her gün, her saat doğru çalışmak zorundadır.
Hazır Entegratörün Gerçekten İyi Yaptığı İşler
Bir yazılım firması olarak bunu söylemek bize kazandırmıyor ama doğrusu bu: Çoğu satıcı için hazır entegratör doğru başlangıçtır. Sebepleri somut:
- Pazaryeri değişikliklerini sizin yerinize takip ederler. Pazaryerleri API sürümlerini, kategori ağaçlarını ve zorunlu alanlarını değiştirir. Abonelik ücretinin önemli bir kısmı aslında bu takip işinin bedelidir.
- Kategori eşleştirme ekranları hazırdır. Kendi yazılımınızda bu ekranı sıfırdan yapmak, beklenenden fazla iş çıkarır.
- Kargo ve e-fatura bağlantıları çoğu zaman pakette gelir. Ayrı ayrı entegre etmek zorunda kalmazsınız.
- Başlama maliyeti düşüktür. Deneyip vazgeçmek mümkündür. Özel geliştirmede bu esneklik yoktur.
Ürünleriniz standart, fiyatınız her kanalda aynı ya da basit bir yüzde farkıyla belirleniyor ve muhasebe programınız entegratörün desteklediği listede yer alıyorsa, kendi yazılımınızı yazmak için iyi bir sebebiniz büyük ihtimalle yok.
API'nin İçinden Bakınca: Trendyol Örneğiyle Gerçek Kurallar
Kendi entegrasyonunuzu yazmayı düşünüyorsanız işin neye benzediğini bilmeniz gerekir. Trendyol'un herkese açık geliştirici dokümantasyonundaki birkaç kural, bir entegrasyonun neden "API'ye istek atmaktan" ibaret olmadığını iyi gösteriyor:
1. İstek sınırı uç nokta başına. Aynı uç noktaya 10 saniyede en fazla 50 istek atılabiliyor; aşılırsa 429 too.many.requests dönüyor. Her isteğin User-Agent başlığında satıcı numarası ile entegratör adı (kendiniz entegre ediyorsanız "Self Integration") bulunmak zorunda. Bu başlık yoksa istek 403 ile reddediliyor (Trendyol, Yetkilendirme).
2. Stok ve fiyat toplu ve asenkron gidiyor. Tek istekte en fazla 1.000 SKU güncellenebiliyor ve aynı istek 15 dakika boyunca tekrar gönderilemiyor. Güncellemenin gerçekten işlenip işlenmediğini, dönen toplu işlem numarasıyla ayrıca sorgulamanız gerekiyor (Trendyol, Stok ve Fiyat Güncelleme).
3. Webhook var ama tek başına yetmiyor. Sipariş durum değişikliklerini (oluşturuldu, faturalandı, kargolandı, iade edildi vb.) webhook ile almak mümkün. Başarısız bildirimler 5 dakikada bir yeniden deneniyor, tekrarlayan hatalarda webhook pasife düşüyor. Dokümantasyon, webhook her zaman ulaşamayabileceği için periyodik veri çekme de geliştirilmesini açıkça tavsiye ediyor (Trendyol, Webhook Modeli).
4. Test ortamına erişim IP ile sınırlı. Stage ortamı yalnızca beyaz listeye eklenen IPv4 adreslerinden erişilebilir, en fazla 7 IP tanımlanabiliyor ve kayıtların bir son geçerlilik tarihi var (Trendyol, Test Ortamı IP Whitelist).
Bunların yazılım tarafındaki karşılığı şudur:
- Değişen stokları kuyruğa almanız, 1.000'lik paketlere bölmeniz ve hız sınırına göre göndermeniz gerekir.
- Her güncellemenin sonucunu ayrıca kontrol edip reddedilenleri bir ekranda göstermeniz gerekir. Aksi halde "stoğu gönderdik" sanıp aşırı satış yaşarsınız.
- 10.000 SKU'luk bir katalogda "her şeyi her 5 dakikada bir gönder" yaklaşımı çalışmaz. Sadece değişeni göndermek zorunda kalırsınız. Bu da son gönderilen değeri tutan bir ara veri katmanı demektir.
- Siparişleri hem webhook'tan hem periyodik sorgudan aldığınız için aynı sipariş iki kez gelebilir. ERP'ye yazmadan önce tekrar kontrolü şarttır.
Bu dört madde hazır entegratörlerin arka planda çözdüğü işlerdir. Kendi yazılımınızı yazacaksanız bunları da yazarsınız. Üstelik her pazaryeri için ayrı ayrı, çünkü Hepsiburada ve n11'in kuralları ve veri modelleri Trendyol'unkinden farklıdır.
Kendi Entegrasyonunuz Ne Zaman Mantıklı? 8 Soruluk Puanlama
Aşağıdaki her soruya "evet" diyorsanız 1 puan yazın:
| # | Soru | Evet ise |
|---|---|---|
| 1 | Aynı ürünün fiyatı kanala, kampanyaya ve maliyete göre farklı bir formülle mi hesaplanıyor? | +1 |
| 2 | ERP'nizde firmaya özel alanlar, belge tipleri ya da depo yapısı var mı ve hazır programlar bunları taşıyamıyor mu? | +1 |
| 3 | Katalogunuz on binlerce SKU'dan ve sık değişen stoktan mı oluşuyor? | +1 |
| 4 | Pazaryeri siparişleri, kendi sitenizin ve bayi kanalınızın siparişleriyle aynı stoktan mı düşüyor? | +1 |
| 5 | Entegrasyon verisini başka iç sistemler de (depo, raporlama, servis) kullanmak zorunda mı? | +1 |
| 6 | Abonelik ücreti sipariş ya da ürün sayısıyla birlikte artıyor ve bu kalem büyüyor mu? | +1 |
| 7 | Entegratörün yol haritasını beklemekten dolayı kampanya ya da kanal açılışı gecikti mi? | +1 |
| 8 | Entegrasyonu yaşatacak bir teknik ekibiniz ya da uzun vadeli bir yazılım ortağınız var mı? | +1 |
- 0–2 puan: Hazır entegratör kullanın. Kendi yazılımınızın getirisi, maliyetini karşılamaz.
- 3–5 puan: Hibrit yol (aşağıda). Entegratörü bırakmadan, sadece size özel kuralları kendi katmanınıza alın.
- 6–8 puan: Kendi entegrasyon katmanınızı değerlendirin. 8. soruya "hayır" dediyseniz önce onu çözün. Sahibi olmayan bir entegrasyon, pazaryeri ilk API değişikliğini yaptığında durur.
- soru bilerek listede. Özel entegrasyonun asıl maliyeti geliştirme değil, yıllarca bakımdır.
Üçüncü Yol: Entegratör Kalsın, Kurallar Sizde Olsun
En çok önerdiğimiz yapı ikisinin arasındadır. Pazaryeriyle konuşan katmanı (API çağrıları, kategori eşleştirme, kargo etiketi) hazır entegratör yürütür. Ama fiyatın ve stoğun hesaplandığı yer sizin kontrolünüzdeki küçük bir ara servistir:
- ERP'den maliyet, stok ve ürün verisi ara servise gelir.
- Ara servis kanal bazlı fiyatı, güvenlik stoğunu (örneğin "son 3 adedi pazaryerinde gösterme") ve kampanya kurallarını uygular.
- Sonuç, entegratöre onun desteklediği yöntemle (API ya da XML) verilir.
- Siparişler entegratörden ERP'ye akarken ara servis tekrar kontrolünü yapar ve siparişin hangi kanaldan geldiğini işaretler.
Bu yapıda pazaryerlerinin değişen kurallarını entegratör takip etmeye devam eder. Sizin iş kurallarınız ise bir abonelik ürününün ayar ekranına sıkışmaz. Entegratör değiştirmek istediğinizde de kurallarınız yerinde kalır.
Maliyeti Doğru Karşılaştırmak: 3 Yıllık Bakış
Bu yazıda fiyat vermiyoruz, çünkü entegratör paketleri sipariş hacmine ve kanal sayısına göre çok değişiyor. Bunun yerine iki teklifi aynı tabloya koymanın yolunu verelim:
| Kalem | Hazır entegratör | Kendi entegrasyonunuz |
|---|---|---|
| Başlangıç | Kurulum ve eşleştirme emeği | Analiz ve geliştirme |
| Aylık sabit | Abonelik | Sunucu ve izleme |
| Hacimle artan | Sipariş, ürün ya da kanal başı ücret (varsa) | Genellikle yok |
| Pazaryeri API değişiklikleri | Pakete dahil | Sizin bakım bütçeniz |
| Yeni pazaryeri eklemek | Çoğu zaman bir ayar | Yeni bir geliştirme |
| İş kuralı değişikliği | Paket izin verdiği kadar | Sizin kararınız |
| Firmadan çıkış | Kurallar pakette kalır | Kod ve veri sizindir |
İki sütunu 36 ay için toplayın. Kendi entegrasyon sütununa yıllık bakım için geliştirme maliyetinin belirli bir oranını mutlaka ekleyin. Bu satırı boş bırakan her hesap, özel yazılımı olduğundan ucuz gösterir. Benzer bir tuzağı yazılımda en ucuz teklif yazımızda ayrıntılı anlattık.
Veri Taşınabilirliği Taslağı Neyi Değiştirebilir?
Ağustos 2026'da basına yansıyan bir yönetmelik taslağına göre Ticaret Bakanlığı, orta, büyük ve çok büyük ölçekli pazaryerlerinin satıcı talep ettiğinde ürün açıklamaları, görseller, satış ve iade verileri ile müşteri değerlendirmelerini başka bir pazaryerine bedelsiz aktarmasını öngörüyor (Ticaret Gazetesi). Bu yazı yayımlandığında düzenleme taslak aşamasındaydı; son hali değişebilir.
Yürürlüğe girerse yeni bir pazaryerine açılmanın en zahmetli kısmı (ürün içeriğini ve itibarı sıfırdan kurmak) hafifleyebilir. Ama bu, entegrasyon ihtiyacını azaltmaz, artırır. Kanal sayısı arttıkça stoğun ve fiyatın tek bir yerden yönetilmesi daha kritik hale gelir. Ürün verisinin "asıl" kopyasının hangi sistemde durduğu sorusunu şimdiden netleştiren firmalar bu değişikliğe daha hazırlıklı olur.
Kendi Deneyimimizden Bir Not
Digitexa olarak bu yazıda bir pazaryeri müşteri projesinden rakam vermiyoruz. Paylaşacağımız doğrulanmış bir örnek olmadığı için örnek uydurmuyoruz. Ancak entegrasyonun asıl zorluğunun API çağrısında değil, veri sahipliğinde olduğunu ERP tarafında yaşadık. Parça E-Kuralkan projesinde 50.000'den fazla ürün, bayi bazlı fiyat ve ERP ile senkron stok vardı. Belirleyici kararlar ekranlardan önce şunlardı: Fiyat nerede hesaplanıyor, stok ne sıklıkla ve hangi yönde akıyor, bir kayıt iki kez gelirse ne oluyor? Pazaryeri entegrasyonunda da sorular aynı. Sadece karşı tarafta ERP yerine birden fazla pazaryeri var. Bayi kanalı için aynı soruları B2B bayi portalı yazımızda sipariş üzerinden anlattık.
Teklif İsterken Sorulacak 6 Soru
İster bir entegratörle, ister bir yazılım ajansı ile görüşün, şu soruların cevabı teklifin kendisinden daha çok şey söyler:
- Stok güncellemesi ne kadar gecikmeyle pazaryerine yansıyor ve reddedilen güncellemeyi nerede görüyorum?
- Aynı sipariş iki kez gelirse ERP'ye iki kez yazılmasını ne engelliyor?
- Kanal bazlı fiyatı hangi kurallarla tanımlayabiliyorum? Örnek bir ürünle gösterilmesini isteyin.
- Pazaryeri API'sini değiştirdiğinde güncelleme kimin sorumluluğunda ve ne kadar sürede yapılıyor?
- İade, stoğa otomatik dönüyor mu? Fatura pazaryerine nasıl iletiliyor?
- Ayrılmak istersem eşleştirmelerim, kurallarım ve sipariş geçmişim bana hangi formatta veriliyor?
Altıncı soru, iki modelin farkını en net gösteren sorudur.
Son Söz
Pazaryeri entegrasyonunda "hazır mı, özel mi" sorusunun genel bir doğru cevabı yok. Belirleyici olan, iş kurallarınızın ne kadar size özgü olduğu ve entegrasyonu yıllarca kimin yaşatacağı. Standart bir katalog ve tek fiyat politikasıyla satıyorsanız hazır entegratörle başlayın ve paranızı ürüne ve reklama harcayın. Fiyatınız kanal kanal hesaplanıyor, ERP'niz size özel ve pazaryeri siparişleri bayi ya da site siparişleriyle aynı stoğu paylaşıyorsa, kuralların sizde kaldığı bir katman kurmanın zamanı gelmiş olabilir.
E-ticaret altyapınızı bir bütün olarak düşünüyorsanız e-ticaret yazılımı çözümlerimize, ERP'nize ve iş kurallarınıza göre bir ara katman ya da entegrasyon gerekiyorsa özel yazılım geliştirme sürecimize göz atabilirsiniz. Mevcut yapınızı anlatırsanız iletişim üzerinden ilk görüşmede hangi yolun size uyduğunu açıkça söyleriz. Hazır bir entegratör yetiyorsa bunu da söyleriz.
