E-Ticaret için Make & n8n Entegrasyon Çözümleri

E-ticaret entegrasyonu, sipariş verisinin mağaza panelinden muhasebe, kargo ve müşteri iletişimi sistemlerine elle taşınmasını ortadan kaldırmaktır; ancak bunu güvenilir yapan şey akışın kurulması değil, akış bozulduğunda ne olacağının tasarlanmasıdır. Entegrasyon projelerinde işin kolay kısmı mutlu senaryodur; asıl mühendislik, mükerrer teslimat ve düşen çalışmayla başa çıkmakta yatar.

E-ticarette Manuel Veri Girişinin Bedeli

Siparişlerin kargo sistemlerine elle girilmesi, faturaların manuel kesilmesi ve stok adetlerinin platformlar arasında gün sonlarında güncellenmesi, e-ticaret işletmelerinde en yaygın operasyonel darboğazdır. Bu süreçler kargo gecikmelerine, yanlış gönderimlere ve satılmış ürünün stokta görünmesine yol açar.

Manuel işin görünmeyen tarafı ise ölçeklenme biçimidir: sipariş adedi iki katına çıktığında veri girişi işi de iki katına çıkar. Bu, kalıcı değer üretmeyen ve hacimle doğrusal büyüyen bir yüktür — otomasyonun ilk hedefi tam olarak bu tür işlerdir.

Make.com Entegrasyon Mimarisi Nasıl Çalışır?

Mimarinin iskeleti dört katmandır:

• Tetikleyici: Sipariş oluştuğunda platform bir webhook çağrısı gönderir. Alternatif olarak belirli aralıklarla sorgulama (polling) yapılır; webhook hızlıdır, sorgulama ise kaçırılan olayları yakalar.
• Doğrulama ve dönüştürme: Gelen veri şema açısından denetlenir, alan eşleme yapılır (platformun alan adları hedef sistemin alan adlarına çevrilir), zorunlu alan eksikse iş istisna kuyruğuna alınır.
• Hedef sistem yazma: Muhasebe/ERP tarafında kayıt açılır, kargo tarafında gönderi oluşturulur, CRM tarafında müşteri kaydı güncellenir.
• Geri bildirim: Kargo takip numarası mağazaya ve müşteriye geri yazılır; böylece zincir kapanır.

Bu dört katmanın hepsinde geçerli tek tasarım ilkesi vardır: her adım kendi başına yeniden çalıştırılabilir olmalıdır. Make.com'un senaryo mantığı ve modül yapısına dair temel kavramları Make.com nedir yazısında, kurumsal ölçekteki uygulamasını ise kurumsal otomasyon çözümleri sayfasında anlatıyorum.

Teslim Garantisi ve Tekilleştirme: Entegrasyonun En Kritik Ayrıntısı

E-ticaret entegrasyonlarında en pahalı hatalar buradan çıkar: webhook teslimatı garantili değildir ve aynı olay birden fazla kez teslim edilebilir. Bu, kurulum hatası değil, sistemlerin çalışma biçimidir.

Somut bir örnek olarak Shopify'ın geliştirici dokümantasyonu, uygulamaların webhook verisine güvenmemesi ve veriyi düzenli mutabakat (reconciliation) işleriyle senkron tutması gerektiğini açıkça yazar. Mükerrer teslimatı yönetmek için her isteğin taşıdığı X-Shopify-Webhook-Id başlığının kullanılması, olayların sıralanması içinse X-Shopify-Triggered-At zaman damgasının okunması önerilir.

Tasarım karşılığı üç kuraldır. Birincisi tekillik anahtarı: her sipariş için hedef sistemde tek bir kayıt açılmasını sağlayan bir anahtar belirlenir (olay kimliği veya sipariş numarası) ve yazma işlemi bu anahtara göre “varsa güncelle, yoksa oluştur” mantığıyla yapılır. İkincisi hızlı yanıt: Shopify, uygulamanın webhook'a beş saniye içinde yanıt vermesini bekler; bu süreyi aşan teslimatlar başarısız sayılır. Doğru desen, önce yanıtı dönmek sonra işlemektir — ağır işi yanıt öncesine koymak, teslimatın başarısız sayılmasına ve gereksiz yeniden denemeye yol açar. Üçüncüsü mutabakat: günlük bir karşılaştırma işi, platformdaki sipariş listesiyle hedef sistemdeki kayıtları kıyaslar ve eksikleri tamamlar.

Düşen İş Nerede Bekler? Hata Yönetimi ve Yeniden Deneme

İkinci kritik ayrıntı, akış koptuğunda işin nerede beklediğidir. Burada iki ayrı katmanın davranışı bilinmelidir.

Platform tarafı: Shopify başarısız webhook çağrılarını dört saatlik bir süre içinde en fazla sekiz kez yeniden dener; denemeler arasındaki aralık her seferinde artar. İlk deneme dâhil dokuz başarısız girişimden sonra teslimat denemeleri durur ve abonelik silinebilir. Yani hedef sisteminiz saatlerce yanıt vermezse olay kalıcı olarak kaybolur.

Otomasyon platformu tarafı: Make'te düşen bir çalışmanın saklanması için “tamamlanmamış çalıştırmaların saklanması” ayarının açık olması gerekir ve bu ayar varsayılan olarak kapalıdır. Kapalı durumda hata oluştuğunda tamamlanmamış çalışma kaydedilmez — yani hiçbir kuyrukta beklemez. Bu, kurulumların en sessiz veri kaybı kaynağıdır: senaryo “çalışıyor” görünür, düşen işler ise hiç var olmamış gibi kaybolur. Ayar açıldığında düşen çalışmalar tamamlanmamış çalıştırmalar sekmesinde birikir ve elle veya otomatik olarak yeniden çalıştırılabilir.

Pratik kural: bir entegrasyon devreye alınmadan önce “bu akış şu an bozulursa hangi kayıt nerede bekler” sorusunun yazılı bir cevabı olmalıdır. Cevap yoksa, sistem hata anında sessizdir.

Çalışılmış Örnek: Bir Siparişin Uçtan Uca Yolculuğu

Girdi: mağazada saat 23:10'da bir sipariş oluşuyor; iki kalem ürün, kapıda ödeme, farklı fatura ve teslimat adresi.

Adım 1 (tetikleme): Platform sipariş olayını webhook ile gönderir. Akış olayı alır almaz yanıtı döner; işleme yanıttan sonra başlar.

Adım 2 (tekilleştirme): Olay kimliği daha önce işlenmiş mi diye kontrol edilir. İşlenmişse akış burada durur ve mükerrer kayıt oluşmaz — aynı olayın ikinci teslimatı bu adımda soğurulur.

Adım 3 (doğrulama): Zorunlu alanlar denetlenir. Teslimat adresinde ilçe bilgisi eksikse kayıt istisna kuyruğuna düşer ve operasyona bildirim gider; akış “boş geç” demez.

Adım 4 (yazma): Muhasebe tarafında sipariş kaydı, tekillik anahtarına göre “varsa güncelle, yoksa oluştur” mantığıyla açılır. Fatura ve teslimat adresleri ayrı alanlara yazılır.

Adım 5 (kargo): Gönderi oluşturulur ve takip numarası alınır. Kargo servisi yanıt vermezse akış burada durur ve iş tamamlanmamış çalıştırma olarak saklanır; ayar kapalı olsaydı bu sipariş sessizce kargosuz kalırdı.

Adım 6 (geri yazma ve bildirim): Takip numarası mağaza kaydına işlenir, müşteriye bilgilendirme gider.

Adım 7 (mutabakat): Ertesi sabah çalışan karşılaştırma işi, gün içindeki tüm siparişleri hedef sistemdeki kayıtlarla kıyaslar. Eksik varsa tamamlar, fazlalık varsa raporlar.

Çıktı: Sipariş gece işlenmiştir, ama asıl kazanç hızda değildir: hangi siparişin hangi adımda takıldığı görünürdür ve hiçbir kayıt sessizce kaybolmaz.

Ölçüm ve Veri: Entegrasyonun Getirisi Nasıl Hesaplanır?

Entegrasyon tekliflerinde sık görülen “sipariş başına 15 dakika tasarruf” türü rakamlar işletmeden işletmeye değişir ve doğrulanamaz. Bu sayfada rakam vaat etmek yerine ölçüm yöntemini sabitliyorum:

Son üç metrik özellikle önemlidir: bir entegrasyonun “çalışıyor” sayılması, hata üretmemesi değil, ürettiği hatanın görünür olmasıdır.

Hata Desenleri ve Riskler

• Tekillik anahtarı koymamak. Mükerrer teslimat kaçınılmazdır; anahtar yoksa aynı sipariş iki kez faturalanır veya iki kez kargoya verilir.
• Tamamlanmamış çalıştırma saklamayı açmamak. Ayar varsayılan olarak kapalıdır; kapalıyken düşen iş hiçbir kuyrukta beklemez ve sessizce kaybolur.
• Webhook'a güvenip mutabakat kurmamak. Platform dokümanı bile webhook verisine güvenilmemesini ve düzenli karşılaştırma yapılmasını önerir.
• Yanıtı işlemden sonra dönmek. Beş saniyelik yanıt penceresi aşıldığında teslimat başarısız sayılır ve gereksiz yeniden deneme zinciri başlar.
• Hata bildirimini kimseye bağlamamak. Bir yere düşen ama kimseye haber vermeyen istisna kuyruğu, dolu bir çöp kutusudur.
• Stok yazmayı tek yönlü kurmak. Birden çok satış kanalı varsa tek yönlü senkron, bir kanalda tükenen ürünü diğerinde satmaya devam eder.
• Test verisini canlı sisteme akıtmak. Ayrı test bağlantısı olmadan yapılan denemeler muhasebe kayıtlarını kirletir ve geri alması pahalıdır.
• Alan eşlemeyi belgelememek. Hangi alanın nereye yazıldığı yazılı değilse, altı ay sonra kimse akışa dokunamaz.

Kurulum Sırası: Hangi Entegrasyon Önce Yapılır?

1. Taban ölçüm: Elle işlem süresi, hata adedi ve gecikmeler iki hafta boyunca kaydedilir.
2. Alan eşleme belgesi: Kaynak ve hedef sistemlerin alanları tablo hâlinde eşlenir; zorunlu alanlar ve dönüşüm kuralları yazılır.
3. Tek yönlü sipariş akışı: Önce yalnızca sipariş → muhasebe yönü kurulur, tekillik anahtarı ve istisna kuyruğu ile birlikte.
4. Kargo ve geri yazma: Gönderi oluşturma ve takip numarasının geri yazılması eklenir.
5. Stok senkronu: Çok kanallı satış varsa iki yönlü stok akışı en son kurulur; en riskli katman budur.
6. Mutabakat işi: Günlük karşılaştırma devreye alınır ve raporu bir sorumluya bağlanır.

Bu sıranın gerekçesi risk dağılımıdır. İlk üç adım geri alınabilir: yanlış eşlenen bir alan düzeltilir, hatalı açılmış bir kayıt silinir. Stok senkronu ise geri alınması en zor katmandır çünkü iki yönlüdür ve yanlış kurulduğunda hatayı her iki sisteme birden yazar. Aynı mantık devreye alma biçimi için de geçerlidir: yeni bir akış doğrudan tüm siparişlere açılmaz, önce sınırlı bir alt kümede gölge koşum yapılır — sistem kaydı hazırlar, insan doğrular. Uyuşmazlıklar kural düzeltmesine dönüştükten sonra akış tam hacme açılır.

Devreye alma sonrasında ilk iki hafta boyunca istisna kuyruğu ve tamamlanmamış çalıştırma sayısı her gün okunur. Bu iki sayı sıfıra yaklaşmıyorsa sorun akışta değil çoğunlukla veri kalitesindedir; kaynak sistemdeki eksik alanlar düzeltilmeden otomasyonun düzgün çalışması beklenmemelidir.

Kaynaklar ve Referanslar

• Shopify webhook teslimatı: garanti edilmemesi, X-Shopify-Webhook-Id ile tekilleştirme ve mutabakat önerisi — Shopify Geliştirici Dokümantasyonu
• Shopify webhook yeniden deneme politikası: dört saat içinde sekiz deneme, beş saniyelik yanıt penceresi — Shopify webhook sorun giderme
• Tamamlanmamış çalıştırmaların varsayılan olarak saklanmadığı — Make Yardım Merkezi