API Entegrasyonu Fiyatları 2026: Maliyet Nasıl Hesaplanır?

API entegrasyonu fiyatları neden bu kadar farklı çıkıyor?

Kısa cevap: teklifler aynı işi fiyatlamıyor. Bir firma yalnızca verinin A sisteminden B sistemine taşınmasını fiyatlar; diğeri karşı sistem kapalıyken ne olacağını, aynı siparişin iki kez gelmesini, gece yarısı düşen bağlantıyı ve ay sonunda iki sistemin rakamlarının tutmamasını da kapsama alır. İkinci teklif doğal olarak birkaç kat yüksek çıkar ve ilk bakışta pahalı görünür.

Veri entegrasyonu tarafında yıllardır çalışan biri olarak teklif görüşmelerinde en sık duyduğum cümle şu: "Basit bir iş, siparişleri ERP'ye aktaracak." Sonra sorular gelir. Sipariş hangi cariye yazılacak, pazaryerinin müşterisi ERP'de yoksa açılacak mı? Kargo ücreti ayrı satır mı? Kampanya indirimi satır bazında mı, belge bazında mı düşülüyor? İade olunca ERP'de ne oluşacak? Her soru, kapsama birkaç saat ya da birkaç gün ekler.

Aynı cümleyle istenen işin üç farklı kapsamı aşağıda. Üçü de "pazaryeri–ERP entegrasyonu" diye teklif edilebilir; fiyat farkının nereden geldiğini görmek, yazının geri kalanını okumayı kolaylaştırır.

• Kapsam 1 · Yalnız sipariş aktarımı
  • Siparişler 15 dakikada bir çekilir, ERP'ye sipariş fişi olarak yazılır
  • Cari tek bir "pazaryeri müşterisi" hesabına bağlanır
  • Hata olursa log dosyasına yazılır
  Birkaç günlük iş. Ama hata olunca kimse fark etmez.
• Kapsam 2 · Sipariş + stok + fiyat
  • Stok ve fiyat ERP'den pazaryerine tek yönlü gider
  • Varyant, birim ve KDV oranı eşleştirme tablosu kurulur
  • Hata kuyruğu ve tekrar deneme, e-posta alarmı vardır
  Birkaç haftalık iş. Günlük operasyonu taşır.
• Kapsam 3 · Çift yönlü, iade ve fatura dahil
  • Sipariş durumu, iade ve kargo bilgisi iki yönlü akar
  • e-Fatura numarası ERP'den pazaryerine geri yazılır
  • Günlük mutabakat raporu ve izleme paneli vardır
  Birkaç aylık proje. Elle müdahaleyi neredeyse bitirir.

Teklifteki rakamın arkasında hep benzer katmanlar vardır. Endpoint'i çağıran kod, bütün işin genellikle küçük bir kısmıdır; asıl efor keşif, alan eşleştirme, hata yönetimi, test ve izlemededir. Aşağıdaki şema bu katmanların nasıl üst üste bindiğini örnek oranlarla gösteriyor.

API entegrasyonu maliyetini belirleyen 9 faktör

Bizim ekipte bir entegrasyona efor yazmadan önce veri akış şemasını çizeriz: hangi nesne, hangi sistemden, hangi yöne, ne sıklıkla ve hangi kuralla akacak. Aşağıdaki dokuz faktör bu şemadan okunur. Her kartta maliyeti neyin artırdığını ve neyin düşürdüğünü ayrı yazdım; teklif görüşmesine giderken bu kartları soru listesi olarak da kullanabilirsiniz.

1. 1Bağlanacak sistem sayısıHer yeni sistemle birlikte yeni bir kimlik doğrulama, yeni bir test ortamı ve yeni bir hata davranışı gelir. Üç sistemi birbirine bağlamak, üç ayrı ikili bağlantıdan pahalıdır; çünkü veri artık bir merkezden geçer ve sıra önem kazanır.↑ Artırır: Her sistemi diğerlerine doğrudan bağlamak (noktadan noktaya ağ)↓ Düşürür: Tek bir entegrasyon katmanı ve ortak veri modeli
2. 2Karşı tarafın arayüzüDokümanlı, sandbox'ı (canlı veriye dokunmadan deneme yapılan test ortamı) olan bir REST servisiyle çalışmak ile WSDL'i yıllardır güncellenmemiş bir SOAP servisiyle ya da API'si hiç olmayan bir masaüstü programla çalışmak arasında birkaç kat efor farkı vardır. Bu, fiyatı en çok oynatan tek faktördür. Veritabanı tarafından geldiğim için en sık itiraz ettiğim yol, ERP tablolarına doğrudan yazmaktır: ERP sürüm yükseltmesinde bir kolon adı ya da tetikleyici değişir ve entegrasyon hata bile vermeden yanlış veri yazmaya başlar.↑ Artırır: API yok, doğrudan veritabanı, dokümansız SOAP↓ Düşürür: OpenAPI dokümanı, sandbox, örnek istekler
3. 3Veri yönüTek yönlü akışta bir sistem esastır, diğeri okur. Çift yönlü akışta aynı kayıt iki yerde değişebilir ve hangisinin kazanacağına karar veren bir kural yazmak gerekir. Bu kural yazılmazsa veri sessizce bozulur.↑ Artırır: Her nesnede çift yön↓ Düşürür: Nesne bazında tek esas sistem
4. 4Senkron sıklığıGecelik toplu aktarım basit bir zamanlanmış görevdir. Olay anında senkron ise webhook alıcısı (karşı sistem bir olay olduğunda sizin adresinizi çağırır), kuyruk, tekrar deneme ve sıra garantisi ister. Arada 5–15 dakikalık çekim çoğu işletme için yeterli bir orta yoldur.↑ Artırır: Her nesnede gerçek zaman beklentisi↓ Düşürür: Nesneye göre farklı sıklık
5. 5Günlük kayıt hacmiGünde birkaç yüz sipariş ile kampanya gününde on binlerce stok güncellemesi aynı kodla taşınmaz. Hacim büyüdükçe toplu işlem, sayfalama, karşı tarafın hız sınırına uyum ve kuyruk ölçeklemesi devreye girer.↑ Artırır: Her değişikliği ayrı ayrı göndermek↓ Düşürür: Yalnız farkı (delta) aktarmak
6. 6Alan eşleştirme ve iş kuralıVaryantlar, ölçü birimleri, KDV oranları, fiyat listeleri, depo kodları, kampanya indirimleri. Entegrasyonda en çok zaman alan iş, iki sistemin aynı şeyi farklı adlandırdığı yerleri bulmaktır. Bu iş kod yazmaktan çok veri sözlüğü hazırlamaktır.↑ Artırır: Kuralların proje sırasında keşfedilmesi↓ Düşürür: Müşteri tarafında hazırlanmış veri sözlüğü
7. 7Güvenlik ve uyumlulukSabit bir API anahtarı ile token yenilemeli OAuth 2.0 ya da iki tarafın da sertifikayla kimliğini kanıtladığı mTLS ve tam denetim izi (audit log) arasında belirgin bir efor farkı vardır. Kişisel veri taşınıyorsa KVKK açısından erişim kaydı ve saklama süresi de tasarıma girer.↑ Artırır: Kişisel veri, finansal işlem, denetim zorunluluğu↓ Düşürür: Kişisel veri içermeyen katalog ve stok akışı
8. 8Ortam sayısıTest, ön canlı (staging) ve canlı ortamların her birinin kendi ayarı, kendi anahtarı ve kendi verisi olur. Karşı tarafın test ortamı yoksa testler canlıda, dikkatle ve daha yavaş yapılır; bu da takvimi uzatır.↑ Artırır: Karşı tarafta test ortamı olmaması↓ Düşürür: Sandbox erişiminin işe başlamadan alınması
9. 9Dokümantasyon, SDK ve izlemeEntegrasyonu yalnız siz kullanacaksanız alan eşleştirme dokümanı ve alarm yeterli olabilir. Bayilere veya iş ortaklarına açıyorsanız OpenAPI dokümanı, Postman koleksiyonu, belki bir SDK ve kullanım paneli gerekir.↑ Artırır: Dışarıya açılan partner API↓ Düşürür: Tek bir iç entegrasyon

İkinci faktör, yani karşı tarafın arayüzü, planlayıcıda bir çarpan olarak çalışır. Aşağıdaki skala, aynı nesne setini farklı arayüzlerle taşımanın göreli eforunu gösteriyor. Rakamlar örnek; yön ve büyüklük ise sahada gördüğümüzle uyumlu.

API entegrasyonu maliyeti nasıl hesaplanır? Maliyet Planlayıcı

Aşağıdaki planlayıcı, yukarıdaki dokuz faktörü açık bir formüle döker. Her bağlanacak sistem için bir satır açın; karşı tarafın arayüzünü, veri yönünü ve taşınacak nesneleri seçin. Ardından senkron sıklığını, günlük kayıt hacmini, güvenlik seviyesini ve ek teslimatları işaretleyin.

Saatlik ücret alanı bilerek boş geliyor. Bir firmanın ücretini size dayatmak yerine, elinizdeki teklifteki ya da piyasada duyduğunuz ücreti yazmanızı istiyoruz. Ücret girene kadar planlayıcı yalnızca efor-saat, adam-gün ve takvim gösterir; ücret girince TL aralığı (KDV hariç ve dahil), yıllık bakım tahmini ve 36 aylık toplam maliyet açılır.

Tek yönlü mü, çift yönlü mü? Senkron yönü ve sıklığı fiyatı nasıl değiştirir?

Planlayıcıda çift yönlü seçtiğinizde ilgili sistemin eşleştirme eforu 1,7 ile çarpılıyor. Bu katsayının arkasında tek bir soru var: aynı kayıt iki yerde aynı anda değişirse hangisi doğru kabul edilecek?

Somut bir örnek vereyim. Müşteri hizmetleri pazaryeri panelinden bir siparişin teslimat adresini düzeltiyor. Aynı dakikalarda depo, ERP'de aynı siparişi "hazırlanıyor" durumuna alıyor. Senkron çalıştığında iki değişiklik birbirinin üstüne yazılırsa ya adres düzeltmesi kaybolur ya da durum geri alınır. Çift yönlü bir entegrasyon, bu tür çakışmaları alan bazında çözen bir kural ister: adres pazaryerinden, durum ERP'den gelir gibi.

Bu kuralı yazmak, test etmek ve iki sistemin saatleri arasındaki farkı hesaba katmak zaman alır. Bu yüzden ilk sorum her zaman şu olur: bu nesne gerçekten iki tarafta da değişiyor mu? Stok neredeyse her zaman tek yönlüdür, esas sistem ERP'dir. Fiyat çoğu işletmede tek yönlüdür. Çift yön genellikle sipariş durumu, iade ve kargo bilgisinde gerekir.

Çift yönlü senkronda çakışma kuralları

• 1.Alan bazında esas sistemKayıt bazında değil alan bazında karar verin: adres pazaryerinden, durum ve fatura numarası ERP'den.
• 2.Son yazan kazanır, ama sürüm numarasıylaZaman damgası tek başına güvenilmez; iki sunucunun saati farklı olabilir. Kayıt sürüm numarası veya değişiklik sayacı tutun.
• 3.Yankı döngüsünü kesinA'dan B'ye yazılan değişiklik B'de bir olay tetikler ve A'ya geri döner. Kaynağı işaretlemeyen entegrasyon kendi yazdığını sonsuza kadar geri okur.
• 4.Çakışmayı sessiz bırakmayınKural karar veremiyorsa kaydı bir inceleme kuyruğuna atın ve birine haber verin. Sessiz üstüne yazma, ayın sonunda mutabakatta patlar.

Senkron sıklığı: hangisi ne zaman yeter?

Küçük, orta ve kurumsal API entegrasyonu ne kadar sürer, ne kadar tutar?

Aşağıdaki dört kapsam, sahada en sık karşılaştığımız entegrasyon tiplerinden derlenmiş örneklerdir; gerçek bir müşteri projesi değildir. Her kartın efor aralığı planlayıcıdan canlı hesaplanıyor. TL karşılığını bilerek sabit yazmadım: kartı planlayıcıya yükleyip kendi saatlik ücretinizi girdiğinizde tutarı siz görürsünüz. W3'ün güncel paket kapsamları için API geliştirme hizmet sayfamıza bakabilirsiniz.

1. 1Tek yönlü stok ve fiyat çekimiTedarikçinin stok ve fiyat listesini kendi sitesine almak isteyen bayiTedarikçinin REST servisinden stok ve fiyat gecelik çekilir, siteye yazılır. Hata olursa sorumlu kişiye e-posta gider.

   Efor

   67–86 sa

   Adam-gün

   8–11

   Takvim

   3 hf

   Dikkat: Tedarikçinin ürün kodu ile sizin kodunuz aynı değilse eşleştirme tablosu ayrı bir iş kalemidir.Planlayıcıya yükle ↑
2. 2E-ticaret + ödeme + kargoKendi mağazasında ödeme ve kargo adımlarını otomatikleştirmek isteyen e-ticaret firmasıÖdeme onayı ve iade bildirimi webhook ile alınır; kargo firmasının SOAP servisiyle gönderi açılır ve durum takip edilir.

   Efor

   164–210 sa

   Adam-gün

   21–26

   Takvim

   5–6 hf

   Dikkat: Kargo firmasının test ortamı sınırlıysa canlı testler takvimi uzatır; iade akışı çoğu zaman sonradan hatırlanır.Planlayıcıya yükle ↑
3. 3Çift yönlü pazaryeri + ERPBirden fazla kanalda satan ve stoğu ERP'den yöneten işletmeÜrün, stok, fiyat, sipariş ve iade pazaryeri ile ERP arasında akar; ERP tarafına veritabanı üzerinden bağlanılır. İzleme paneli ve OpenAPI dokümanı teslim edilir.

   Efor

   312–416 sa

   Adam-gün

   39–52

   Takvim

   8–11 hf

   Dikkat: Varyant ve kategori eşleştirmesi, kodlamadan uzun sürebilir. Müşteri tarafında veri sözlüğü hazırsa aralığın alt ucuna yaklaşılır.Planlayıcıya yükle ↑
4. 4Bayilere açılan partner APIBayilerinin sipariş ve stok bilgisine kendi sistemlerinden erişmesini isteyen üretici veya distribütörÜrün, fiyat, stok, sipariş ve cari bilgisi bayilere sertifikalı ve kotalı bir API ile açılır; arkada ERP'den okunur. SDK, kullanım paneli ve yük testi teslimata dahildir.

   Efor

   373–497 sa

   Adam-gün

   47–62

   Takvim

   9–12 hf

   Dikkat: Asıl maliyet sürüm yönetimidir: bir bayi eski sürümü kullanırken API'yi değiştirmek, geriye uyumluluk kuralı ister.Planlayıcıya yükle ↑

Adam-gün hesabında 1 gün = 8 saat aldık. Takvimde örnek olarak haftada yaklaşık 50 saatlik ekip kapasitesi (bir buçuk geliştirici civarı) ve bir canlıya geçiş haftası varsayıldı. Gerçek takvimi kod hızından çok karşı tarafın erişim açma ve onay süreleri belirler; bir kargo firmasından test hesabı almak bazen geliştirmenin kendisinden uzun sürer. Mikroservise geçiş gibi kurumsal ölçekte ise iş tek bir entegrasyon olmaktan çıkar, mimari projeye dönüşür.

Mimari ölçekte bir dönüşüm planlıyorsanız mikro servis geçişi için API geliştirme sayfası, entegrasyonu servis ayrıştırmasıyla birlikte nasıl ele aldığımızı anlatıyor.

Hazır entegrasyon, iPaaS ve özel API: 3 yıllık maliyet karşılaştırması

"Hazır entegrasyon mu, özel yazılım mı?" sorusu aslında bir zaman sorusudur. Hazır çözümde başlangıç bedeli düşük, aylık bedel süreklidir. Özel geliştirmede başlangıç bedeli yüksek, aylık gider bakım ve altyapıyla sınırlıdır. İki eğri bir noktada kesişir; kesişme 36 ayın içindeyse özel geliştirme ciddi bir seçenektir, dışındaysa çoğu zaman değildir.

Pazaryeri entegrasyonu fiyatları diye arama yapanların büyük kısmı aslında bu ilk seçeneği, yani entegratör aboneliğini arıyor. Bu firmalar Trendyol, Hepsiburada ve benzeri kanalları tek panelde toplar; ücretlendirme genellikle kanal sayısı, ürün veya sipariş adedi kademesiyle aylık ya da yıllık yapılır. Standart bir mağaza için mantıklı bir başlangıçtır. Sorun, iş kuralınız panelin sunduğu ayarların dışına çıktığında başlar: ERP'nizde özel bir alan, bayi bazlı fiyat ya da depo bazlı stok gibi.

iPaaS (Integration Platform as a Service) araçları, yani Zapier, Make veya kurumsal tarafta benzeri platformlar, iki sistemi kod yazmadan bağlamanızı sağlar. Ücretlendirme kullanıma göredir: Zapier başarıyla tamamlanan her eylemi bir görev (task) sayar, Make ise 2025'ten beri kredi birimiyle faturalar. Kabaca, akıştaki her adım her kayıt için bir birim tüketir. Düşük hacimli bildirim ve form akışlarında çok ekonomiktir; günde binlerce kaydı birkaç adımdan geçirdiğinizde fatura hızla büyür ve hata yönetimi platformun izin verdiği kadardır.

Aşağıdaki grafik iki kümülatif maliyet eğrisini şematik olarak gösteriyor. Planlayıcıda hazır çözümün aylık bedelini girdiğinizde aynı hesabı kendi rakamlarınızla yapıyor ve başa baş ayını yazıyor. Bir uyarı: hazır çözümün aylık bedeli 36 ay sabit kalmaz; kur ve fiyat güncellemelerini hesaba katmak için girdiğiniz bedeli biraz yukarı yuvarlayın.

API entegrasyonu teklifinde hangi kalemler görünmez? Retry, idempotency, hata kuyruğu ve izleme

Bir entegrasyonun gerçek kalitesi, her şey yolunda giderken değil, karşı sistem yanıt vermediğinde ortaya çıkar. Ucuz tekliflerin ucuzluğu da genelde tam bu bölümden gelir: mutlu yol (happy path) kodlanır, geri kalanı "gerekirse bakarız" diye bırakılır.

En pahalı hatayı anlatayım. Pazaryeri bir siparişi bildiriyor, sizin sisteminiz siparişi ERP'ye yazıyor ama yanıtı göndermeden bağlantı kopuyor. Pazaryeri bildirimin ulaşmadığını düşünüp tekrar gönderiyor. Sisteminiz aynı siparişi ikinci kez yazıyor. Depo iki koli hazırlıyor, muhasebe iki fatura kesiyor. Bu senaryonun adı çift sipariştir ve önlemi idempotency anahtarıdır: her olayın benzersiz kimliği saklanır, aynı kimlik ikinci kez gelirse yeni kayıt açılmaz.

Aşağıdaki şema aynı tekrar denemenin iki farklı sonucunu gösteriyor. Teklifinizde bu kalemlerin her biri ya açıkça yazmalı ya da neden gerekmediği açıklanmalı. Sahadaki hata tiplerini sipariş düşmüyor, stok tutmuyorsa ne yapmalı yazısında ayrıca ele aldık; kavramların temelini merak ediyorsanız API nedir, entegrasyon nasıl yapılır rehberine bakabilirsiniz.

• Tekrar deneme (retry) ve geri çekilme (backoff)Karşı sistem geçici olarak yanıt vermediğinde istek, artan aralıklarla yeniden denenir. Aralıksız tekrar deneme karşı tarafı kilitler, hiç denememek veri kaybettirir.Az efor, büyük etki
• Idempotency anahtarıAynı olayın iki kez işlenmesini engeller. Ödeme ve siparişte bu yoksa çift kayıt yalnızca zaman meselesidir.Az efor, büyük etki
• Hata kuyruğu (DLQ, dead letter queue)Belirli sayıda denemeden sonra işlenemeyen kayıt kaybolmaz, ayrı bir kuyruğa düşer ve bir ekrandan yeniden gönderilebilir.Orta efor
• Hız sınırı (rate limit) stratejisiPazaryerleri ve kargo firmaları belirli bir süre içinde (saniye veya dakika başına) gönderilebilecek istek sayısını sınırlar. Strateji yoksa kampanya günü istekler reddedilir ve stok güncellenmez.Orta efor, hacimle artar
• Mutabakat işiGünde bir veya birkaç kez iki sistemdeki kayıtları karşılaştıran küçük bir iş. Kaçan webhook'u, sessizce düşen kaydı ve elle yapılan değişikliği yakalar.Orta efor, en çok ihmal edilen
• İzleme ve alarmKuyruk birikiyor mu, hata oranı arttı mı, son başarılı senkron ne zamandı? Bunu müşteriniz şikâyet etmeden önce bilmeniz gerekir.Orta efor
• Alan eşleştirme dokümanıHangi alanın hangi alana, hangi dönüşümle aktarıldığını yazan tablo. Bir yıl sonra yeni bir alan eklemek istediğinizde ilk aranan belgedir.Az efor

Kaynak kodun kime ait olacağı, SLA, ödeme planı ve sözleşme maddeleri gibi genel konuları burada tekrarlamıyorum; bunlar her yazılım projesi için geçerli ve yazılım firması seçerken dikkat edilmesi gerekenler yazımızda ayrıntılı anlatılıyor.

API bakım ücreti ne kadar tutar, neden gerekir?

Bakım ücreti, çoğu müşterinin ilk itiraz ettiği kalemdir: "Entegrasyon çalışıyor, neden her ay ödeyeyim?" Cevap, entegrasyonun iki ucunda da sizin kontrol etmediğiniz sistemlerin olmasıdır. Kod değişmese de karşı taraf değişir.

Pazaryerleri API sürümlerini günceller ve eski sürümü belirli bir tarihte kapatır. Kargo firması servis adresini veya kimlik doğrulama yöntemini değiştirir. ERP'niz sürüm yükseltmesinde bir tablonun yapısını değiştirir. e-Fatura tarafında GİB'in teknik kılavuzları ve UBL-TR şemaları zaman zaman güncellenir; özel entegratörünüz de buna göre kendi servisini değiştirir. Bunların herhangi biri, entegrasyonun bir sabah hiç uyarı vermeden durmasına yeter. Bizde en çok iş çıkaran tetikleyici pazaryeri tarafındaki değişiklikler değil, müşterinin kendi ERP'sinde yaptığı ve bize haber vermediği sürüm yükseltmesi oluyor.

Sektörde yıllık bakım için geliştirme bedelinin belirli bir yüzdesi sık dile getirilir; genellikle yüzde 10 ile 25 arasında rakamlar duyarsınız. Bu bir standart değil, bir alışkanlıktır. Planlayıcıda varsayılanı %15 bıraktım ve kaydırıcıyla değiştirebilmenizi sağladım. Doğru oran, entegrasyonun kaç dış sisteme dokunduğuna ve bu sistemlerin ne sıklıkla değiştiğine bağlıdır.

• Saat bankasıYıllık veya aylık belirli bir saat satın alınır, kullanıldıkça düşer. Değişikliği az olan entegrasyonlar için adil bir modeldir; kullanılmayan saatin devredip devretmediğini sözleşmede yazın.Uygun: Az değişen, tek veya iki sistemli entegrasyon
• Aylık sabitİzleme, alarm takibi, karşı taraf değişikliklerine uyum ve belirli bir müdahale süresi için sabit bir aylık bedel. Bütçesi öngörülebilir, kapsamı net yazılmalıdır.Uygun: Pazaryeri ve kargo gibi sık değişen kanallar
• Olay başıSorun çıktıkça saatlik ücretle müdahale. Kâğıt üzerinde en ucuz model; ama acil müdahale garantisi yoktur ve sorun en yoğun gününüzde çıkar.Uygun: Kritik olmayan, gecelik raporlama akışları

Sabit fiyat mı, adam-gün mü, abonelik mi? Entegrasyon fiyatlandırma modelleri

Aynı kapsam üç farklı modelle fiyatlanabilir ve model, riskin kimde kalacağını belirler. Sabit fiyatta risk firmadadır; firma da bu riski fiyata ekler ya da kapsamı daraltır. Adam-gün modelinde risk sizdedir ama ne için ödediğinizi görürsünüz. Abonelikte ise geliştirme bedeli aylık ödemeye yayılır, karşılığında uzun bir taahhüt verirsiniz.

Kapsamı belirsiz bir entegrasyonda sabit fiyat isterseniz, elinize ya şişirilmiş ya da içi boşaltılmış bir teklif geçer. Bizim önerimiz keşfi ayrı fiyatlandırmaktır: birkaç günlük bir çalışmayla veri akış şeması, alan eşleştirme taslağı ve karşı sistemlerin test erişimi netleşir; asıl geliştirme bu belge üzerinden sabit fiyatla verilebilir hâle gelir. Saatlik ve proje bazlı danışmanlık ücretlerinin nasıl oluştuğunu merak ediyorsanız IT danışmanlık ücretleri yazısı bu tarafı açıyor.

• Sabit fiyat+ Bütçe baştan bellidir; kapsam belgesi zorunlu hâle gelir.− Kapsam dışı her istek değişiklik talebi olur; firma belirsizliği fiyata ekler.Uygun: Keşfi yapılmış, veri sözlüğü hazır işler
• Adam-gün / saat+ Ne için ödediğinizi görürsünüz; kapsam yol üstünde değişebilir.− Toplam belirsizdir; haftalık raporlama ve üst sınır yoksa bütçe kayar.Uygun: Belirsiz, eski sistemli, keşif gerektiren işler
• Abonelik / aylık+ Başlangıç yükü düşer; bakım ve izleme bedele dahildir.− Uzun taahhüt; sözleşme bitince kaynak kod ve altyapının kime kalacağı netleşmeli.Uygun: Sürekli değişen kanallar, iç ekibi olmayan işletmeler

Entegrasyonun altyapı ve üçüncü taraf ücretleri neler? Sunucu, kuyruk, entegratör ve çağrı bedelleri

Geliştirme bittiğinde fatura bitmez. Entegrasyon bir yerde çalışır, bir yere log yazar, bazen bir servise her çağrı için ücret öder. Bu kalemler tek tek küçük görünür ama 36 aylık hesapta toplam maliyetin anlamlı bir kısmını oluşturabilir. Planlayıcıdaki "aylık altyapı" alanı bunun için var.

Sağlayıcı fiyatları sık değişir ve çoğu döviz bazlıdır, bu yüzden aşağıda rakam vermiyorum; hangi kalemin nasıl ücretlendiğini yazıyorum. Teklif alırken her kalemin sizin hesabınıza mı yoksa firmanın hesabına mı açılacağını sorun. Hesap firmada açılırsa sözleşme bittiğinde devir planı gerekir.

Bulut tarafında aylık faturanın hangi kalemlerden oluştuğunu bulut sunucu fiyatları yazısında kalem kalem açtık. Pazaryerlerinin satıcılarına sunduğu API erişiminin güncel koşullarını ise kendi satıcı sözleşmenizden kontrol edin; bizim gördüğümüz projelerde maliyet API'nin kendisinden değil, araya giren yazılımdan çıkıyor.

API entegrasyonu maliyeti kaliteden kısmadan nasıl düşürülür?

Maliyeti düşürmenin iki yolu var: daha az iş yaptırmak ya da işi daha az belirsiz hâle getirmek. Üçüncü yol gibi görünen "aynı işi daha ucuza yaptırmak" ise pratikte retry'ı, mutabakatı ve testi kesmeye çıkar. Aşağıdaki adımların hiçbiri kaliteden kısmıyor.

1. 1Fazlara bölünÖnce tek yönlü sipariş aktarımı, sonra stok ve fiyat, en son çift yönlü iade ve partner API. Her faz kendi başına değer üretir ve bir sonrakinin kapsamını netleştirir.
2. 2Veri sözlüğünü siz hazırlayınÜrün kodları, birimler, KDV oranları, depo ve fiyat listesi karşılıkları. Bu tabloyu işletmeyi bilen kişi hazırladığında, geliştirici günlerce soru sormak zorunda kalmaz.
3. 3Erişimleri işe başlamadan alınKarşı sistemin test ortamı, API anahtarı, IP izni, örnek veri. Geliştirici hazırken IP izni için iki hafta beklemek sık yaşanan bir durum; bu bekleme de genelde müşteri tarafının sorumluluğundadır.
4. 4Hazırı olanı hazırdan alınStandart bir kargo etiketi veya bildirim akışı için hazır modül ya da iPaaS yeterliyse, özel geliştirmeyi gerçekten size özgü kurala ayırın.
5. 5Kapsam dışını yazılı listeleyin"Bu fazda yok" listesi, "bu fazda var" listesi kadar değerlidir. Yol ortasında eklenen her istek, sabit fiyatı değişiklik talebine çevirir.

API entegrasyonu teklifleri nasıl karşılaştırılır?

Toplam fiyatları yan yana koyduğunuzda aslında farklı kapsamları karşılaştırırsınız. Daha adil yöntem, her teklifin hangi teknik maddeleri kapsadığını işaretleyip kapsanan madde başına fiyata bakmaktır. Aşağıdaki araç bunu yapıyor: her teklif için toplam fiyatı yazın, on bir maddeyi "var", "yok" veya "belirsiz" olarak işaretleyin.

Bu listede bilerek yalnız entegrasyona özgü maddeler var. Kaynak kodun devri, SLA ve ödeme planı gibi genel firma kriterleri için firma seçimi yazımızdaki karne daha uygun. Büyük bir ihalede teklifleri bağımsız bir gözle değerlendirmek isterseniz ihale ve tedarikçi seçimi için teknik danışmanlık sayfamıza bakabilirsiniz.

Ne zaman özel API entegrasyonu yaptırmamalısınız?

Entegrasyon yazan bir ekip olarak bu bölümü yazmak bize ters gelmiyor; yanlış zamanda yapılan entegrasyon, sonradan bakımı en zor iş oluyor. Aşağıdaki beş durumdan birindeyseniz özel geliştirme büyük olasılıkla gereksiz bir maliyettir.

• ✕Hacim düşükGünde birkaç sipariş veya haftada bir aktarım varsa, elle aktarım ya da basit bir dosya içe aktarımı aylarca yeter. Entegrasyonun kendini ödemesi için önce taşınacak bir iş yükü olmalı.
• ✕Platformun hazır modülü iş kuralınızı karşılıyorE-ticaret altyapınızın veya ERP'nizin resmî entegrasyon modülü, ihtiyacınızın tamamını karşılıyorsa önce onu deneyin. Özel geliştirmeyi, modülün bıraktığı boşluğa ayırın.
• ✕Süreç henüz oturmamışSipariş akışınız her ay değişiyorsa, onu koda dökerseniz her ay yeniden yazdırırsınız. Önce süreci birkaç ay elle ve sabit bir şekilde çalıştırın.
• ✕Asıl sorun verideÜrün kodları iki sistemde tutarsızsa, entegrasyon bu tutarsızlığı daha hızlı çoğaltır. Önce veri temizliği, sonra entegrasyon.
• ✕ERP'nin kendisi değişmek üzereAltı ay içinde ERP değiştirecekseniz, eski sisteme yazılan entegrasyon büyük ölçüde çöpe gider. Logo tarafında sürüm ve ürün seçimini Logo Go3 mü, Tiger 3 mü yazısında anlatıyoruz.

Öte yandan iş kuralının ağır olduğu yerde özel katman gerçekten fark yaratır. Kendi ürünümüz TYS bunun iyi bir örneği: teklif hazırlanırken cari, ürün, fiyat ve stok Logo'dan okunuyor, onaylanan teklif Logo'ya sipariş olarak yazılıyor ve aktarım sonrası mutabakat kontrolü yapılıyor. Bu kadar iş kuralını hazır bir modülün ayar ekranına sığdırmak mümkün değil.

Logo özelinde entegrasyon ve raporlama ihtiyaçları için Logo ERP çözüm ortaklığı hizmetimize ve Logo ERP için özel entegrasyon ve rapor sayfasına; e-ticaret, B2B ve ERP akışlarının ayrıntısı için Logo ERP entegrasyonu rehberimize göz atabilirsiniz. Birden fazla sistemi tek veri modelinde toplamak istiyorsanız sistem birleştirme için API geliştirme, e-ticaret kanallarınız için e-ticaret entegrasyonları için API geliştirme sayfaları daha yakın senaryolar.

Sık Sorulan Sorular