E‑Ticaret Entegrasyonu ile Sipariş Otomasyonu

06.11.2025

E-ticaret entegrasyonu: sistemler arası bağlantı ve otomasyon

E‑ticaret entegrasyonu; mağaza ve pazar yerlerindeki sipariş, ürün, stok ve gönderi verilerinin ERP, OMS, WMS ve taşıyıcı sistemleri arasında tanımlı kurallarla aktarılmasıdır. Sipariş otomasyonu ise bu veri akışının belirli adımlarını tekrar eden manuel girişe gerek kalmadan çalıştırır.

Ancak bir API bağlantısının kurulması, siparişlerin her koşulda “anında ve hatasız” işleneceği anlamına gelmez. Yanlış SKU eşlemesi, yinelenen bildirim, sırası değişen olaylar, eski stok verisi veya başarısız durum güncellemesi otomasyonla daha hızlı yayılabilir. Sağlam bir entegrasyon; yalnız sistemleri bağlamaz, veri sahibini, kimlikleri, geçerli durum geçişlerini, hata telafisini ve ölçüm yöntemini de tanımlar.

Bu rehber, e‑ticaret sipariş entegrasyonunu ticari vaatlerden ziyade operasyonel kontrol açısından ele alır. Amaç; hangi işin otomatikleşebileceğini, hangi kararın insanda veya ana sistemde kalması gerektiğini ve entegrasyonun nasıl güvenilir biçimde işletileceğini açıklamaktır. Siparişin depo içindeki fiziksel yolunu ayrıca fulfillment süreci rehberinde inceleyebilirsiniz.

E‑ticaret entegrasyonu neyi otomatikleştirir ve hangi sistemleri bağlar?

Tipik bir e‑ticaret operasyonunda aynı siparişin farklı parçaları birden fazla sistemde yaşar:

Mağaza veya pazar yeri: Sepet, ödeme, kanal sipariş kimliği, müşteri talebi ve kanalın kendi durumları
ERP: Ticari ürün kartı, muhasebe, fatura ve satın alma gibi şirket kayıtları
OMS veya entegrasyon katmanı: Kanal verisini ortak modele dönüştürme, sipariş yönlendirme, iş kuralları ve geri bildirim
WMS: Fiziksel stok, lokasyon, tahsis, toplama, paketleme ve sevk hareketleri
Taşıyıcı sistemi: Etiket veya takip numarası, fiziksel kabul taraması, taşıma ve teslimat olayları

Her işletmede ayrı bir OMS bulunması gerekmez; bazı yapılarda ERP veya WMS entegrasyon katmanının bir bölümünü üstlenebilir. Shopify’ın resmi OMS rehberi de dış OMS, hibrit ve platform merkezli farklı mimarilerin mümkün olduğunu; ana kayıt sistemi (system of record) seçiminin mimariye göre değiştiğini gösterir. Bu modeller evrensel reçete değil, farklı sorumluluk dağılımlarına örnektir. Order management for enterprise

Doğru kurulduğunda entegrasyon; sipariş verisini içe alabilir, ürün kimliğini eşleyebilir, işlenebilirlik kontrolü yapabilir, WMS görevi oluşturabilir, stok veya durum bilgisini kanala geri yazabilir ve taşıyıcı verisini sipariş kaydıyla ilişkilendirebilir. Fakat entegrasyon tek başına:

Eksik veya yanlış ürün ana verisini düzeltmez.
Fiziksel stok ile sistem kaydının eşit olduğunu garanti etmez.
Hangi siparişin risk, ödeme veya müşteri kuralı nedeniyle bekletileceğine kendiliğinden karar vermez.
Etiket üretildiğinde paketin taşıyıcıya teslim edildiğini kanıtlamaz.
Taşıyıcının son müşteriye teslim süresini kontrol etmez.

E‑iş teknolojileri üzerine yapılan araştırmalar, performans faydasının yalnız teknolojinin varlığından değil, süreç ve bilgi entegrasyonundan doğduğunu gösteriyor. Tedarik zinciri entegrasyonuna ilişkin meta-analiz de genel olarak olumlu bir ilişki bulsa da sonuçların entegrasyon türüne ve bağlama göre değiştiğini belirtiyor. Bu nedenle “entegrasyon kesin olarak maliyeti düşürür” yerine, doğru tasarımın manuel tekrarları azaltabileceği ve süreci ölçülebilir hâle getirebileceği söylenmelidir. Devaraj, Krajewski ve Wei · Leuschner, Rogers ve Charvet

Veri sahibi ve entegrasyon sözleşmesi nasıl belirlenir?

Entegrasyon tasarımının ilk sorusu “Hangi API’yi kullanacağız?” değil, “Hangi alanın doğru ve yetkili kaynağı hangi sistem?” olmalıdır. Aynı veriye iki sistemin bağımsız biçimde sahip çıkması, özellikle stok ve durumlarda yarış koşulu yaratır.

Alan bazında bir sahiplik matrisi hazırlanmalıdır:

Ticari sipariş ve ödeme durumu: satış kanalı veya yetkilendirilmiş OMS
İç ürün kimliği ve barkod: kararlaştırılan ürün ana veri sistemi
Fiziksel eldeki, bloke ve tahsisli stok: WMS
Kanala yayımlanan satılabilir miktar: tanımlanmış hesaplama kuralı ve tek yayınlayıcı
Toplama, paketleme ve sevke hazır durumu: WMS
Taşıyıcı kabulü, taşıma ve teslimat olayı: taşıyıcı
Müşteri bildirimi: kanalın veya sözleşmede belirlenen iletişim sisteminin davranışı

Ardından yazılı bir veri sözleşmesi oluşturulur. Bu sözleşme alan adlarını, veri tiplerini, zorunlu alanları, tarih ve saat dilimini, miktar birimini, para birimini, durum değerlerini, kimlikleri, sürüm bilgisini ve hata yanıtlarını kapsar. Bir orderId alanının varlığı yeterli değildir; hangi mağazada benzersiz olduğu ve sipariş, paket ya da fulfillment kaydını mı temsil ettiği de açıklanmalıdır.

HTTP API sözleşmelerini insan ve makine tarafından okunabilir biçimde tanımlamak için OpenAPI gibi standartlar kullanılabilir. Belge tek başına entegrasyonu güvenilir yapmaz; fakat şema değişikliği, kabul testi ve taraflar arası sorumluluk için ortak bir referans sağlar. OpenAPI Specification

Sipariş, SKU, satır ve paket kimlikleri nasıl eşleştirilir?

Müşteriye gösterilen sipariş numarası, teknik olarak güvenilir tekil anahtar olmayabilir. Aynı numara farklı mağazalarda tekrar edebilir; sipariş bölündüğünde birden fazla paket oluşabilir veya bir sipariş satırı kısmen karşılanabilir. Güvenli iş anahtarı çoğu durumda şu bileşenleri içerir:

kanal + mağaza/satıcı hesabı + kaynak sipariş kimliği

Bunun yanında şu kimlikler ayrı alanlarda saklanmalıdır:

Kaynak sipariş kimliği ve müşteriye gösterilen sipariş numarası
Sipariş satırı kimliği
Kaynak ürün, varyant ve SKU değeri
WMS iç ürün ve sipariş kimliği
Paket veya gönderi (shipment) kimliği
Fulfillment kaydı
Taşıyıcı takip numarası veya barkodu

Ürün eşleme yalnız iki SKU metnini yan yana koymak değildir. Varyant, ürün seti (bundle) içeriği, koli içi adet, satış birimi, barkod, ölçü-ağırlık ve gerekiyorsa lot/seri kuralları da tanımlanır. Eşlenmemiş bir SKU geldiğinde otomatik olarak benzer ürüne yönlendirmek yerine siparişi kontrollü istisna kuyruğuna almak daha güvenlidir.

Shopify’ın kurumsal OMS rehberinde global id kararlı ve benzersizken mağaza tarafından biçimlendirilen name ve sayısal number alanlarının benzersiz olmayabileceği belirtilir. Trendyol sipariş paketlerinde de sipariş, paket ve durum kavramları ayrı izlenir; örneğin paket bölme veya durum değişikliği yalnız görünen sipariş numarasıyla yönetilemez. Order management for enterprise · Trendyol sipariş paketleri

Webhook, polling ve mutabakat birlikte nasıl kullanılmalıdır?

Sipariş verisi üç temel yöntemle taşınabilir:

Webhook veya bildirim: Kaynak sistem bir olay olduğunda entegrasyon adresine mesaj gönderir. Gecikmeyi azaltabilir ve gereksiz sorguyu sınırlar.
Polling: Entegrasyon belirli aralıklarla API’yi sorgular. Webhook bulunmayan alanlarda, kaçan veriyi tamamlarken veya kontrollü artımlı okumada kullanılır.
Dosya aktarımı: CSV, XML, SFTP veya benzeri toplu akışlar; eski sistemlerde, yüksek hacimli toplu (batch) işlemlerde veya API bulunmadığında tercih edilebilir.

En güvenilir model çoğu zaman hibrittir: webhook düşük gecikmeli sinyal verir, API kaydın güncel ayrıntısını getirir, periyodik mutabakat ise kaçırılmış veya yanlış işlenmiş kayıtları bulur. Shopify, webhook sıralamasını garanti etmediğini ve webhook teslimatına tek başına güvenilmemesi gerektiğini açıkça belirtir. Eski bir olay daha yeni olaydan sonra gelebileceği için kaynak zaman damgası ve mevcut kayıt sürümü dikkate alınmalıdır. Shopify webhooks

WooCommerce; sipariş, ürün ve müşteri gibi kaynaklar için webhook konuları, imza başlığı ve teslimat logları sunar. Trendyol da sipariş paketi durumları için webhook modeli sağlar. Bu örnekler aynı kavramı kullansa da kimlik doğrulama, mesaj gövdesi (payload), tekrar davranışı ve desteklenen olaylar platforma göre farklıdır. WooCommerce webhooks · Trendyol webhook modeli

Webhook’a verilen başarılı HTTP yanıtı, mesajın entegrasyon tarafından kabul edildiğini gösterebilir; siparişin depoda toplandığını veya gönderildiğini göstermez. Mesaj mümkün olduğunca hızlı doğrulanıp dayanıklı bir kuyruğa alınmalı, uzun süren iş kuralları daha sonra çalıştırılmalıdır.

Sipariş doğrulaması ve ortak durum modeli nasıl kurulur?

Kanaldan gelen her sipariş doğrudan toplama görevine dönüşmemelidir. Önce siparişin işlenebilir olup olmadığı kontrol edilir:

Kaynak sipariş ve satır kimlikleri mevcut mu?
Sipariş durumu fulfillment için uygun mu?
Gerekli ödeme, risk veya kanal onayı tamam mı?
SKU ve miktarlar eşlenmiş mi?
Geçerli teslimat ve iletişim bilgileri var mı?
Yeterli kullanılabilir stok bulunuyor mu?
Paketleme ve taşıyıcı kuralları tanımlı mı?

Kaynak platformların durumları birbirine kelime kelime çevrilmemelidir. Ortak bir iç model kurulup kaynak durum ayrıca korunabilir. Örneğin iç akış alındı → doğrulama bekliyor → işlenebilir → beklemede → tahsis edildi → toplanıyor → paketlendi → sevke hazır → taşıyıcıya devredildi → teslim edildi / iptal / istisna biçiminde olabilir. Bu yalnız örnek bir modeldir; gerçek geçişler müşterinin kanal ve operasyon kurallarına göre belirlenir.

Trendyol dokümantasyonunda Awaiting durumundaki siparişlerin Created durumuna geçmeden fulfillment işlemine alınmaması gerektiği özellikle belirtilir. Shopify dokümantasyonu da ödeme ile fulfillment durumunun teknik olarak bağımsız olabileceğini gösterir. Dolayısıyla “sipariş oluştuğu anda WMS’e otomatik salınır” genellemesi doğru değildir. Trendyol sipariş paketleri · Order management for enterprise

Yinelenen işlemler ve eşzamanlı güncellemeler nasıl yönetilir?

Dağıtık sistemlerde aynı bildirim birden fazla kez gelebilir veya API yanıtı kaybolduğu için istemci aynı isteği yeniden gönderebilir. Hedef, “mesaj yalnız bir kez gelir” varsayımı değil, aynı mesaj tekrarlandığında aynı iş sonucunu üretmek olmalıdır. Bu davranış idempotency olarak adlandırılır.

Uygulamada:

Kaynak olay veya teslimat kimliği kaydedilir.
Sipariş oluşturma için kanal, mağaza ve kaynak sipariş kimliğinden benzersiz iş anahtarı üretilir.
Aynı olay yeniden gelirse ikinci sipariş ya da ikinci stok hareketi oluşturulmaz.
Varsa kaynak sıra veya sürüm numarası; yoksa kaynak zaman damgası ile geçerli durum geçiş kuralları, daha eski bir olayın yeni durum üzerine yazmasını engeller.
Başarılı iş sonucu ile dış sisteme gönderilecek olay arasında kopukluk oluşmaması için gerekirse işlem kaydıyla olay yayınını birlikte güvenceye alan transactional outbox deseni kullanılır.

HTTP standardında PUT, DELETE ve güvenli yöntemler protokol düzeyinde aynı sonuçlu (idempotent) kabul edilir; POST tabanlı bir sipariş oluşturma işlemi ise kendiliğinden güvenli tekrar edilebilir değildir. Uygulamanın iş anahtarı veya desteklenen idempotency anahtarıyla bu davranışı sağlaması gerekir. RFC 9110 – Idempotent Methods

Shopify webhook rehberi, HMAC kontrolünün yanında teslimat kimliğiyle yinelenen mesajların ayıklanmasını önerir. Veritabanı işlemi ile olay yayınlama arasındaki tutarsızlık riskini azaltmak için kullanılan transactional outbox deseni de AWS tarafından ayrıntılı biçimde açıklanır. Shopify webhooks · Transactional outbox pattern

Stok senkronizasyonu ve tahsis mantığı nasıl ayrılır?

“Stok” tek sayı değildir. Fiziksel eldeki miktar, satılabilir miktar, siparişe tahsis edilmiş miktar, hasarlı veya bloke stok, yoldaki ürün ve güvenlik stoğu farklı anlamlara gelir. Shopify’ın resmi stok durumları da on hand, available, committed, unavailable ve incoming miktarlarını ayrı tanımlar. Understanding inventory states

Fulfillment entegrasyonunda çoğu durumda WMS fiziksel stok hareketlerinin ana kaynağıdır. Satış kanalına ise iş kuralıyla hesaplanan satılabilir miktar gönderilir. Bu hesap:

Fiziksel stoktan tahsisli ve bloke miktarı ayırabilir.
Kanal bazında güvenlik payı uygulayabilir.
Birden fazla mağazanın aynı havuzu kullanmasını dikkate alabilir.
İade kabul edilen ürünü kalite kararı verilmeden satılabilir stoğa katmayabilir.

Mutlak değer ile delta güncellemesi karıştırılmamalıdır. Tek kaynak WMS ise güncel mutlak miktar yayımlanabilir; birden fazla yazan sistem varsa sürüm veya compare-and-set kontrolü gerekir. Delta hareketler kullanılıyorsa her hareket benzersiz kimlikle yalnız bir kez uygulanmalıdır. Shopify inventorySetQuantities işlemi de mutlak değer yazımını ana kayıt sistemi (system of record) senaryosuyla sınırlar ve eşzamanlı değişikliklere karşı karşılaştırma mekanizması sunar. inventorySetQuantities

Bilgi sistemi kaydı ile fiziksel stok arasındaki fark, e‑perakende ve B2B operasyonlarında da gerçek bir problemdir. Bu nedenle senkronizasyon başarısı yalnız API’nin 200 dönmesiyle değil, kanal ve WMS miktarlarının periyodik mutabakatıyla ölçülmelidir. Inventory inaccuracies in e‑retailing/B2B contexts

Fiziksel sayım, güvenlik stoğu ve stok politikalarını stok yönetimi rehberinde daha ayrıntılı ele alıyoruz.

İptal, adres değişikliği, eksik stok ve kısmi sevk nasıl yönetilir?

Sipariş oluşturulduktan sonra yeni olaylar gelebilir. İptal, adres değişikliği, ürün çıkarma, miktar değişikliği, eksik stok veya siparişin birden fazla pakete bölünmesi normal entegrasyon senaryolarıdır; yalnız “hata” olarak görülmemelidir.

Her değişiklik için karar noktası tanımlanmalıdır:

Sipariş henüz tahsis edilmediyse hangi alanlar otomatik güncellenebilir?
Toplama başladıktan sonra iptal geldiğinde görev nasıl durdurulur?
Paket kapandıysa adres değişikliği yeni etiket gerektirir mi?
Bir satır eksikse sipariş bekletilecek, kısmi gönderilecek veya iptal mi edilecek?
Paket bölündüğünde kanal, WMS ve taşıyıcıda hangi kimlikler korunacak?
İptal sonrası ayrılmış stok ne zaman yeniden satılabilir olur?

Bu kurallar kanalın izin verdiği işlemlerle müşterinin ticari politikasını birlikte yansıtmalıdır. Eski bir durumun yeni durumu geriye çevirmesine izin verilmemeli; fiziksel operasyonda geri alınamayacak bir aşamaya gelindiyse kayıt müşteri hizmetleri veya operasyon incelemesine düşmelidir.

İade, iptal ile aynı olay değildir. Müşteriye gitmiş veya geri dönmüş ürünün fiziksel kabul, kontrol ve stok kararı ayrı bir ters lojistik akışıdır. Ayrıntılı model için ters lojistik ve iade yönetimi rehberine bakabilirsiniz.

Fulfillment durumu ve takip bilgisi kanala nasıl yazılır?

Kargo etiketi entegrasyonu genellikle WMS veya OMS’nin taşıyıcı ya da pazar yeri servisinden etiket istemesiyle başlar. Dönen paket kimliği, barkod, takip numarası, servis ve etiket dosyası doğru sipariş ile ilişkilendirilir. Bu kayıtta üç olay birbirinden ayrılmalıdır:

Etiket üretildi: Taşıyıcı veya kanal bir etiket/takip kimliği verdi.
Taşıyıcıya devredildi: Paket fiziksel olarak teslim edildi ve depo devri kaydetti.
Taşıyıcı kabul etti: Taşıyıcı ağı ilk kabul taramasını üretti.

Etiket üretmek gönderiyi “teslim edildi” veya hatta her zaman “kargoya verildi” yapmaz. Kanala yazılacak durum, kanala özgü kurala ve doğrulanmış olay kaynağına dayanmalıdır. Amazon’ın resmi bildirim listesinde genel sipariş değişiklikleri için ORDER_CHANGE, Multi-Channel Fulfillment siparişleri için ise FULFILLMENT_ORDER_STATUS gibi ayrı olay tipleri bulunması, tek bir shipped alanının bütün yaşam döngüsünü temsil edemeyeceğine iyi bir örnektir. Bu kaynak bir Memnun Depo platform desteği iddiası değil, olay modelleme örneğidir. Amazon Notification Type Values

Müşteri bildirimi de ayrı bir ayardır. Bazı kanallar takip bilgisi yazıldığında bildirim gönderebilir; bazılarında ayrıca bildirim seçeneği veya farklı akış gerekir. “Takip numarası üretildi ve müşteriye ulaştı” tek işlem gibi raporlanmamalıdır.

Taşıyıcının ağ içi hareketleri ve son müşteriye teslimatı depo entegrasyonunun kontrol alanı dışındadır. Bu ayrımı son mil lojistiği rehberinde ele alıyoruz.

Hata, yeniden deneme ve manuel müdahale kuyruğu nasıl kurulmalıdır?

Her hata aynı şekilde yeniden denenmemelidir. Önce neden sınıflandırılır:

Geçici teknik hata: Timeout, bağlantı kesintisi, uygun 5xx veya servis meşguliyeti
Servis limiti: 429 veya platformun kota uyarısı
Yetki sorunu: Süresi dolmuş token, yanlış scope veya iptal edilen erişim
Veri sorunu: Eşlenmemiş SKU, eksik adres, hatalı miktar veya bilinmeyen durum
İş kuralı sorunu: İptal edilmiş siparişte sevk talebi, izin verilmeyen durum geçişi veya stok yetersizliği

Geçici hatalar sınırlı sayıda, kademeli bekleme ve rastgele sapma (jitter) ile yeniden denenebilir. Aynı anda binlerce kaydı tekrar göndermek dış servisteki sorunu büyütebilir. Amazon SP‑API kullanım planları limitlerin operasyon ve hesaba göre değişebileceğini belirtir; AWS’nin rehberi de zaman aşımı, sınırlı yeniden deneme, kademeli bekleme (exponential backoff) ve jitter yaklaşımını açıklar. SP‑API usage plans and rate limits · Timeouts, retries and backoff with jitter

Kalıcı veri ve yetki sorunları otomatik tekrar döngüsünde tutulmamalıdır. Denemeleri tükenen kayıt; sipariş kimliği, hata nedeni, son deneme zamanı ve sorumlu ekiple birlikte manuel müdahale kuyruğuna alınır. Düzeltildikten sonra kontrollü yeniden işletme (replay) yapılır.

Mutabakat görevi ise kaynak sistemdeki siparişleri ve güncellemeleri belirli zaman aralığında yeniden okuyarak şu soruları cevaplar: Kaynakta olup WMS’te olmayan sipariş var mı? WMS’te hazırlanmış fakat kanala yazılmamış gönderi var mı? Stok veya durum eski mi? Bu kontrol, webhook ve retry mekanizmasının alternatifi değil güvenlik ağıdır.

Servis limitleri, sayfalama ve trafik kontrolü nasıl planlanır?

API kapasitesi sınırsız değildir. Platformlar endpoint, uygulama, mağaza veya hesap bazında farklı rate limit uygular; limitleri ve sürümleri zaman içinde değiştirebilir. Bu nedenle sabit bir “dakikada şu kadar sipariş” varsayımı mimariye gömülmemelidir.

Entegrasyon şu kontrollere ihtiyaç duyar:

İstekleri kuyruk üzerinden dengeli gönderme
Sunulduğunda Retry-After başlığına ve platformun kullanım metriklerine uyma
Sayfa veya devam işaretçisi (cursor) bilgisini kaybetmeden sürdürme
Büyük tarih aralıklarını artımlı pencerelere bölme
Toplu senkronizasyon ile günlük operasyon trafiğini önceliklendirme
Yoğun kampanya sırasında akış baskılama (backpressure) uygulama
Son başarılı senkronizasyon noktasını kalıcı saklama

Shopify, API türüne göre farklı limit yöntemleri kullanır ve uygulamaların kota kullanım durumunu okuyarak sorumlu biçimde yeniden denemesini önerir. Trendyol’un sipariş paketi dokümantasyonu da kayıt penceresi, sayfalama ve yüksek hacimli sorgularla ilgili güncel sınırlar yayımlar; periyodik tarama ve yüksek hacimli senkronizasyon için sayfa tabanlı uç nokta yerine cursor tabanlı akış uç noktasını önerir. Sonuç olarak entegrasyon, tek bir platformun bugünkü limitine değil değişebilir kapasite sözleşmesine ve güncel endpoint yönlendirmesine göre tasarlanmalıdır. Shopify API limits · Trendyol sipariş paketleri · Trendyol cursor tabanlı sipariş akışı

Kimlik doğrulama, yetki ve kişisel veri nasıl korunur?

Sipariş entegrasyonu ad, adres, telefon ve e‑posta gibi kişisel verilerle ürün ve ödeme durumu gibi operasyonel verileri taşıyabilir. Güvenlik yalnız API anahtarını bir .env dosyasına koymak değildir. Asgari çerçeve şunları içermelidir:

HTTPS/TLS ve platformun desteklediği güncel kimlik doğrulama yöntemi
Yalnız gerekli kaynaklara erişen en düşük yetki ve scope
Webhook imzası veya HMAC doğrulaması
Token ve secret’ların güvenli saklanması, rotasyonu ve iptali
Gelen üçüncü taraf verisinin şema ve iş kuralı açısından doğrulanması
Loglarda adres, telefon, e‑posta, token ve ham mesaj gövdesinin maskelenmesi
Replay, manuel düzeltme ve yönetici işlemlerinde rol bazlı erişim
Veri saklama, silme ve ihlal müdahale prosedürü

OWASP, güvenilir görünen üçüncü taraf API verisinin doğrulanmadan tüketilmesini ayrı bir güvenlik riski olarak ele alır. Shopify da teslimat işlenmeden önce ham istek gövdesi üzerinden imza doğrulaması ve yinelenen teslimat kontrolü önerir. OWASP – Unsafe Consumption of APIs · Shopify webhooks

KVKK’ya göre veri sorumlusu, kişisel verinin hukuka aykırı işlenmesini ve erişimini önlemek ile muhafazasını sağlamak için uygun teknik ve idari tedbirleri almak zorundadır. Verinin bir hizmet sağlayıcı tarafından işlenmesi bu sorumlulukların sözleşme, erişim ve denetim boyutunu ortadan kaldırmaz. KVKK veri güvenliği yükümlülükleri

Entegrasyon nasıl izlenir ve denetlenir?

“Entegrasyon çalışıyor” bilgisi yalnız sunucunun ayakta olmasıyla ölçülemez. Sipariş akışının teknik ve operasyonel sinyalleri birlikte izlenmelidir:

Gelen webhook veya bildirim (notification) sayısı
Son başarılı sipariş alma ve geri yazım zamanı
Olay yaşı ve kuyruk bekleme süresi
Başarılı, başarısız ve yeniden denenmiş mesaj sayısı
Engellenen yinelenen olaylar
Eşlenmemiş SKU ve doğrulama bekleyen siparişler
WMS ile kanal arasındaki stok ve durum farkları
Manuel müdahale kuyruğunun yaşı
Başarısız etiket veya takip bilgisi geri yazımları

Log, metrik ve dağıtık iz (trace) farklı sorulara yanıt verir. Ortak korelasyon alanları; kanal, mağaza, kaynak sipariş, satır, paket ve olay kimliği olmalıdır. Kişisel veriler korelasyon anahtarı olarak kullanılmamalıdır. OpenTelemetry bu sinyalleri ortak bir gözlemlenebilirlik çerçevesinde ele alır. OpenTelemetry signals

Denetim izi yalnız geliştiriciye yönelik teknik log değildir. “Bu sipariş neden bekledi?”, “Stok hangi olayla değişti?”, “Durum kanala ne zaman ve hangi yanıtla yazıldı?” sorularının tarih, kaynak ve sorumlu ile cevaplanabilmesi gerekir. Böylece performans sorunu ile veri hatası birbirinden ayrılabilir.

Sürüm değişiklikleri, test ve kontrollü canlıya geçiş nasıl yönetilir?

API entegrasyonu tek seferlik kurulum değil, bakımı gereken bir ürün yaşam döngüsüdür. Platformlar alanları, kimlik doğrulama yöntemlerini, sayfalama yapısını ve sürümleri değiştirebilir. Trendyol changelog’u gibi resmi değişiklik kanalları bu nedenle düzenli izlenmelidir. Trendyol changelog

Canlıya geçmeden önce normal akışın yanında istisnalar da test edilmelidir:

Yeni sipariş ve aynı siparişin yinelenen bildirimi
Olayların sırası değiştiğinde güncel durumun korunması
Eşlenmemiş SKU, eksik adres ve yetersiz stok
Toplama öncesi ve toplama sonrası iptal
Kısmi sevk, paket bölme ve birden fazla takip numarası
Webhook kesintisi ve API ile kaçan veriyi tamamlama
Rate limit, timeout ve geçici servis hatası
Etiket üretim hatası ve kanala durum yazamama
Token süresinin dolması veya yetkinin kaldırılması
Eski sürümden yeni sürüme şema değişikliği

Platform test ortamı (sandbox) sağlıyorsa kullanılmalı; sağlamıyorsa kontrollü test hesabı, sınırlı SKU ve açıkça işaretlenmiş test siparişleriyle ilerlenmelidir. Önce tek mağaza veya sınırlı trafikle pilot yapılmalı, eski ve yeni akış sonuçları karşılaştırılmalı, geri dönüş ve yeniden işletme prosedürü doğrulanmalıdır.

Fiziksel el terminali, konveyör veya robotik gibi depo otomasyonu bu yazının kapsamından farklıdır. Bu yatırımlar için otomasyonlu sipariş karşılama rehberine; WMS ve teknoloji seçimi için fulfillment teknolojileri rehberine bakabilirsiniz.

E‑ticaret entegrasyonu hangi KPI’larla ölçülmelidir?

Tek bir “entegrasyon başarı oranı” bütün resmi göstermez. Her KPI için başlangıç ve bitiş olayı, payda, hariç tutulan kayıtlar, dönem ve sorumlu taraf yazılmalıdır.

Önerilen ölçümler:

Sipariş içe alma başarı oranı
Kaynakta oluşma ile WMS’e doğrulanmış kayıt arasındaki gecikme; medyan ve yüksek yüzdelikler
Mükerrer sipariş veya stok hareketi engelleme sayısı
Eşlenmemiş SKU ve doğrulama hatası oranı
Manuel müdahale gerektiren sipariş oranı
Başarısız ve yeniden denenmiş API işlemi oranı
Denemeleri tükenen kayıt sayısı ve çözüm süresi
Kanal ile WMS stok mutabakat farkı
Fulfillment durumu ve takip bilgisi geri yazım başarı oranı
Kaynakta olup hedefte bulunmayan kayıt sayısı
Son başarılı senkronizasyondan beri geçen süre
Entegrasyon kaynaklı operasyon bekleme süresi

Sonuçlar mağaza, kanal, hata sınıfı ve sipariş profiline göre ayrıştırılmalıdır. Ortalama gecikme tek başına yoğun kampanyadaki kuyrukları gizleyebilir; medyan ve yüksek yüzdelikler birlikte izlenebilir. Ölçülmemiş bir “%100 senkronizasyon” veya evrensel sektör kıyas ölçütü (benchmark) yayımlanmamalıdır.

Memnun Depo’nun doğrulanmış entegrasyon kapsamı nedir?

Memnun Depo’nun doğrulanmış entegrasyon çerçevesi; standart kurulum süresini ve teknik erişimi bulunan sistemlerde ek kurulum veya geliştirme ücreti alınmamasını kapsar. Hangi mağaza, pazar yeri ya da taşıyıcı sisteminde hangi veri alanlarının bağlanabileceği; güncel API kapsamı, yetkiler ve müşteri iş kurallarıyla proje başlangıcında doğrulanır. Bu nedenle bütün platform ve özellikleri kapsayan genel bir destek vaadi verilmez.

Ücret ve süre çerçevesi şöyledir:

Gerekli teknik erişim ve iş kuralları sağlandıktan sonra standart entegrasyon kurulumu 1–3 iş günüdür.
Teknik erişimi bulunan sistemlerde standart ve ihtiyaca özel entegrasyonlar için ek kurulum veya geliştirme ücreti alınmaz.
Sıfır ek ücret politikası Memnun Depo’nun kurulum ve geliştirme bedeliyle ilgilidir; varsa üçüncü taraf platform, API veya lisans ücretleri ayrıca değerlendirilir.
Pazar yeri onayı, API erişimi, değişen platform gereksinimleri veya dış sistem bürokrasisi kurulum süresini uzatabilir.
Özel entegrasyonun kapsamı ve takvimi, sistemin teknik olanakları ve iş kurallarına göre ayrıca belirlenir; bütün özel projeler için 1–3 iş günü vaadi verilmez.

İşlenebilir sipariş; geçerli sipariş bilgisi, yeterli kullanılabilir stok ve tanımlı paketleme kuralı bulunan sipariştir. İşlenebilir siparişleri sisteme alındıktan sonra en geç 12 saat içinde toplar, paketler ve sevke hazırlarız. Taşıyıcının paketi teslim alma zamanı, ağ içi taşıma ve son müşteriye teslim süresi bu operasyon sözünün dışındadır.

Örnek bağlantıları görmek ve proje kapsamını görüşmek için entegrasyonlar sayfasını inceleyebilir; kendi sipariş, SKU ve paketleme profiliniz için entegrasyon talebi oluşturabilirsiniz. Sayfadaki örnekler, teknik doğrulama yapılmadan bütün özelliklerin otomatik olarak desteklendiği anlamına gelmez.

E‑ticaret entegrasyonu hakkında sık sorulan sorular

E‑ticaret sipariş entegrasyonu nedir?

Mağaza veya pazar yerindeki sipariş verisinin tanımlı kimlik, alan ve durum kurallarıyla OMS, ERP ya da WMS’e aktarılması; fulfillment ve takip bilgilerinin de izin verilen kapsamda kanala geri yazılmasıdır. Yalnız siparişi kopyalamak değil, iki yönlü veri ve hata yönetimi sürecidir.

API ile webhook arasındaki fark nedir?

API genellikle bir sistemin diğerinden veri istemesini veya işlem talep etmesini sağlar. Webhook ise belirli bir olay oluştuğunda kaynak sistemin hedefe bildirim göndermesidir. Güvenilir akışta webhook, API ile ayrıntı okuma ve periyodik mutabakat birlikte kullanılabilir.

Gerçek zamanlı stok senkronizasyonu mümkün müdür?

Düşük gecikmeli güncelleme mümkündür; ancak ağ, kuyruk, rate limit ve hata nedeniyle mutlak sıfır gecikme garanti edilemez. Daha önemli olan; satılabilir stok tanımının doğru olması, gecikmenin ölçülmesi ve WMS ile kanalların düzenli mutabakatıdır.

Entegrasyon mükerrer siparişi tamamen önler mi?

Kaynak olay kimliği, benzersiz iş anahtarı ve idempotent işlem tasarımı mükerrer kayıt riskini önemli ölçüde kontrol eder. Fakat bu kontroller uygulanmazsa webhook veya retry aynı siparişi birden fazla kez işleyebilir.

Entegrasyon kurulumu ne kadar sürer?

Memnun Depo’da gerekli teknik erişim ve iş kuralları teslim edildikten sonra standart kurulum 1–3 iş günüdür. Platform onayı, API erişimi, bürokrasi veya özel geliştirme kapsamı toplam takvimi uzatabilir.

Özel entegrasyon gerçekten ücretsiz mi?

Teknik erişimi bulunan sistemlerde standart ve ihtiyaca özel entegrasyon için Memnun Depo ek kurulum veya geliştirme ücreti almaz. Üçüncü taraf platform, API ve lisans ücretleri bu kapsama dahil değildir.

Entegrasyona başlamak için hangi bilgiler gerekir?

Mağaza ve kanal listesi, teknik erişimler, SKU ve varyant eşlemeleri, stok sahipliği, işlenebilir sipariş statüleri, iptal ve kısmi sevk kuralları, paketleme profili, taşıyıcı akışı, beklenen hacim ve test yetkilileri gerekir. Bu bilgiler netleşmeden yalnız API anahtarı paylaşmak yeterli değildir.

Kaynaklar ve ileri okuma

Bu makale entegrasyon mimarisi ve operasyonları hakkında genel bilgi sunar. Platform API’leri, sürümler, servis limitleri, veri koruma gereklilikleri ve taşıyıcı hizmetleri değişebilir. Her uygulama güncel resmî dokümantasyon ve müşteriye özgü iş kurallarıyla ayrıca doğrulanmalıdır.