API nedir, ne işe yarar? Yöneticiler için entegrasyon rehberi

API (Application Programming Interface, uygulama programlama arayüzü), bir yazılımın başka bir yazılıma hangi bilgiyi hangi kurallarla verdiğini ve hangi işlemi yaptırmasına izin verdiğini tanımlayan sözleşmedir. Şirkette stok, sipariş, fatura ve ödeme bilgisinin elle kopyalanmadan bir programdan diğerine geçmesini sağlar. API entegrasyonu ise bu sözleşmeyi kullanan bağlantı yazılımının kurulmasıdır.

Arama motoruna "api nedir" yazınca ilaçtaki etken madde (API) gibi aynı harflerle yazılan başka kısaltmalar da çıkıyor; bu yazı yalnızca yazılımdaki anlamıyla ilgili. Ben Emre Aydın, UlvionTech'te kıdemli yazılım mühendisiyim ve zamanımın büyük kısmını bir iş problemi ile çalışan bir sistem arasındaki kısımda geçiriyorum: kapsam, mimari ve teslim. Bu yazıyı, "iki programımızı birbirine bağlayalım mı?" sorusuna karar verecek yöneticiler için yazdım. Teknik terimleri ilk geçtikleri yerde açıklıyorum, çünkü bir entegrasyon teklifini okuyabilmeniz bu terimlere bağlı.

API nedir, ne demek?

API (Application Programming Interface), Türkçesiyle uygulama programlama arayüzü, bir programın başka programlara açtığı kapıdır: hangi bilgiyi isteyebileceğinizi, hangi işlemi yaptırabileceğinizi ve cevabın hangi biçimde geleceğini önceden yazılı olarak belirler. MDN'nin API tanımı (yeni sekmede açılır) da bu yönde: API, bir uygulamayla insan arayüzü yerine yazılım üzerinden etkileşim kurmayı sağlayan özellik ve kurallar bütünüdür ve uygulama ile onu kullanan taraf arasında bir sözleşme gibi görülebilir. Ekranda düğmeye basan bir çalışan kullanıcı arayüzünü kullanır. Aynı işi gece yarısı kendi kendine yapan bir program ise API'yi kullanır.

Bir yöneticinin API hakkında bilmesi gereken ilk şey, API'si olan bir programın verisini başka sistemlerle paylaşmaya hazır olmasıdır. API'si olmayan bir programdan veri almak ise ekran kazıma, dosya aktarımı ya da elle giriş gibi daha kırılgan yollara kalır. Yeni bir yazılım satın alırken ya da yaptırırken ilk soracağım şeylerden biri, API'sinin olup olmadığı ve dokümanının herkese açık olup olmadığı olurdu. Ayrıca API'nin hangi işlemleri açtığına bakmak gerekir. Bazı programlar yalnızca okumaya izin verir; stoğu okuyabilirsiniz ama güncelleyemezsiniz.

API bir şirkette ne işe yarar? Stok, sipariş, fatura ve ödeme örnekleri

API bir şirkette, aynı bilginin birden fazla programa elle yazılmasını ortadan kaldırmaya yarar. Bir sipariş web sitenize düştüğünde stok programının, muhasebe programının ve kargo tarafının bundan haberdar olması gerekir; API yoksa bunu bir çalışan kopyala-yapıştırla yapar. Her elle aktarım gecikme ve yazım hatası riski taşır. Sipariş sayısı arttıkça bu iş bir kişinin gününün büyük bölümünü alabilir. API ile aynı aktarım kimse beklemeden, mesai saatinden bağımsız ve arkasında kayıt bırakarak olur.

Şirket içinde API ile taşınan tipik bilgi akışları şunlardır:

• Stok: Depo ya da stok programındaki miktarın web sitesinde, pazaryeri mağazasında ve bayi ekranında aynı anda güncellenmesi. Pazaryerlerine özgü kurallar için pazaryeri entegrasyonu rehberine bakabilirsiniz.
• Sipariş: Web sitesinden, mobil uygulamadan ya da B2B bayi portalından gelen siparişin depo ve muhasebe programına kendiliğinden düşmesi.
• Fatura: Kesinleşen siparişten faturanın muhasebe ya da fatura programında oluşturulması ve fatura numarasının siparişe geri yazılması.
• Ödeme: Ödeme kuruluşundan gelen "ödeme alındı" ya da "iade edildi" bilgisinin siparişin durumunu değiştirmesi.
• Müşteri ve iletişim: Formdan gelen talebin müşteri takip programına kaydı ve sipariş durumunun müşteriye mesajla bildirilmesi. WhatsApp tarafının ücretleri ayrı bir konu; WhatsApp Business API fiyatı yazısında ele alınıyor.
• Raporlama: Farklı programlardaki satış, stok ve tahsilat verisinin tek bir yönetim panelinde toplanması.

Sizin yerinizde olsam, bir API entegrasyonu projesini konuşmadan önce stok, sipariş, fatura ve ödeme akışlarını tek tek yazıya dökerdim: hangi bilgi, hangi programdan, hangi programa, ne sıklıkla ve kimin onayıyla gidiyor. Bu liste çıkmadan "programlarımızı entegre edelim" demek, kapsamı belirsiz bir iş istemek olur. Liste çıktığında ise akışlardan yalnızca birkaçının ciddi zaman kaybettirdiği ortaya çıkabilir ve proje küçülür.

API nasıl çalışır, REST API nedir?

API, istek ve yanıt mantığıyla çalışır: bir program belirli bir adrese, belirli bir işlem için istek gönderir, karşı taraf da sonucu ve bir durum kodunu döner. Web API'leri bu alışverişi, tarayıcınızın web sayfalarını açarken kullandığı HTTP ile yapar. Ekim 2026 itibarıyla HTTP'nin anlamını (semantics) tanımlayan güncel belge, IETF'in Haziran 2022 tarihli RFC 9110 (yeni sekmede açılır)'dur. Bu belgeye göre GET yöntemi bir kaynağın mevcut halini ister, yani okumak içindir. Kayıt eklemek, güncellemek ve silmek için POST, PUT ve DELETE gibi başka yöntemler kullanılır.

API yanıtıyla gelen durum kodu, isteğin sonucunu kısaca söyler ve entegrasyonun hata davranışı bu kodlara göre tasarlanır. RFC 9110'a göre 2xx ile başlayan kodlar başarıyı anlatır. 401, geçerli kimlik bilgisi olmadığı için isteğin uygulanmadığını; 403, sunucunun isteği anladığı halde yerine getirmeyi reddettiğini; 404, istenen kaynağın bulunamadığını gösterir. 503 ise sunucunun geçici bir aşırı yük ya da bakım nedeniyle isteği şu an karşılayamadığını anlatır. Bir yöneticinin bu kodları ezberlemesi gerekmez; önemli olan, teklif veren ekibin her birinde yazılımın ne yapacağını söyleyebilmesidir.

REST API nedir?

REST API, REST mimari tarzına uyacak şekilde tasarlanmış ve HTTP üzerinden çağrılan bir API'dir. REST (Representational State Transfer) terimini Roy Fielding, 2000 yılındaki doktora tezinin beşinci bölümünde (yeni sekmede açılır) tanımladı. MDN'ye göre REST (yeni sekmede açılır), verimli, güvenilir ve ölçeklenebilir dağıtık sistemler ortaya çıkaran bir grup tasarım kısıtıdır. MDN aynı yerde, HTTP API'lerinin gündelik dilde REST API diye anıldığını ama hepsinin REST'in bütün kısıtlarına uymadığını da not eder. Bu yüzden bir teklifteki "REST API ile entegre olacağız" ifadesi bağlantının türünü anlatır; tek başına bir kalite garantisi sayılmaz.

Bir API isteği örneği nasıl görünür?

Bir API isteği bir adres, bir yöntem (GET, PUT gibi) ve web API'lerinde yaygın olarak JSON biçiminde bir gövdeden oluşur. Anlatım için kurgulanmış bir stok güncellemesinde stok programı, web sitesinin API'sine PUT /api/stok/URUN-1042 adresiyle bir istek gönderir ve isteğin gövdesinde ürün kodunu, depoyu ve yeni miktarı taşır. Bu gövde, RFC 8259 (yeni sekmede açılır)'da tanımlanan, metin tabanlı ve programlama dilinden bağımsız bir veri biçimi olan JSON ile yazılır. Alan adları temsilidir.

{
  "urun_kodu": "URUN-1042",
  "depo": "istanbul-merkez",
  "miktar": 37,
  "kaynak": "stok-programi"
}

Bu örnekte stok güncellemesi için PUT seçildi, çünkü RFC 9110'a göre PUT ve DELETE ile GET gibi güvenli yöntemler "idempotent"tir: aynı isteği birkaç kez göndermenin sunucudaki amaçlanan etkisi, bir kez göndermekle aynıdır. Bağlantı koptuğu için aynı stok güncellemesi iki kez giderse miktar yine 37 olur. POST ile yapılan sipariş oluşturmada ise aynı isteğin ikinci kez gitmesi ikinci bir sipariş demek olabilir. Web sitesi isteği kabul ederse 2xx ile başlayan bir başarı kodu döner; API yeni ürün oluşturmaya izin vermiyorsa ve ürün yoksa 404, anahtar geçersizse 401 döner.

API anahtarı (API key) nedir?

API anahtarı, bir programın API'ye kendini tanıtmak için gönderdiği gizli bir koddur; anahtarı bilen, o anahtarın izin verdiği her şeyi yapabilir. Daha gelişmiş sistemler, Ekim 2012 tarihli RFC 6749 (yeni sekmede açılır)'da tanımlanan OAuth 2.0 çerçevesini kullanır. Bu çerçevede uygulama, kullanıcı adına erişimde kaynağın sahibinin onayıyla bir erişim belirteci (access token) alır ve RFC'ye göre bu belirteçler belirli kapsamları ve süreleri temsil eder. Pratikteki anlamı şudur: bir entegrasyona yalnızca işini yapacağı kadar yetki verilebilir ve bu yetkinin süresi dolabilir.

API anahtarları konusunda net bir görüşüm var: anahtarlar ve hesaplar şirketinizin adına açılmalı, e-postayla ya da mesajla dolaşmamalı ve işi yapan yazılımcının kişisel hesabında kalmamalı. UlvionTech'te kod deposu, bulut hesapları ve üçüncü taraf servisler ilk günden müşterinin adına açılır; API anahtarları da bu kuralın parçasıdır. Bir anahtar sızarsa onu iptal edip yenisini üretecek yetkilinin kim olduğunu önceden bilmek gerekir. Kişisel veri taşıyan bir entegrasyonda bu soru KVKK açısından da önemlidir; ayrıntılar web sitesi KVKK kontrol listesinde.

API entegrasyonu nasıl yapılır?

API entegrasyonu; iki sistem arasındaki bilgi akışının yazıya dökülmesi, karşı tarafın dokümanına göre bağlantı yazılımının geliştirilmesi, test ortamında denenmesi ve izlenerek canlıya alınmasıyla yapılır. Bir yönetici olarak asıl katkı vereceğiniz adımlar, akışları yazmak ile izleme ve sahipliği belirlemektir: hangi bilginin nereye gideceğine ve hata olunca kime haber verileceğine siz karar verirsiniz. Aradaki adımlar teknik ekibin işidir, ama her birinin görebileceğiniz bir çıktısı olmalı. Bir API entegrasyonunu şu sırayla kurmanızı öneririm:

1. Akışları yazın. Hangi bilgi, hangi programdan hangisine, ne sıklıkla ve hangi tetikleyiciyle gidecek; her akış için tek cümle yeter.
2. Karşı tarafın API'sini inceleyin. Doküman herkese açık mı, test ortamı (sandbox) var mı, hangi işlemler açık ve hangi kimlik doğrulama yöntemi kullanılıyor?
3. Alanları eşleştirin. Sizin "ürün kodu" alanınız ile onların "SKU" alanı, sizin KDV dahil fiyatınız ile onların KDV hariç fiyatı gibi farklar bu adımda çıkar.
4. Hata davranışını kararlaştırın. İstek reddedilirse, limit aşılırsa ya da karşı taraf cevap vermezse ne olacağı ve kime bildirim gideceği yazılır.
5. Test ortamında deneyin. Canlı veriye dokunmadan, uç durumlarla birlikte: sıfır stok, iptal edilen sipariş, iade, yarım kalan ödeme.
6. Kademeli canlıya alın. Önce tek bir akışla ya da sınırlı ürünle başlanır ve iki tarafın kayıtları birkaç gün karşılaştırılır.
7. İzlemeyi ve sahipliği kurun. Kayıtlar (log), uyarılar ve "bu entegrasyonun sahibi kim" sorusunun cevabı yazılı olur.

Alan eşleştirmesi, bir API entegrasyonunda benim en çok önem verdiğim adımdır ve küçük bir işte bile atlanmamalıdır. Alan eşleştirmesi atlanırsa her şey teknik olarak çalışır ama yanlış fiyat, yanlış birim ya da yanlış müşteri kaydı fark edilmeden akar. Bu tür hatalar bir durum kodu üretmediği için ay sonu mutabakatına kadar fark edilmeyebilir. Akışların yazılı bir kapsama dönüşmesi, UlvionTech'in "koddan önce kapsam" ilkesinin de özüdür.

API entegrasyonunun süresini ne belirler?

Bir API entegrasyonunun süresini en çok karşı tarafın API'sinin kalitesi belirler: dokümanın açıklığı, test ortamının varlığı, kimlik doğrulamanın karmaşıklığı, istek limitleri ve sürüm değişikliklerinin sıklığı. Sizin tarafınızdaki akış sayısı ve iş kuralları da süreyi büyütür. Burada gün ya da hafta vermiyorum, çünkü aynı "stok entegrasyonu" iyi belgelenmiş bir API'de kısa, belgesi eksik bir API'de çok daha uzun sürebilir. Bir teklifteki süreyi değerlendirirken şu beş başlığa bakmak işinizi kolaylaştırır.

API dokümantasyonu süreyi nasıl etkiler?

API dokümantasyonu, karşı tarafın API kalitesinin entegrasyon süresine en çok yansıyan parçasıdır. Her alanın anlamını, örnek istekleri ve hata kodlarını yazan bir doküman, deneme yanılmayla geçecek günleri azaltır. Eksik ya da eski bir dokümanda geliştirici, API'nin nasıl davrandığını istek gönderip sonucuna bakarak öğrenir ve bu süre önceden tahmin edilemez. Test ortamı (sandbox) da aynı ölçüde önemlidir; yoksa her deneme canlı veriye dokunur ve test yavaşlar. Teklif istemeden önce karşı tarafın doküman bağlantısını ekibe göndermek, süre tahminini belirgin biçimde iyileştirir.

Kimlik doğrulama ve yetkiler

API kimlik doğrulaması, basit bir anahtardan OAuth 2.0 akışlarına kadar değişir ve karmaşıklaştıkça kurulum süresi uzar. OAuth'ta erişim belirteçleri süreli verilebilir; süresi dolan belirteci yenileme belirteciyle (refresh token) yenileyen mantık yazılmazsa entegrasyon bir gece kimseye haber vermeden durabilir. Bazı kurumlar API erişimini başvuruya, sözleşmeye ya da onay sürecine bağlar ve bu bekleme süresi geliştirme süresine eklenir. Onay süreçlerini projenin en başında başlatmak gerekir, çünkü kodla hızlandırılamayan kalemlerden biri budur.

API istek limiti (rate limit) nedir?

İstek limiti, bir API'nin belirli bir sürede kabul ettiği istek sayısına koyduğu üst sınırdır. Nisan 2012 tarihli RFC 6585 (yeni sekmede açılır), bu durum için 429 Too Many Requests kodunu tanımlar: istemci belirli bir sürede çok fazla istek göndermiştir. Yanıt, yeniden denemeden önce ne kadar beklenmesi gerektiğini söyleyen bir Retry-After başlığı içerebilir. Binlerce ürünün stoğunu tek tek güncellemek isteyen bir entegrasyon bu sınıra takılabilir. Bu yüzden toplu güncelleme, kuyruk ve sıralama tasarımı gerekir; limit ne kadar düşükse bu tasarım o kadar emek ister.

Hata yönetimi ve yeniden deneme

Hata yönetimi, bir API entegrasyonunun her şey yolunda gitmediğinde ne yaptığını belirler ve bana göre projede sık atlanan ama pahalıya patlayabilen bir kısımdır. Karşı taraf 503 döndürdüğünde istek kaybolmamalı; bir kuyrukta bekleyip sonra yeniden denenmelidir. Yeniden denemenin de bir kuralı var: idempotent olmayan bir isteği körü körüne tekrarlamak çift sipariş ya da çift tahsilat üretebilir. İyi bir tasarımda her başarısız istek kaydedilir, belirli sayıda denemeden sonra bir insana bildirim gider ve kimse veriyi düzeltmek için tabloları elle karıştırmaz.

Sürüm değişiklikleri ve bakım

API sürüm değişikliği, karşı tarafın API'sini güncellemesi ya da eski bir sürümü kapatmasıdır ve entegrasyonun canlıya çıktıktan sonra da emek istemesinin ana nedenidir. Bir alanın adı değişir, bir uç nokta (endpoint) kaldırılır ya da kimlik doğrulama yöntemi yenilenir; sizin tarafınızda hiçbir şey değişmediği halde entegrasyon bozulur. Bu yüzden entegrasyonu, bakım bütçesi olan bir parça olarak planlamak gerekir. Bakımın kimde olduğu, ne kadar sürede müdahale edileceği ve hangi değişikliklerin ek ücrete girdiği sözleşmede yazmalı; yazılım hizmet sözleşmesi örneği bu maddeleri tek tek listeliyor.

Hazır bağlayıcı mı, özel entegrasyon mu, CSV aktarımı mı?

Özel entegrasyon size özgü kuralları, üç ya da daha fazla sistemi ve anlık veriyi gerektiren akışlara; hazır bağlayıcı iki yaygın program arasındaki standart akışlara; CSV ya da Excel aktarımı ise tek seferlik ya da ayda bir yapılan taşımaya uyar. Özel entegrasyon, sizin akışınıza göre yazılan ve kodu, sunucusu, anahtarları şirketinizin adına duran bağlantı yazılımıdır. Hazır bağlayıcı ise yaygın programlar arasında önceden kurulmuş bağlantıları ayarlarla kullanmanızı sağlayan hazır programdır. Bana göre bu seçimi ürün tercihinden önce kurallarınız ve bağlanan sistem sayısı belirlemeli; üç yolun aynı ölçütlerle karşılaştırması şöyle:

Kendi API entegrasyonunuzu yazdırmanın avantajları, kurallarınız size özgüleştikçe ve bağlanan sistem sayısı arttıkça büyür: akış bir ürünün ayarlarına göre sınırlanmaz, işinizin kurallarına göre çalışır; maliyet abonelik kalemleri gibi kullanıcı ve işlem sayısıyla kendiliğinden büyümez, değişiklik için kimsenin yol haritasını beklemezsiniz.

Özel API entegrasyonunun dezavantajları da bellidir: ilk sürüm daha uzun sürer, baştan daha fazla bütçe ister ve şirketinizde bu entegrasyonu sahiplenen biri olmalıdır. Yapay zekâ destekli geliştirme ilk yazım süresini kısaltabilir; yine de kararı kendi teklifinizdeki rakamla vermelisiniz. Hazır ve özel yazılım kararının genel çerçevesi özel yazılım mı hazır yazılım mı yazısında.

Entegrasyon yolunu seçerken şu eşleştirmeyi kullanabilirsiniz:

• Özel entegrasyonu seçin, eğer akışınızda size özgü kurallar varsa, üç ya da daha fazla sistem birbirine bağlanacaksa, veri anlık olmalıysa ya da bağlantının kodunun ve verisinin şirketinizde kalmasını istiyorsanız.
• Hazır bağlayıcıyı seçin, eğer iki yaygın program arasında standart bir akış kuruyorsanız, kurallarınız bağlayıcının ayarlarına sığıyorsa ve abonelik maliyetini üç-beş yıllık toplamıyla kendi rakamlarınızla hesapladıysanız.
• CSV aktarımını seçin, eğer iş tek seferlikse, veri haftada ya da ayda bir taşınıyorsa ve birkaç saatlik gecikme kimseye zarar vermiyorsa.
• Henüz hiçbirini seçmeyin, eğer akışları yazıya dökmediyseniz; belirsiz bir sürece kurulan entegrasyonun kuralları da sık sık yeniden yazılır.

Ne zaman API entegrasyonu yapmamalısınız?

API entegrasyonu, bilgi sık, düzenli ve hacimli aktığında anlamlıdır; bu üç koşul yoksa bağlantı yazılımı yazmak gereksiz bir maliyet olabilir. Entegrasyonu ertelemenizi ya da hiç yapmamanızı söyleyeceğim durumlar şunlar:

• Tek seferlik veri taşıma: Eski programdan yenisine bir kez geçiyorsanız dışa aktarım dosyası ve dikkatli bir kontrol listesi yeter.
• Düşük hacim: Günde birkaç sipariş elle birkaç dakikada aktarılıyorsa, entegrasyonun kendini amorti etmesi uzun sürer.
• Arada bir gereken raporlar: Ayda bir yönetim raporu için programların CSV ya da Excel dışa aktarımı yeterlidir; Excel'in nerede yetmediğini Excel'den yazılıma geçiş yazısı anlatıyor.
• API'si olmayan ya da çok kısıtlı bir program: Ekran kazıma gibi kırılgan yollarla kurulan bağlantı, ekran değiştiğinde bozulabilir; bu durumda önce programın kendisini sorgulamak gerekir.
• Henüz oturmamış süreç: Kimin neyi onayladığı her ay değişiyorsa entegrasyon kuralları da her ay yeniden yazılır.
• Kodsuz araçla çözülebilen basit akış: Tek tetikleyici ve tek eylemden oluşan akışlarda kod yazmadan otomasyon yeterli olabilir; sınırlarını no-code otomasyon mu özel yazılım mı yazısında ele aldım.

API entegrasyonu, elle yapılan bir aktarımın maliyetini düşürmek için vardır. Bu yüzden elle aktarımın ayda kaç saat aldığını ve hatalarının neye mal olduğunu kabaca hesaplamadan bir entegrasyon teklifine evet dememenizi öneririm. Bu hesap bazen entegrasyonun gerektiğini, bazen de iyi tasarlanmış bir dışa aktarım dosyasının işi gördüğünü gösterir. Dışa aktarım dosyası yeterli çıkarsa, entegrasyon bütçesi iş yükü daha fazla olan bir akışa ayrılabilir.

API entegrasyonunda sık yapılan hatalar nelerdir?

API entegrasyonunda sık yapılan hatalar kapsamla ve sahiplikle ilgilidir: kod çalışır ama yanlış şeyi yapar ya da bozulduğunda kimse fark etmez. Bu hatalar entegrasyon işinin doğasından gelen genel kalıplardır:

• "Her şeyi bağlayalım" diye başlamak: Akış listesi olmadan başlayan iş, öncelikleri olmayan ve bitmeyen bir projeye dönme riski taşır.
• Hata senaryosunu konuşmamak: Her şeyin yolunda gittiği senaryo test edilir; limit aşımı, zaman aşımı ve iade gibi durumlar canlıda öğrenilir.
• Tek yönlü düşünmek: Sipariş web sitesinden depoya gider ama iptal depodan web sitesine dönmezse iki sistemin kayıtları kısa sürede birbirinden ayrışır.
• Anahtarları kişisel hesaplarda tutmak: Yazılımcı ayrıldığında erişim de onunla gidebilir.
• İzleme kurmamak: Entegrasyon durduğunda bunu ilk fark eden müşteri olabilir.
• Bakımı bütçelememek: Karşı tarafın sürüm değişikliği geldiğinde entegrasyon acil bir işe dönüşür.

Entegrasyon hatalarına karşı temel önlem, bağlantıyı yazılı bir kapsamla ve sahibi belli bir parça olarak kurmaktır. İlk sürümde fazladan özellik yerine izleme ve uyarı mekanizmasına süre ayırmayı daha değerli bulurum. Hatayı gün içinde fark ettiren bir uyarı, ay sonunda bulunan bir hatadan daha ucuza kapanabilir. Kayıtların ve uyarıların tek ekranda toplanması, kurumsal paneller hizmetimizin de konusudur.

Entegrasyon teklifi almadan önce hangi soruları sormalısınız?

Bir API entegrasyonu teklifini değerlendirmenin en hızlı yolu, her teklif verene aynı soruları sormaktır; cevapların açıklığı, fiyat kadar bilgi verir. Görüşmeye şu soru listesiyle girebilirsiniz:

• İlk sürümde hangi akışlar var, hangileri sonraya kaldı ve bu yazılı mı?
• Karşı tarafın dokümanını ve test ortamını incelediniz mi; süre tahmininiz buna mı dayanıyor?
• İstek limiti aşıldığında ya da karşı taraf cevap vermediğinde veri nerede bekliyor, kaç kez yeniden deneniyor?
• Aynı istek iki kez giderse çift kayıt nasıl önleniyor?
• Hatalar kime, hangi kanaldan bildiriliyor ve kayıtları kim görebiliyor?
• API anahtarları, kod deposu ve sunucu kimin adına açılıyor?
• Karşı taraf sürüm değiştirdiğinde güncelleme destek dönemine dahil mi, değilse nasıl fiyatlanıyor?
• Kişisel veri taşınıyorsa hangi alanlar gidiyor ve ne kadar süre saklanıyor?

Akış kapsamı, hata ve yeniden deneme, çift kayıt, anahtar sahipliği ve sürüm bakımı sorularına açık cevap veremeyen bir entegrasyon teklifi, ucuz görünse bile riski size bırakır. Teklifleri karşılaştırmanın genel yöntemi yazılım yaptırma maliyeti ve teklif karşılaştırma yazısında. Stok entegrasyonu düşünüyorsanız, önce stok tarafını netleştirmek için stok takip programı seçimi yazısına da bakabilirsiniz. Ben API anahtarlarının ve kod deposunun kimin adına açıldığı sorusuna verilen cevaba özellikle bakarım, çünkü sahipliği sonradan düzeltmek zordur.

Bir API entegrasyonuna nereden başlamalı?

Bir API entegrasyonuna, en çok zaman kaybettiren tek akışı seçip onu uçtan uca ve izlemesiyle birlikte kurarak başlamanızı öneririm. Bu akış, örneğin web sitesinden gelen siparişin depo ve muhasebe programına düşmesi ya da stok miktarının satış kanallarına dağıtılması olabilir. UlvionTech böyle bir işe iki tarafın dokümanını okuyarak, alan eşleştirmesini yazıya dökerek ve hata senaryolarını sizinle kararlaştırarak başlar. İlk akış bir süre sorunsuz çalıştıktan sonra ikincisine geçmek, her adımda neyin işe yaradığını görmenizi sağlar. Bu tür bağlantıları web uygulamaları hizmetinin parçası olarak, yazılı kapsam ve sabit fiyatlı teklifle kurarız.

Ne zaman UlvionTech ile çalışmamalısınız?

UlvionTech ile çalışmamanız gereken durumlar, işin dışarıdan bir yazılım ekibine ihtiyaç duymadığı durumlardır:

• Şirket içinde bir yazılım ekibiniz varsa: Kendi geliştiricileriniz sistemleri tanıyorsa, dışarıdan gelen bir ekip işe bağlam kaybı ekleyebilir; en fazla bir mimari görüş için konuşmak yeterli olur.
• Sorun karşı tarafın API'sindeyse: Hata sağlayıcının tarafındaysa ve belgelenmişse önce sağlayıcının destek ekibine başvurun; bizim yazacağımız geçici bir çözüm sorunu kalıcı olarak gidermez.
• Kurulu bir hazır bağlayıcınız işinizi görüyorsa: Tek sorun küçük bir ayar ya da eksik bir alan eşleştirmesiyse, bağlayıcının kendi destek ekibi bunu daha hızlı çözer.
• Entegrasyonun sahibi olacak kimse yoksa: Şirketinizde akışlara karar verecek ve hatalarda aranacak bir kişi belirlenmeden başlanan entegrasyon sahipsiz kalır; önce o kişiyi belirlemenizi isterim.

Akışlarınızı yazdıysanız ve hangisinin size en çok zaman kaybettirdiğini biliyorsanız, o listeyle iletişim sayfamızdan bize yazabilirsiniz; karşı tarafın API dokümanının bağlantısını da eklerseniz ilk süre tahmini daha isabetli olur.