API Sürümü Tek Taraflı Kaldırılırsa Entegrasyon Masrafını Kim Öder?

API sağlayıcısının eski sürümü veya sözleşmede üstlendiği işlevi kaldırması, değişiklik yetkisi ve geçiş taahhütleri üzerinden incelenir. TBK m.24, genel işlem koşullarını düzenleyene karşı taraf aleyhine tek yanlı değişiklik yetkisi veren kayıtları yazılmamış sayar. Ancak bu kural, bütün API sürümlerinin süresiz korunması gerektiği anlamına gelmez.

Entegrasyon masrafının karşı taraftan istenmesi için sözleşmesel borç, ihlal ve gider arasındaki bağ gösterilmelidir. Sağlayıcının sorumluluğu, müşterinin uyum görevi ve entegrasyonu geliştiren firmanın bakım borcu ayrı belirlenir; aynı teknik değişiklik her sözleşmede aynı sonucu doğurmaz.

API değişikliği hangi sözleşmesel hizmeti etkiler?

API, uygulamaların belirli kurallarla birbirine veri veya işlem iletmesini sağlayan arayüzdür. İşletme bu arayüz üzerinden sipariş aktarımı, stok güncellemesi, raporlama veya muhasebe bağlantısı kurmuşsa sürüm değişikliği yalnız yazılım ekibinin meselesi değildir. Önce arayüze erişimin sözleşmede nasıl tanımlandığı belirlenir. Ana hizmet paketinin parçası, ayrıca ücretli bir özellik, sınırlı deneme imkânı veya bağımsız bir üçüncü kişi hizmeti olması, sağlayıcının üstlendiği borcun kapsamını değiştirir.

TBK m.19 ve 26 uyarınca gerçek sözleşme içeriği ve kanunun sınırları içindeki taraf iradesi esas alınır. API’nin sözleşmede hiç anılmaması, her teknik belgeyi önemsiz hale getirmez; teklif, sipariş formu, kabul edilen ekler ve yazışmalar birlikte incelenir. Bununla birlikte kamuya açık bir geliştirici sayfasının bulunması da tek başına belirli sürümün süresiz korunacağı taahhüdünü göstermez. Hangi belgeye hangi tarihte dayanılarak sözleşme kurulduğu ispatlanmalıdır.

Mevcut entegrasyonun ne yaptığı da açıkça yazılır. Sadece veri okuyan bağlantı ile şirket adına işlem oluşturan bağlantı aynı işlevi taşımaz. Dönen veri alanının kaldırılması, kimlik doğrulama yönteminin değiştirilmesi, çağrı sınırının daraltılması ve eski sürümün tamamen kapatılması farklı teknik olaylardır. Hukuki talep bunların hangisinin gerçekleştiğine dayanıyorsa o değişiklik somutlaştırılır. “API bozuldu” cümlesi, hangi sözleşmesel edimin yerine getirilmediğini açıklamak için tek başına yeterli değildir.

Her güncelleme borca aykırılık veya ücretsiz uyarlama hakkı doğurur mu?

Yazılım hizmetinin sürmesi, bütün teknik ayrıntılarının sonsuza kadar aynı kalacağı anlamına gelmez. Taraflar belirli sürümün destek süresini, değişiklik takvimini, eski ve yeni sürümün birlikte çalışacağı dönemi ve müşterinin uyarlama görevlerini kararlaştırmış olabilir. Böyle bir düzenleme varsa gerçek değişiklik bu şartlarla karşılaştırılır. Sağlayıcının taahhüt ettiği uyumluluk alanı ile müşterinin kendi uygulamasında üstlendiği geliştirme faaliyeti ayrılır. Geçerli kapsam içinde yapılan güncelleme otomatik olarak tazminat doğurmaz.

Diğer taraftan API erişimi sözleşmenin belirli işlevi olarak satılmış ve belirli süre korunması üstlenilmişse, bu işlevin ortadan kaldırılması yalnız “ürün kararı” denilerek sözleşme dışına çıkarılamaz. Ücretli bağlantının çalışmaması, sözleşmedeki değişiklik yetkisi ve sorumluluk hükümleriyle birlikte incelenir. SaaS sözleşmesinde API ve entegrasyon kapsamı, genel sözleşme hazırlığı bakımından yararlıdır. Buradaki inceleme, yapılmış değişikliğin mevcut müşteri ilişkisine ve uyarlama giderine etkisidir.

TBK m.24, sınırsız değişiklik yetkisini nasıl sınırlar?

TBK m.20’deki tanıma göre sağlayıcının çok sayıda benzer sözleşmede kullanmak üzere önceden tek taraflı hazırladığı hükümler genel işlem koşuludur. Bu nitelikteki sözleşmelerde, düzenleyene karşı taraf aleyhine tek yanlı değişiklik veya yeni düzenleme yapma yetkisi veren kayıtlar TBK m.24 gereğince yazılmamış sayılır. Dolayısıyla “tüm API özelliklerini dilediğimiz an değiştirebiliriz” kaydı, koşulları gerçekleştiğinde bu hükümle denetlenir. Mesele yalnız bildirimin yapılıp yapılmadığı değildir; değişiklik yetkisinin kanunen geçerli kapsamı önce belirlenir.

Önceden taraflarca belirlenmiş nesnel sürüm takvimi ile sağlayıcının istediği anda istediği işlevi kaldırma yetkisi aynı düzenleme değildir. TBK m.24, her teknik güncellemenin yasaklandığı anlamına gelmez. Bunun karşılığında müşteriye bir e-posta gönderilmesi, kanuna aykırı sınırsız değişiklik yetkisini kendiliğinden geçerli hale getirmez. Hangi kayıtların standart olduğu, hangilerinin özel müzakere edildiği ve uyuşmazlık konusu değişikliğin müşterinin durumunu nasıl etkilediği ayrı gösterilir.

Genel işlem koşullarının sözleşmeye girişi TBK m.21; belirsiz ifadelerin yorumu m.23; dürüstlük kuralına aykırı ağırlaştırıcı içerik ise m.25 kapsamında ayrıca ele alınır. Genel şartların sözleşmeye dahil edilmesi ile değişiklik yasağı farklı denetim aşamalarıdır. Bu nedenle şirketin ilk kurulumda şartları kabul etmiş olması bütün sonraki sürümlere sınırsız onay verdiği biçiminde okunmaz. Yeni teklif ve gerçekten verilen kabul, kendi tarih ve kapsamıyla incelenir.

Uyuşmazlıkta hangi sözleşme ve teknik belge sürümü kullanılır?

Başlangıç sözleşmesi, API ekleri, geliştirici dokümanı, değişiklik duyurusu ve müşterinin verdiği cevap ayrı sürümler halinde saklanır. İnternet sayfasının bugün görünen içeriği, geçmişte müşteriye hangi taahhüdün sunulduğunu her zaman göstermez. Belgenin alınma tarihi, yürürlük tarihi, ilgili hesabın kabul kaydı ve varsa önceki kopya birlikte korunur. Sonradan hazırlanmış teknik açıklama, tarafların geçmişte farklı bir kapsam üzerinde anlaştığına ilişkin belgelerin yerine geçirilmez.

Değişiklik dosyası, eski ve yeni yapının karşılaştırmasını da içermelidir. Kaldırılan işlevin adı, veri alanı, kimlik doğrulama yöntemi veya kapasite sınırı açıkça belirtilir. Değişikliğin uygulandığı gün, duyurunun ulaştığı gün ve müşterinin geçiş hazırlığına başladığı gün farklıysa her biri gösterilir. API anahtarlarının kendisi açık raporlarda paylaşılmadan hesap ve uygulama kimliği belirlenir. Amaç, güvenlik sırlarını yaymak değil, hangi bağlantının hangi değişiklik nedeniyle durduğunu doğrulamaktır.

Bağlantının yanıt vermesi, işlemin doğru tamamlandığını tek başına göstermez. Yeni sürümde alanların anlamı, para birimi, tarih bilgisi veya işlem kimliğinin kullanımı değişmişse veri aktarımı görünüşte başarılı olduğu halde işletme kaydı hatalı oluşabilir. Bu nedenle karşılaştırma yalnız bağlantı kurulup kurulmadığına indirgenmez; kaynak işlem ile hedef sistemdeki sonuç eşleştirilir. Hangi işlemlerin yeniden gönderildiği ve hangilerinin düzeltildiği de kaydedilir. Aksi halde aynı siparişin tekrar işlenmesiyle ilk değişikliğin doğurduğu kayıp birbirine karışır.

Değişiklik önceden bildirildiğinde hangi sorular cevaplanır?

Bildirimin içeriği, yalnız “yeni sürüme geçiyoruz” cümlesiyle sınırlı kalmamalıdır. Sözleşmede üstlenilen bildirim düzeni bakımından etkilenen işlevler, eski sürümün son günü, yeni teknik dokümana erişim ve test ortamı değerlendirilir. Şirket bildirimi aldıktan sonra kendi uygulamasının gerçekten etkilenip etkilenmediğini belirler. Sağlayıcı da gönderim ve ulaştırma kayıtlarını korur. Bütün API sözleşmeleri için kanunda tek bir genel geçiş gün sayısı varmış gibi açıklama yapılmaz; özel düzenlemeler varsa ayrıca incelenir.

Geçiş için fiilen yapılması gereken işler; bağlantı kodu, test verisi, yetki düzeni, işlem kontrolü ve canlıya alma takvimiyle belirlenir. Müşteri önceden kendisine sağlanan uyum imkânını kullanmamışsa bu olgu sorumluluk ve zarar hesabında önem taşır. Ancak yeni sürümün belgeleri veya gerekli erişim sağlanmadıysa geçişin neden tamamlanamadığı da kayda geçirilir. Taraflardan birinin bütün gecikmeyi diğerine yüklemesi yerine, hangi işin kimin kontrolünde olduğu zaman çizelgesinde gösterilir.

Yeni sürüme teknik geçiş yapılması, geçmişteki her ihlalin kabul edildiği veya bütün zarar taleplerinden vazgeçildiği anlamına kendiliğinden gelmez. Geçiş anlaşmasında ayrıca feragat, ibra veya kapsamlı hesap kapatma ifadesi bulunuyorsa bunun sonucu ayrıca değerlendirilir. İşletmenin faaliyetini devam ettirmek için bağlantıyı uyarlaması ile tüm hukuki talepleri sona erdirmesi ayrı irade açıklamalarıdır. Yeni lisans, yeni ücret veya yeni kullanım sınırı kabul edilecekse değişen ekonomik koşullar da kayıtta gösterilmelidir.

Güvenlik gerekçesiyle acil değişiklik yapılmışsa ne incelenir?

Gerçek bir güvenlik sorunu ile gerekçesi açıklanmayan ticari ürün değişikliği aynı değerlendirmeye tabi değildir. Sözleşmede acil güvenlik müdahalesi için düzenleme varsa, olayın o düzenlemenin kapsamına girip girmediği araştırılır. Etkilenen bağlantı, riskin niteliği, zorunlu müdahalenin kapsamı ve işlevin yeniden sağlanması için yapılan işlemler belgelenir. Teknik sırların açıklanmasını gerektirmeyen, ancak müdahalenin nedenini ve sonucunu değerlendirmeye yarayan olay kaydı istenir.

Güvenlik gerekçesi ileri sürülmesi, sağlayıcının sözleşmeye ilişkin bütün yükümlülüklerini otomatik kaldırmaz. Bildirim, alternatif erişim veya önceden üstlenilen geçiş desteği varsa bunların yerine getirilmesi ayrıca incelenir. Aynı biçimde müşterinin tehlikeli bağlantının aynen açık tutulmasını koşulsuz bir hak olarak ileri sürmesi de doğru değildir. TBK m.112 kapsamında hangi borcun ihlal edildiği ve sağlayıcının kusursuzluk savunması somut olayla değerlendirilir; güvenlik müdahalesi etiketi tek başına sonucun yerine geçmez.

Uyarlama ücretini API sağlayıcısı mı, yazılımı yapan firma mı karşılar?

API sağlayıcısı ile müşterinin entegrasyonunu geliştiren firma aynı kişi değilse iki sözleşme ayrı incelenir. Sağlayıcının erişim ve sürüm taahhüdü ile yazılım firmasının teslim, bakım ve uyarlama borçları karıştırılmamalıdır. Yazılım firması her dış sistem değişikliğini süresiz ve ücretsiz karşılamayı üstlenmiş sayılmaz. Sözleşmede bakımın hangi güncellemeleri kapsadığı, belirli sürümlere destek verilip verilmediği ve ek geliştirme onayının nasıl alındığı belirlenir. Mevcut bedelin kapsamı buna göre açıklanır.

Eser niteliğindeki entegrasyon geliştirmesinde TBK m.471, yüklenicinin sadakat ve özen borcunu düzenler. Buna karşılık devam eden işgörme faaliyetinin vekâlet niteliği taşıdığı ölçüde TBK m.502 ve 506 incelenir. Bu maddelerden, her teknik değişikliğin her durumda ücretsiz yapılacağı sonucu çıkarılmaz. Yazılım firmasının önceden bildirilen sürüm kapanışını görmezden gelmesi ile müşterinin sonradan yeni bir işlev istemesi farklıdır. Talep, üstlenilen belirli edimin yerine getirilmemesine dayanmalıdır.

Şirket yeni firmadan uyarlama hizmeti alıyorsa iş emri, ilk kapsamı eski işlevin geri getirilmesiyle sınırlı biçimde göstermelidir. Aynı çalışma sırasında yeni rapor, yeni modül veya farklı tasarım yapılırsa bunların gideri ayrılır. Sağlayıcıdan talep edilen masrafın, API değişikliğinin zorunlu sonucu olduğu açıklanmalıdır. TBK m.113 kapsamındaki başkasına yaptırma izni ile şirketin kendi kararıyla acil gider yapıp sonradan zarar talep etmesi aynı hukuki yol değildir; talebin dayanağı doğru kurulmalıdır.

Entegrasyon değişikliğinden doğan zarar nasıl hesaplanır?

TBK m.112 uyarınca borca aykırılık nedeniyle tazminat isteyen şirket; edimi, ihlali, zararı ve nedensellik bağını ortaya koyar. Borçlu, kendisine kusur yüklenemeyeceğini ispat etmedikçe bu zarardan sorumludur. Yeni geliştirici faturası tek başına bütün giderin karşı tarafa ait olduğunu göstermez. Faturanın hangi iş için kesildiği, bu işin neden gerekli hale geldiği, önceki sistemin hangi işlevi geri kazandığı ve bedelin kapsamı teknik açıklamayla birleştirilir.

İşletme kaybında siparişlerin yeniden girilmesi, veri eşleştirilmesi ve zorunlu geçici işlem maliyeti gibi kalemler ayrı gösterilir. Bir işlem iki kez oluşmuşsa düzeltme kaydı; aktarım hiç gerçekleşmemişse kaynak ve hedef sistem karşılaştırması korunur. Genel satış düşüşünün tamamını API değişikliğine bağlamak yerine hangi işlemlerin hangi dönemde aksadığı açıklanır. Uyarlama gideri ile aynı gideri içeren başka bir tazminat kalemi yinelenmez. Elde edilen yeni ve bağımsız geliştirme faydası da hesap dışında bırakılmaz.

TBK m.114/2 aracılığıyla m.52, zarar görenin zararın meydana gelmesine veya artmasına etkisini değerlendirmeye imkan verir. Müşterinin sözleşmeye uygun bildirime rağmen gerekli testi yapmaması, kendi kodundaki bağımsız hata veya değişiklikle ilgisiz bağlantı sorunu bu kapsamda somutlaştırılır. Her müşteri hatası bütün zararı ortadan kaldırmaz; hangi kayıp üzerinde etkili olduğu belirlenir. Şirketin geçişi kolaylaştırmak için yaptığı işbirliği ve eksik belge talepleri de dosyaya eklenir.

İfa talebi, süre verilmesi ve fesih nasıl ayrılır?

İhtarda eski sürümün koşulsuz ve süresiz açık tutulması gibi sözleşmede bulunmayan bir edim talep edilmez. Sağlayıcının üstlendiği erişimin geri sağlanması, geçiş dokümanının sunulması, sözleşmesel desteğin verilmesi veya belirli uyarlama giderinin karşılanması ayrı başlıklar halinde yazılır. TBK m.117 uyarınca muaccel borç ve temerrüt koşulları belirlenir. Tacirler arasındaki ilgili bildirimlerde TTK m.18/3 gözetilir; teknik destek kaydı ile hukuki ihtar birbirini tamamlar.

Temerrütte TBK m.123 uygun süre verilmesini, m.124 süre gerektirmeyen durumları, m.125 ise seçimlik hakları düzenler. İfasına başlanmış sürekli edimli ilişkide TBK m.126 ayrıca önem taşır. API hizmetinin niteliği ve sözleşmenin hangi aşamada olduğu belirlenmeden her dosyada aynı dönme veya fesih ifadesi kullanılmaz. Konunun bildirim yönü tacirler arasında ihtar yöntemleri rehberinde açıklanır. Talep, teknik olarak yerine getirilebilir ve hukuken üstlenilmiş edime yönelmelidir.

Teknik deliller mahkemeye nasıl hazırlanır?

HMK m.199 elektronik kayıtları belge kapsamına alır; m.194 ise vakıaların somutlaştırılmasını ve delillerin hangi vakıayı ispatladığının gösterilmesini gerektirir. Kayıtlar eski ve yeni sürüm karşılaştırması, olay zaman çizelgesi ve gider listesiyle düzenlenir. Ekran görüntüsünün yanında özgün günlük dosyaları ve teknik raporlar saklanır. Şirketin bütün müşteri verileri dosyaya gelişigüzel eklenmez; incelemeye gerekli olay ve işlem kayıtları belirlenir.

Eski dokümanın kaldırılması veya günlüklerin silinmesi tehlikesi varsa HMK m.400’deki hukuki yarar koşullarıyla delil tespiti istenir. Tespitin konusu belirli API, sürüm, işlem ve dönemle tanımlanır. Ticari nitelikteki para veya tazminat davasında TTK m.5/A kapsamı ve dava şartı arabuluculuk incelenir. Sağlayıcı yurt dışındaysa uygulanacak hukuk ve uyuşmazlık çözüm hükmü ayrıca değerlendirilir; Türk şirketinin müşteri olması tek başına bütün sözleşmenin Türk hukukuna tabi olduğunu göstermez.

Sık sorulan sorular

API sağlayıcısı eski sürümü hiçbir zaman kapatamaz mı?

Böyle genel bir kural yoktur. Sözleşmedeki sürüm, destek ve geçiş taahhütleri belirlenir. Geçerli kapsam içinde yapılan güncelleme ile taahhüt edilmiş işlevin kaldırılması ayrılır. Standart şarttaki karşı taraf aleyhine sınırsız değişiklik yetkisi TBK m.24 kapsamında denetlenir.

Değişiklik e-postası TBK m.24 sorununu çözer mi?

Tek başına çözmez. Önce değişiklik yetkisinin geçerli kapsamı belirlenir. TBK m.24 koşulları gerçekleşmişse, müşteriye bildirim yapılması yazılmamış sayılan sınırsız yetki kaydını geçerli hale getirmez. Bildirimin sözleşmeye uygun ifası ayrıca incelenir.

API için kanunen sabit bir geçiş süresi var mı?

Bütün API sözleşmelerine uygulanacak tek bir genel gün sayısı bu hükümlerden çıkmaz. Sözleşmedeki takvim, kapsam, bildirim borcu ve varsa özel düzenleme incelenir. Sağlayıcının verdiği teknik imkânlar ile müşterinin üstlendiği geçiş işleri birlikte değerlendirilir.

Kamuya açık API dokümanı sözleşmenin parçası mıdır?

Dokümana nasıl atıf yapıldığı, müşteriye ne zaman sunulduğu ve hangi kapsamın kabul edildiği araştırılır. Kamuya açık bulunması tek başına süresiz destek taahhüdü oluşturmaz. Sözleşmeye dahil edilen teknik ekler ve kabul edilen sürüm belgeleri ise borcun kapsamının belirlenmesinde kullanılır.

Güvenlik nedeniyle yapılan her değişiklik sorumluluğu kaldırır mı?

Hayır. Gerçek risk, sözleşmedeki acil müdahale yetkisi, işlemin kapsamı ve üstlenilmiş bildirim veya destek borçları incelenir. TBK m.112 uyarınca ihlal ve kusursuzluk savunması somut olayla değerlendirilir. Güvenlik gerekçesi bütün yükümlülükleri otomatik ortadan kaldırmaz.

Entegrasyonu yapan firma tüm API değişikliklerini ücretsiz düzeltir mi?

Ücretsiz uyarlama kapsamı sözleşmeden belirlenir. Geliştirme, bakım ve dış sistem güncellemesine uyum farklı edimlerdir. Eser niteliğinde TBK m.471, vekâlet niteliğindeki işgörmede m.502 ve 506 dikkate alınır; bu maddeler sınırsız ücretsiz geliştirme hakkı yaratmaz.

Yeni yazılımcının faturasının tamamı sağlayıcıdan istenir mi?

Fatura, giderin API değişikliğiyle bağını tek başına ispatlamaz. Eski işlevi geri getiren zorunlu çalışma ile yeni özellik geliştirmesi ayrılır. TBK m.112 kapsamında ihlal, zarar ve nedensellik bağı gösterilir; aynı gider farklı taleplerde tekrarlanmaz.

Yeni sürüme geçmek eski taleplerden vazgeçmek anlamına gelir mi?

İşin devamı için teknik geçiş yapılması ile sulh, ibra veya feragat ayrı işlemlerdir. Geçişte imzalanan veya kabul edilen metnin tam içeriği incelenir. Kapsamlı kapanış anlaşması varsa etkisi ayrıca değerlendirilir; sırf geçiş yapıldığı için bütün taleplerin bittiği söylenmez.

Eski teknik belgeler silinirse hangi delil yolu kullanılır?

Kaybolma veya daha sonra ileri sürmenin önemli ölçüde zorlaşması tehlikesi somutsa HMK m.400 kapsamında delil tespiti değerlendirilir. İlgili API, sürüm, tarih ve işlem açıkça tanımlanır. Elde bulunan elektronik kayıtlar HMK m.199 çerçevesinde kaynak bilgisiyle korunur.

API sağlayıcısına her durumda Türk mahkemesinde dava açılır mı?

Uygulanacak hukuk, görev, yetki ve varsa uyuşmazlık çözüm şartı ayrı belirlenir. Sağlayıcının yeri ve sözleşmenin milletlerarası niteliği önemlidir. Ticari para veya tazminat davası TTK m.5/A kapsamındaysa dava öncesi arabuluculuk şartı da incelenir.

İstanbul ve Mersin ofislerinde API değişikliği dosyaları, sözleşme sürümü ile teknik olayın zaman çizelgesi eşleştirilerek değerlendirilir. İlk inceleme için eski ve yeni doküman, değişiklik bildirimi, etkilenen işlem listesi, entegrasyon sözleşmesi ve uyarlama giderleri hazırlanmalıdır. API anahtarları ve erişim sırları açık yazışmalarda gönderilmemelidir. Türkiye genelindeki ticari dosyalarda görev, yetki, uygulanacak hukuk ve arabuluculuk şartı sözleşmenin tarafları ve talep kapsamıyla birlikte ele alınır.

Kanun maddeleri ve resmî kaynaklar

• 6098 sayılı Türk Borçlar Kanunu — güncel resmî UYAP metni: m.19–21, 23–26, 52, 112–114, 117, 123–126, 471, 502, 506
• 6102 sayılı Türk Ticaret Kanunu — güncel resmî UYAP metni: m.5/A, 18/3
• 6100 sayılı Hukuk Muhakemeleri Kanunu — güncel resmî UYAP metni: m.194, 199, 400

Av. Halil Bakırcı tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

Avukat Halil BAKIRCI, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Av. Halil Bakırcı profilini inceleyin →