E-ticaret entegrasyonu, mağazada oluşan verilerin muhasebe, ERP, pazar yeri, kargo veya depo gibi başka sistemlere kontrollü biçimde aktarılması ve bu sistemlerden gelen durumların mağazaya geri işlenmesidir. Buradaki amaç yalnızca iki yazılımı “bağlamak” değildir. Hangi kaydın esas alınacağı, alanların nasıl eşleneceği, bir olay iki kez gelirse ne yapılacağı ve bağlantı kesildiğinde sürecin nasıl toparlanacağı da entegrasyonun parçasıdır.
Bu nedenle çalışan bir eklenti görmek, entegrasyonun güvenilir olduğunu tek başına göstermez. Sağlıklı bir kurgu; veri sözleşmesi, kimlik eşleme, durum yönetimi, hata kuyruğu ve mutabakat mekanizmasıyla birlikte değerlendirilir.
E-ticaret entegrasyonu hangi parçaları tanımlar?
İlk karar, her veri türü için “doğru kaynak” sistemin belirlenmesidir. Ürün açıklaması mağazada, stok ERP’de, kargo takip numarası ise taşıyıcının sisteminde yönetiliyor olabilir. Aynı alan iki tarafta da değiştirilebiliyorsa son yazanın kazanması çoğu zaman yeterli değildir; eski bir güncelleme yeni verinin üzerine yazabilir.
Uygulamada aşağıdaki başlıklar açıkça tanımlanmalıdır:
- Kayıt kimliği: Mağazadaki sipariş numarası, ERP belge numarası ve kargo gönderi kodu aynı işlemle nasıl ilişkilendirilecek?
- Alan eşleme: SKU, varyant, vergi, indirim, para birimi ve adres alanları karşı sistemde hangi biçimde tutulacak?
- Yön ve sıklık: Veri tek yönlü mü, çift yönlü mü; anlık olayla mı, zamanlanmış toplu işlemle mi aktarılacak?
- Durum geçişleri: Hangi sistem hangi durumu değiştirebilir; iptal, iade veya parçalı sevkiyat nasıl temsil edilir?
- Yetkilendirme: API anahtarının erişebileceği kaynaklar, süresi ve yenileme yöntemi nedir?
Örneğin WooCommerce’in resmî Orders API dokümantasyonu, sipariş kayıtlarının oluşturulması, görüntülenmesi ve güncellenmesi için kimlik ve durum alanları sunar. Ancak bu uç noktaların varlığı, ERP’deki alanların kendiliğinden doğru eşleneceği anlamına gelmez; dönüşüm kuralları işletmeye özgü bir sözleşme olarak yazılmalıdır.
API, webhook ve zamanlanmış mutabakat birlikte nasıl çalışır?
API, bir sistemin diğerinden veri istemesine veya veri yazmasına yarar. Webhook ise belirli bir olay oluştuğunda karşı sisteme bildirim gönderir. Webhook anlık akışı hızlandırır; fakat tek güvence olarak kullanılması risklidir. Shopify’ın resmî webhook kılavuzu, olayların her zaman oluşma sırasıyla ulaşmayabileceğini ve kaçırılan kayıtları bulmak için periyodik mutabakat işi kurulmasını önerir.
Bu üç katman pratikte birbirini tamamlar:
- Webhook, değişikliği hızlıca bildirir.
- Entegrasyon, API üzerinden güncel kaydı doğrular ve hedef sisteme işler.
- Zamanlanmış mutabakat, iki taraftaki kayıtları karşılaştırarak kayıp veya takılı işlemleri yakalar.
Mutabakat yalnızca toplam sayıyı karşılaştırmamalıdır. Haricî kimlik, son güncelleme zamanı, tutar, para birimi ve beklenen durum gibi alanlar denetlenmelidir. Böylece “100 kayıt iki tarafta da var” sonucunun arkasında gizlenen yanlış eşleşmeler görülebilir.
Idempotency neden kritik bir güvenlik katmanıdır?
Ağ bağlantısı kesildiğinde istemci aynı isteği yeniden göndermek zorunda kalabilir. İlk istek aslında işlendiği hâlde cevap ulaşmadıysa, ikinci deneme çift kayıt veya çift tahsilat üretebilir. Idempotency, aynı işlem anahtarıyla yinelenen isteğin yeni bir işlem oluşturmak yerine önceki sonuca bağlanmasını sağlar. Stripe’ın idempotent istek dokümantasyonu, güvenli yeniden deneme için benzersiz bir anahtar kullanılmasını ve aynı anahtarın farklı parametrelerle kullanılmamasını tarif eder.
Webhook tarafında da tekrar teslim beklenen bir durumdur. Shopify’ın teslimat doğrulama kılavuzu, bildirimin HMAC ile doğrulanmasını ve aynı Shopify-Webhook-Id değerinin daha önce işlenip işlenmediğinin saklanmasını önerir. Benzer yaklaşım, başka sağlayıcılarda olay kimliği veya işletmenin ürettiği işlem anahtarıyla kurulabilir.
Burada anahtar seçimi önemlidir. “Bugünün tarihi + müşteri” gibi çakışabilecek bir değer yerine, işleme özgü ve kararlı bir kimlik kullanılmalıdır. Aynı olay yeniden geldiğinde sistem önceki sonucu döndürmeli; farklı bir işlem yanlışlıkla aynı anahtarı kullanırsa isteği reddetmelidir.
Durum senkronizasyonu nasıl tasarlanır?
Durumlar düz bir metin listesi değil, izin verilen geçişleri olan bir akış olarak ele alınmalıdır. Örneğin “hazırlanıyor” kaydının eski bir webhook yüzünden yeniden “ödeme bekliyor” durumuna dönmesine izin verilmemelidir. Güncelleme zamanı, olay sürümü veya artan sıra numarası kontrol edilerek daha eski olaylar ayıklanabilir.
Varsayımsal örnek: Bir mağaza siparişi ERP’ye gönderir; ERP kendi belge kimliğini döndürür; depo sevkiyatı açınca kargo sistemi takip kodu üretir ve mağaza müşteriye güncel durumu gösterir. ERP geçici olarak erişilemezse olay kaybolmaz, tekrar deneme kuyruğunda tutulur. Aynı sipariş yeniden gönderildiğinde haricî sipariş kimliği sayesinde ikinci belge açılmaz. Bu örnek, belirli bir sağlayıcının hazır özelliği değil, güvenilir akışın nasıl kurgulanabileceğini gösterir.
Canlıya almadan önce hangi testler yapılmalı?
- Aynı olay iki veya daha fazla kez gönderildiğinde tek kayıt oluşuyor mu?
- “Güncelle” olayı “oluştur” olayından önce gelirse sistem toparlayabiliyor mu?
- Hedef sistem 429 veya 500 döndürdüğünde kontrollü aralıklarla tekrar deneniyor mu?
- Aktarımın yarısında hata oluştuğunda hangi adım geri alınıyor, hangisi yeniden başlatılıyor?
- API yetkisi bittiğinde alarm oluşuyor ve başarısız kayıtlar görünür bir kuyrukta kalıyor mu?
- Alan veya şema değişikliği eski kayıtları sessizce bozuyor mu?
Teknik kabul kriterleri, site projesinin başında yazılmalıdır. Bu konu kurumsal web sitesi yaptırırken dikkat edilmesi gerekenler çerçevesindeki kapsam ve teslim ölçütleriyle birlikte ele alınabilir. Entegrasyonun işletmeye etkisi ise yalnızca kayıt aktarımıyla değil, web sitesindeki dönüşümlerin ölçümü ve sipariş sonrası operasyon kalitesiyle değerlendirilmelidir.
Doğru entegrasyon kapsamı nasıl belirlenir?
Önce veri akış diyagramı çıkarılır; ardından sistem sahipleri, kayıt kimlikleri, hata senaryoları ve servis seviyesi belirlenir. “ERP entegrasyonu” gibi tek satırlık bir kapsam, hangi verinin ne zaman ve hangi kuralla taşınacağını açıklamaz. Teknik keşif sırasında örnek kayıtlar, API limitleri, güvenlik yöntemi ve geri dönüş planı birlikte incelenmelidir.
Hazır bağlayıcının yeterli olduğu projeler de, özel ara katman gerektiren projeler de vardır. Karar; kanal sayısı, işlem hacmi, veri sahipliği ve hata toleransına göre verilmelidir. Uygulama kapsamını değerlendirmek için e-ticaret kurulum ve yönetimi hizmet sayfası sonraki adım olabilir; ancak sağlıklı teklif için önce veri ve durum sözleşmesinin netleştirilmesi gerekir.
Kaynak kontrolü: 16 Ekim 2026. Kapak, konuyu açıklamak için yapay zekâ desteğiyle üretilmiş kavramsal bir illüstrasyondur; gerçek ürün ekranı veya ölçüm sonucu değildir.
