API Entegrasyonu: İşletmeler İçin Rehber

“Mağazayı CRM’e bağlayalım” geliştirme için yeterli kapsam değildir. CRM ve e-ticaret entegrasyonunda hangi olayın hangi kaydı oluşturacağı veya değiştireceği belirlenir. Yeni sipariş, müşteri güncellemesi ve iptal farklı işlemlerdir; her biri için kabul koşulu gerekir.

Örnek başlangıç kuralı şöyle olabilir: CRM’de onaylanan kurumsal teklif, ERP’de taslak sipariş oluştursun. Fatura kesme ve tahsilat bu pilotun dışında kalsın. Teklif kimliği, onay durumu, müşteri kodu ve tutar aktarılır; eksik müşteri kodu işlemi bekletir. Kimin onay vereceği ve kabul edilebilir gecikme işletmeyle belirlenir. Onay geri çekildiğinde taslak siparişin ne olacağı da aynı sözleşmeye eklenir.

API, bir sistemin başka yazılımlarla işlem yapmasını sağlayan arayüzdür. Entegrasyon ise işletmenin bu arayüzle çalışan bağlantısı ve kurallarıdır. Kullanılabilir API bulunması gerekli işlemlerin tamamının açık olduğu anlamına gelmez. Resmi belge, hesap yetkisi ve örnek erişim doğrulandıktan sonra teklif kapsamı netleştirilir.

ERP ve mağaza entegrasyonu kontrol listesi ile her alan için kaynak, hedef ve güncelleme yönü belirlenebilir. Aynı müşterinin iki sistemde farklı adresi varsa hangisinin geçerli olduğu bir iş kararıdır. Alan adını kopyalamak bu kararı çözmez.

Eşleme dosyası kayıt kimliği, zorunlu alan, boş değer ve dönüşüm kuralını içerir. Görünen şirket adı yerine kararlaştırılmış müşteri kodu kullanın; ad değişikliği yeni müşteri yaratmamalıdır. Vergi dahil ve hariç tutarlar, para birimi ve saat dilimi örnek kayıtta ayrı kontrol edilir. İki sistemde de aynı adlı alan bulunması, anlamlarının aynı olduğunu kanıtlamaz.

Geçmiş kayıtların ilk aktarımıyla yeni kayıtların sürekli aktarımı ayrı işlerdir. Bağlantı eksik veriyi kendiliğinden düzeltmez. Temizlik sorumluluğunu ve aktarılacak kayıtları kapsamda yazın. İlk incelemede kişisel bilgi içermeyen, gerçek alan yapısını temsil eden örnek veri kullanılabilir.

Backend geliştirme kapsamında cevapsız veya tekrar gelen işlem de tasarlanır. Stripe API v1, aynı idempotency anahtarıyla tekrar edilen isteğe kaydettiği sonucu döndürür; bunun kapsamı başka API’ye varsayılamaz. Shopify ise yinelenen webhook teslimlerini tanımak için teslim kimliğini belgeler. Aynı teklif olayının tekrar gelmesi ikinci ERP siparişine dönüşmemelidir.

Webhook, olay gerçekleştiğinde gönderilen bildirimdir; düzenli sorgulama ise sistemin değişiklikleri aralıklarla kontrol etmesidir. Seçimi desteklenen olay ve gecikme ihtiyacına göre yapın. Shopify’ın HTTPS teslimlerinde ham gövde üzerinden imza doğrulaması vardır; bildirimin kimden geldiğini kontrol etmekle çift işlemi önlemek ayrı görevlerdir. Diğer sağlayıcının yöntemi kendi belgesinden doğrulanır.

Geçici bağlantı sorunu yeniden denemeye uygun olabilir; hatalı müşteri kodu düzeltilmeden tekrar çalıştırılmaz. Kaynak ve hedef kayıt kimliği, işlem durumu ve hata nedeni izlenir. Tekrar deneme sınırıyla manuel müdahale sahibi belirlenir. Kaynakta onaylanan fakat hedefte oluşmayan teklifleri karşılaştıran mutabakat kontrolü, sessizce atlanan işlemleri bulmaya yardım eder.

Pazarlama otomasyonunda hazır bir bağlantı bazı temel akışları karşılayabilir. Ancak seçim sadece araçta iki uygulama logosunun bulunmasına göre yapılmaz. İstenen veri, işlem yönü, hata davranışı ve kullanılabilir hesap kapsamı kontrol edilir. Bir alan veya olay desteklenmiyorsa alternatif yöntem değerlendirilir.

Hazır araç teklif onayını okuyup ERP taslağı açabiliyorsa önce bu dar akışla deneyin. Yalnız kişi aktarabiliyorsa katalogdaki logolar yeterli değildir. Özel geliştirme eksik iş kuralını karşılayabilir; izleme ve bakım görevi ayrıca tanımlanır. Veri temizliği, fatura otomasyonu ve tüm geçmiş tekliflerin aktarımı başlangıç kapsamına kendiliğinden eklenmez.

Gerçek zamanlı aktarım her işte zorunlu değildir. Stok veya sipariş için kabul edilebilir gecikme işletme tarafından açıklanır. Günlük rapor aktarımıyla ödeme sonrası işlem aynı hız ihtiyacını taşımaz. Bu karar sağlayıcı limitleri, maliyet ve operasyonla birlikte verilir. Araç seçiminden önce gerekli iş davranışını tanımlamak, gereksiz sistem değişikliğini azaltabilir.

Teslim ve yayın süreci entegrasyonun üretime kontrollü taşınmasını destekleyen kapsamdır. Deneme ortamı ve test hesabı bulunup bulunmadığı sağlayıcıyla kontrol edilir. Kullanılabilir değilse hangi örneklerin nasıl güvenli sınırda deneneceği onaylanır. Gerçek sipariş veya ödeme oluşturan testlerin operasyon etkisi açık olmalıdır.

Kabul dosyası ilk onay, tutar güncellemesi, eksik müşteri kodu, tekrar olay ve bağlantı kesintisini kapsar. Her testte beklenen ERP kaydı görülür. Yanıt kaybolduğunda hedefte sipariş zaten oluşmuş olabilir; tekrar öncesi bu durum araştırılır. Aynı olayın eşzamanlı gelişi de denenir. Canlıya geçişte başlangıç verisi ve açılış anını işleten kişi belirlenir.

Bir geliştiricinin “istek başarılı” mesajı görmesi işletmenin kabulüyle aynı değildir. Hedef sistemde doğru kaydın oluştuğu ve sürecin doğru ekip tarafından kullanılabildiği doğrulanır. Testten geçen akışın hangi sınırlar içinde çalıştığı devir belgesinde korunur; doğrulanmamış işlem türleri aynı kapsamda kabul edilmez.

Çok sayıda bağlantı veya eski sistem varsa teknik liderlik desteği sorumluluk ve öncelik kararını netleştirebilir. Entegrasyonun sahibi yalnızca ilk kodu yazan kişi olarak kalmamalıdır. Sağlayıcı değişikliklerini izleyen, erişimleri yöneten ve hata durumunda karar alan ekip belirlenir.

Devir dosyası sistemleri, API sürümünü, yetki kapsamını, hata kuyruğunu ve değişiklik kontrolünü içerir. Hesap erişimi yenilendiğinde kontrol edilecek örnek işlem yazılır; anahtar değeri açık dokümana konmaz. Sağlayıcının değişiklik takvimini izleyen kişiyle işletme kuralını onaylayan kişi ayrılabilir. Destek saatleri ve kapsam dışı işlem türleri sözleşmede açıklanır.

Başlangıçta sistemleri, örnek kaydı ve belgeyi paylaşın. Çıktı, alan eşlemesi, hata kuralları, kabul örnekleri ve sorumluluk dosyası olabilir. Tekliften taslak siparişe uzanan bu pilot çalışmadan faturalama, iade veya muhasebe mutabakatının tamamı için başarı sonucu çıkarılmaz.