API'ler ve Veri Akışı: Entegrasyonlarda KVKK Sorumluluğu (2026)

Yazarlar: Av. Mert Güneş & Av. Melis Güneş — Güneş Partners kurucu ortakları Son güncelleme: Mayıs 2026

TL;DR — Bu Yazının Özeti

• Her API entegrasyonu potansiyel bir kişisel veri akışı noktasıdır; her akış için KVKK değerlendirmesi zorunludur.
• Üçüncü taraf API'ye kişisel veri göndermek, sunucu yurt dışındaysa yurt dışı veri aktarımı sayılır; standart sözleşme gerektirir.
• Webhook tabanlı sistemlerde veri akışı otomatik ve süreklidir; hangi kişisel verinin nereye gittiğinin izlenmesi daha zordur.
• OAuth scope tasarımı veri minimizasyonu ilkesinin doğrudan teknik karşılığıdır: yalnızca gerekli kapsamda erişim yetkisi talep edilmelidir.
• API logları neredeyse her zaman PII (Personally Identifiable Information) içerir; IP adresi, kullanıcı ID, istek parametreleri KVKK kapsamındadır.
• Rate limiting, KVKK'nın "veri güvenliği yükümlülüğü" kapsamında değerlendirilebilir; yeterli rate limiting yokluğu güvenlik açığı oluşturur.
• Üçüncü taraf API kullanımı aydınlatma metninde aktarılan alıcı grupları bölümünde belirtilmelidir.

API Entegrasyonları Neden KVKK Kapsamında?

Modern yazılım mimarisi onlarca üçüncü taraf API ile entegre çalışır. Ödeme işlemi Stripe'a, e-posta SendGrid'e, analitik Mixpanel'e, kimlik doğrulama Auth0'a, CRM Salesforce'a gider. Bu entegrasyonların her biri potansiyel bir kişisel veri akışı noktasıdır.

KVKK açısından kritik olan soru şudur: bu API çağrısında kişisel veri var mı ve bu veri nereye gidiyor?

Üç temel risk alanı mevcuttur.

Veri işleyen ilişkisi: API sağlayıcısı veriyi sizin adınıza işliyorsa veri işleyendir ve DPA zorunludur.

Yurt dışı aktarım: API sağlayıcısının sunucusu yurt dışındaysa her çağrı KVKK m. 9 kapsamındadır.

Amaç dışı işleme: API sağlayıcısı gelen veriyi kendi amaçları için de kullanıyorsa bağımsız veri sorumlusu haline gelir; bu durumda aydınlatma ve hukuki dayanak yeniden değerlendirilmelidir.

API Veri Akışı Haritalama

KVKK uyumunun ilk adımı, uygulamanızdaki tüm API çağrılarında kişisel verinin nereye aktığını haritalamaktır.

Veri Akışı Haritası Nasıl Çıkarılır?

Her API entegrasyonu için şu soruları yanıtlayın.

Request: Bu API çağrısında kullanıcıya ait hangi kişisel veri gönderiliyor? (Kullanıcı ID, e-posta, IP adresi, konum, davranış verisi)

Response: API'nin döndürdüğü yanıt kişisel veri içeriyor mu?

Sağlayıcı rolü: Bu API sağlayıcısı veri işleyen mi, yoksa bağımsız veri sorumlusu mu?

Lokasyon: Sağlayıcının sunucusu nerede?

DPA durumu: Sağlayıcıyla veri işleme sözleşmesi var mı?

Aydınlatma: Bu aktarım aydınlatma metninde belirtildi mi?

Webhook'larda Kişisel Veri Akışı

Webhook, bir olay gerçekleştiğinde bir sistemin diğer sisteme otomatik HTTP isteği göndermesidir. REST API'den temel farkı: REST'te istemci veri ister, webhook'ta veri otomatik olarak push edilir.

Webhook'ların KVKK Açısından Özgün Riskleri

Sürekli ve otomatik akış: Webhook kurulduktan sonra her tetikleme olayında veri akar; bu akış manuel müdahale gerektirmez. Hangi verinin ne zaman, nereye aktığını takip etmek zorlaşır.

Endpoint güvenliği: Webhook endpoint'i yetersiz güvence altındaysa yetkisiz kişiler sahte istek göndererek sistemi manipüle edebilir veya veri sızmasına zemin hazırlayabilir.

Veri kapsamı kontrolsüzlüğü: Tetikleme olayında gereksiz alanların da otomatik olarak gönderilmesi yaygın bir tasarım hatasıdır. "Sipariş tamamlandı" olayında müşterinin tüm profil verisi gönderiliyorsa veri minimizasyonu ilkesi ihlal edilir.

Webhook Güvenliği için KVKK Uyum Adımları

1. Payload minimizasyonu: Webhook payload'ı yalnızca alıcı sistemin gerçekten ihtiyaç duyduğu alanları içermelidir. Tüm nesneyi göndermek yerine, yalnızca gerekli alanları seçmek veri minimizasyonu ilkesinin teknik karşılığıdır.

2. Payload imzalama: Webhook isteklerinin gerçekten beklenen kaynaktan geldiğini doğrulamak için HMAC-SHA256 imzalama uygulanmalıdır. Stripe, GitHub ve Shopify bu yaklaşımı standart olarak kullanır.

3. HTTPS zorunluluğu: Webhook endpoint'i yalnızca HTTPS üzerinden çalışmalıdır; şifrelenmemiş HTTP üzerinden kişisel veri içeren webhook kabul edilmemelidir.

4. Retry mekanizması ve log yönetimi: Webhook'un başarısız teslimat halinde yeniden deneme (retry) logları tutulur. Bu loglar zaman içinde kişisel veri biriktirebilir; log retention politikası uygulanmalıdır.

5. IP kısıtlaması: Mümkünse webhook trafiği yalnızca beklenen kaynak IP aralığından kabul edilmelidir.

OAuth Scope Tasarımı ve Veri Minimizasyonu

OAuth, kullanıcının kimlik bilgilerini paylaşmadan üçüncü taraf uygulamalara belirli kaynaklara erişim izni vermesini sağlar. "Scope" (kapsam), tanımlanan erişim sınırlarıdır.

OAuth Scope Veri Minimizasyonu İlkesinin Teknik Karşılığıdır

KVKK'nın 4. maddesindeki "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesi, OAuth scope tasarımında doğrudan uygulanabilir bir prensibe dönüşür: uygulamanız yalnızca gerçekten ihtiyaç duyduğu scope'ları talep etmelidir.

Kötü tasarım örnekleri:

Yalnızca e-posta adresi gerektiği halde read:user (tüm profil), read:followers (takipçiler) ve read:email birlikte talep edilmesi aşırı scope kullanımıdır. Bu durum kullanıcının gereğinden fazla veri paylaşmasına neden olur ve veri minimizasyonu ilkesini ihlal eder.

İyi tasarım örnekleri:

Yalnızca e-posta adresi gerekiyorsa yalnızca email scope talep edilir. Yalnızca profil fotoğrafı gerekiyorsa yalnızca profile scope talep edilir.

Scope Değişikliklerinde Yeniden Aydınlatma

Uygulama sonradan ek scope talep etmeye başlarsa, bu yeni veri işleme faaliyeti için kullanıcının yeniden aydınlatılması ve rıza alınması gerekir. "Uygulamamızı güncelledik, lütfen yeniden giriş yapın" ekranı aydınlatma yükümlülüğünü karşılamaz; hangi ek izinlerin neden istendiği açıkça belirtilmelidir.

Token Yönetimi

OAuth token'ları dolaylı olarak kişisel veriye erişim anahtarıdır. Token güvenliği KVKK'nın teknik güvenlik yükümlülüğü kapsamındadır.

Access token'ları mümkün olan en kısa süre geçerli olacak şekilde yapılandırılmalıdır. Refresh token'lar güvenli depolama ortamında (KeyStore, Keychain veya encrypted storage) tutulmalıdır. Kullanıcı hesabını sildiğinde veya bağlantıyı kestiğinde tüm token'lar geçersiz kılınmalıdır.

Rate Limiting ve KVKK Güvenlik Yükümlülüğü

Rate limiting, bir API'ye belirli süre içinde yapılabilecek istek sayısını sınırlayan güvenlik mekanizmasıdır. Doğrudan KVKK metinlerinde yer almaz; ancak KVKK'nın 12. maddesindeki "veri güvenliği için gerekli teknik tedbirler" kapsamında değerlendirilebilir.

Rate Limiting Neden KVKK İlişkili?

Veri sızdırma saldırıları (enumeration attacks): Rate limiting olmayan bir API, saldırganın sistematik biçimde kullanıcı verilerini çekmesine imkân tanır. Bir saldırgan saniyede binlerce kullanıcı ID'si deneyerek müşteri profillerini toplayabilir. Bu, KVKK kapsamında veri güvenliği ihlali oluşturabilir.

Kimlik bilgisi doldurma (credential stuffing): Giriş API'sinde rate limiting yoksa otomatik araçlarla binlerce kullanıcı adı/şifre kombinasyonu denenebilir. Başarılı girişlerden elde edilen kişisel verilere erişim bir veri ihlali oluşturur.

Kurul savunmasında rate limiting: Bir ihlal yaşandığında Kurul, "gerekli teknik tedbirler alındı mı?" sorusunu sorar. Rate limiting, brute force koruması ve anomali tespiti bu sorunun yanıtında kritik delillerdir. Yokluğu ağırlaştırıcı faktördür.

Minimum Rate Limiting Standartları

Kimlik doğrulama endpoint'leri (login, password reset): 5 dakikada IP başına 5-10 başarısız denemeden sonra geçici engelleme. Veri okuma endpoint'leri: kullanıcı başına dakikada makul bir üst limit. Webhook receiver'ları: kaynak IP bazlı kısıtlama. Toplu (bulk) işlem endpoint'leri: özellikle sıkı sınırlandırma.

API Loglarında PII Yönetimi

API logları, neredeyse kaçınılmaz biçimde kişisel veri içerir. Kimlik doğrulama loglarında kullanıcı ID ve IP adresi, istek loglarında sorgu parametrelerindeki e-posta veya telefon numarası, hata loglarında exception mesajlarında sızan kişisel veriler buna dahildir.

Bu loglar KVKK kapsamında kişisel veri niteliğindedir ve veri minimizasyonu, saklama süresi ve güvenlik yükümlülüklerine tabidir.

PII Sınıflandırması: Logda Neler Var?

Log PII Azaltma Teknikleri

1. Log maskeleme: Belirli alanların log'a yazılmadan önce otomatik olarak maskelenmesi. Kredi kartı numaraları ve şifreler için yaygın; T.C. kimlik numarası ve sağlık verisi için de uygulanmalıdır.

2. Log seviyesi yönetimi: Debug log'lar üretim ortamında kapalı tutulmalıdır. Tüm istek/yanıt gövdesinin loglandığı debug modu yalnızca geliştirme ortamında aktif olmalıdır.

3. Structured logging ile alan kontrolü: Freeform metin loglama yerine yapılandırılmış (JSON) loglama kullanıldığında hangi alanların loglandığı kontrol edilebilir; PII içeren alanlar listeye eklenmez.

4. Log anonimleştirme:

IP adreslerinin son oktetinin maskelenmesi (192.168.1.xxx → 192.168.1.0) sık başvurulan bir yöntemdir. Ancak bu pseudo-anonimleştirmedir; tam anonimleştirme sayılmaz ve KVKK kapsamından çıkmaz.

5. Log saklama süresi:

Log saklama süresi KVKK'nın ölçülülük ilkesine uygun belirlenmeli ve süre dolan loglar otomatik silinmelidir. Güvenlik logları için 1 yıl, uygulama logları için 90 gün yaygın uygulamadır. Süresiz log saklama hukuka aykırıdır.

6. Log şifreleme:

Log dosyaları dinlenimde (at rest) şifreli olmalıdır. Merkezi log yönetim sistemlerine (Datadog, Elasticsearch, Splunk) aktarım da yurt dışı veri aktarımı kapsamındadır ve standart sözleşme gerektirir.

Üçüncü Taraf API Kullanırken Aydınlatma Metni Güncellemeleri

Üçüncü taraf API entegrasyonları, kullanıcıların kişisel verilerinin üçüncü taraflara aktarıldığı anlamına gelir. KVKK m. 10 uyarınca bu aktarımların aydınlatma metninde belirtilmesi zorunludur.

Aydınlatma Metninde API Entegrasyonları Bölümü

Aydınlatma metninin "kişisel verilerin aktarıldığı alıcı grupları" bölümü güncel API entegrasyonlarını yansıtmalıdır. Soyut ifadeler yeterli değildir: "iş ortakları" veya "hizmet sağlayıcılar" gibi genel ifadeler yerine, aktarılan veri türü ve amaç bazında somut açıklama yapılmalıdır.

Örnek aydınlatma metni ifadeleri:

"Ödeme işlemlerinin gerçekleştirilmesi amacıyla ad, soyad ve ödeme bilgileriniz, ödeme altyapı sağlayıcısı [Şirket Adı] ile paylaşılmaktadır. Bu aktarım [ABD/AB] konumlu sunuculara yapılmakta olup KVKK m. 9 kapsamında [standart sözleşme] güvencesiyle gerçekleştirilmektedir."

"E-posta bilgilendirmelerinin gönderilmesi amacıyla e-posta adresiniz, e-posta hizmet sağlayıcısı [Şirket Adı] ile paylaşılmaktadır."

"Kullanım istatistiklerinin analiz edilmesi amacıyla çerez verileriniz ve IP adresiniz, analitik hizmet sağlayıcısı [Şirket Adı] ile paylaşılmaktadır."

Yeni API Entegrasyonunda Aydınlatma Güncelleme Zorunluluğu

Yeni bir üçüncü taraf API entegrasyonu eklendiğinde aydınlatma metni derhal güncellenmelidir. Güncelleme öncesi yapılan aktarımların da hukuki dayanak sorunu oluşturabileceği unutulmamalıdır.

GraphQL ve REST API'lerinde Veri Minimizasyonu

GraphQL, istemcinin tam olarak hangi alanları istediğini belirleyebildiği bir sorgulama dilidir. Bu özellik KVKK'nın veri minimizasyonu ilkesiyle doğal bir uyum sağlar.

REST API: Aşırı Veri Aktarımı Sorunu

Geleneksel REST API'lerde bir endpoint tüm nesneyi döndürür: GET /users/123 çağrısı yalnızca e-posta gerekse bile adres, telefon, doğum tarihi gibi tüm alanları döndürebilir. İstemci gereksiz alanları görmezden gelse bile veriler ağ üzerinden aktarılmış ve log'larda yer almıştır.

KVKK uyumlu REST API tasarımı: endpoint'ler gerekenden fazla alan döndürmemelidir; yalnızca belirli alanları döndüren parametreli sorgular desteklenmelidir (?fields=email,name gibi).

GraphQL: Doğal Veri Minimizasyonu

GraphQL'de istemci yalnızca ihtiyaç duyduğu alanları sorgular. Bu yapı teknik olarak veri minimizasyonunu zorlar. Ancak dikkat edilmesi gereken nokta: __introspection sorguları şema yapısını ortaya çıkarabilir; üretim ortamında introspection devre dışı bırakılmalıdır.

API Güvenliği ve KVKK Teknik Tedbir Yükümlülüğü

KVKK m. 12'nin gerektirdiği teknik güvenlik tedbirleri, API tasarımında somut gereksinimler doğurur.

Sonuç

API entegrasyonları, modern yazılımın en kritik ve en çok göz ardı edilen KVKK risk alanlarından biridir. Webhook'ların sürekli veri akışı, OAuth scope'ların kapsam yönetimi, API loglarında biriken PII ve üçüncü taraf API sağlayıcıların farklı politikaları — tüm bunlar sistematik bir değerlendirme gerektirir.

Veri akışı haritası, OAuth scope minimizasyonu, log PII yönetimi, rate limiting ve DPA kapsamı bir arada doğru yönetildiğinde API entegrasyonları KVKK uyumlu biçimde çalışır. Bu alanlardan herhangi birinin ihmal edilmesi ise hem teknik güvenlik açıkları hem de ciddi hukuki riskler doğurur.

Güneş Partners olarak API ve entegrasyon mimarilerinin KVKK uyum değerlendirmesinde — veri akışı haritalama, DPA hazırlığı, yurt dışı aktarım güvencesi, aydınlatma metni güncellemeleri ve Kurul süreçlerinde temsil — şirketlere kapsamlı hukuki destek sağlıyoruz. API mimarinizin KVKK uyumunu değerlendirmek için bizimle iletişime geçebilirsiniz.

Bu İçerik Hakkında

Bu içerik, Güneş Partners kurucu ortakları Av. Mert Güneş ve Av. Melis Güneş tarafından, 6698 sayılı KVKK m. 4, 9, 10 ve 12, OWASP API Security Top 10, OAuth 2.0 RFC 6749, KVKK Kurumu teknik güvenlik rehberleri ve uluslararası API güvenlik standartları temelinde hazırlanmıştır. API ve veri akışı KVKK uyum süreçlerinde profesyonel destek için gunespartners.com adresini ziyaret edebilirsiniz.