Modern yazılım dünyasında API'ler, uygulamaların görünmeyen ama en kritik omurgasıdır. Mobil uygulamanız, web siteniz, üçüncü taraf entegrasyonlarınız ve mikroservisleriniz birbiriyle API'ler üzerinden konuşur. Bu konuşmanın taşıdığı veri çoğu zaman son derece hassastır: kullanıcı kimlikleri, ödeme bilgileri, sipariş kayıtları, iş süreçlerinin tamamı. Bu yüzden bir API'nin güvenliği, arkasındaki tüm sistemin güvenliği anlamına gelir. Tek bir korumasız uçnokta, dikkatle inşa edilmiş bütün bir mimariyi savunmasız bırakabilir.
Sorun şu ki API'ler, geleneksel web uygulamalarından farklı bir tehdit yüzeyine sahiptir. Bir API'nin "kullanıcı arayüzü" yoktur; saldırganla doğrudan, makineden makineye konuşur. Bu da güvenliği yalnızca arayüzde gizlenen düğmelere veya istemci tarafı kontrollere asla bırakamayacağınız anlamına gelir. KaliteliWebsite olarak İstanbul merkezli bir yazılım ajansı kimliğiyle yürüttüğümüz entegrasyon projelerinde defalarca gördük: API güvenliği sonradan eklenen bir katman değil, baştan tasarlanması gereken bir disiplindir. Bu rehberde REST ve GraphQL API'lerinizi güvence altına almanın en iyi pratiklerini, somut kod örnekleriyle ve OWASP API Security Top 10 çerçevesiyle ele alıyoruz.
API güvenliği neden ayrı bir disiplin?
Geleneksel web güvenliği, büyük ölçüde tarayıcı ile sunucu arasındaki etkileşime odaklanır. API güvenliği ise daha geniş ve daha karmaşık bir alandır çünkü API'leri yalnızca tarayıcılar değil; mobil uygulamalar, sunucular, IoT cihazları ve otomatik betikler de tüketir. Bu çeşitlilik, saldırı yüzeyini büyütür ve bazı klasik korumaları (örneğin yalnızca tarayıcıya bağlı çerez tabanlı oturumları) yetersiz kılar.
Ayrıca API'ler genellikle iş mantığını doğrudan dışa açar. Bir web sayfası kullanıcıya yalnızca görmesi gerekeni gösterirken, kötü tasarlanmış bir API uçnoktası tüm veri modelini olduğu gibi döndürebilir. Saldırganlar API dokümantasyonunu inceleyerek veya istekleri gözlemleyerek bu uçnoktaları haritalayabilir ve zayıf noktaları sistematik olarak arayabilir. OWASP'ın web uygulamaları için yayımladığı genel Top 10 listesine ek olarak özel bir API Security Top 10 listesi yayımlamasının nedeni tam da budur. Genel web güvenliği temellerini hatırlamak isterseniz OWASP Top 10 rehberimiz bu yazının doğal tamamlayıcısıdır.
API güvenliğinde temel zihinsel model şudur: her isteğe, kim olduğunu kanıtlamadan ve ne yapmaya yetkili olduğunu doğrulatmadan asla güvenmeyin. Bu prensip, aşağıdaki tüm başlıkların ortak çatısını oluşturur.
Kimlik doğrulama (Authentication) stratejileri
Kimlik doğrulama, bir isteğin kimden geldiğini güvenilir biçimde belirleme sürecidir. API'lerde yaygın olarak kullanılan üç temel yaklaşım vardır ve her birinin uygun kullanım senaryosu farklıdır.
API anahtarları
API anahtarları en basit yöntemdir: istemciye verilen benzersiz bir dize, her istekte bir başlıkta gönderilir. Sunucu bu anahtarı doğrular ve isteği o istemciyle ilişkilendirir. API anahtarları, sunucudan sunucuya entegrasyonlar ve kullanım takibi için pratiktir. Ancak tek başına zayıf bir kimliktir; çünkü anahtar ele geçirilirse onu taşıyan herkes istemci gibi davranabilir. Bu yüzden API anahtarları her zaman HTTPS üzerinden taşınmalı, asla istemci tarafı koda gömülmemeli ve düzenli olarak yenilenebilmelidir.
OAuth 2.0 ve OpenID Connect
Kullanıcı adına üçüncü taraf erişimi gerektiğinde standart yöntem OAuth 2.0'dır. OAuth, kullanıcının parolasını paylaşmadan, sınırlı kapsamda ve süreli erişim belirteçleri vermesini sağlar. Örneğin bir uygulamanın kullanıcının takvimine yalnızca okuma erişimi alması bu modelle güvenle yapılır. OpenID Connect ise OAuth 2.0 üzerine kimlik katmanı ekleyerek "bu kullanıcı kim?" sorusunu standart biçimde yanıtlar. Karmaşık ekosistemlerde ve tek oturum açma (SSO) senaryolarında bu standartlar vazgeçilmezdir.
JWT (JSON Web Token) tabanlı kimlik doğrulama
JWT, durumsuz (stateless) kimlik doğrulamanın en yaygın aracıdır. Sunucu, kullanıcı giriş yaptığında imzalı bir belirteç üretir; istemci bu belirteci sonraki her istekte gönderir ve sunucu imzayı doğrulayarak kullanıcıyı tanır. Belirtecin içine kullanıcı kimliği ve roller gibi bilgiler gömülebildiğinden, sunucunun her istekte veritabanına gitmesi gerekmez. Tipik bir JWT akışı şöyledir:
import jwt from 'jsonwebtoken'
// Giriş başarılı olunca kısa ömürlü erişim belirteci üret
const erisimToken = jwt.sign(
{ kullaniciId: kullanici.id, rol: kullanici.rol },
process.env.JWT_GIZLI,
{ expiresIn: '15m' }
)
// Her istekte belirteci doğrula
function kimlikDogrula(req, res, next) {
const baslik = req.headers.authorization
if (!baslik) return res.status(401).json({ hata: 'Yetkisiz' })
try {
const token = baslik.split(' ')[1]
req.kullanici = jwt.verify(token, process.env.JWT_GIZLI)
next()
} catch {
return res.status(401).json({ hata: 'Gecersiz belirtec' })
}
}
JWT kullanırken en sık yapılan hatalar şunlardır: belirteçleri çok uzun ömürlü tutmak, imza algoritmasını doğrulamamak ve gizli anahtarı zayıf seçmek. Doğru yaklaşım, kısa ömürlü bir erişim belirteci ile daha uzun ömürlü bir yenileme belirteci (refresh token) ikilisi kullanmaktır. Böylece bir belirteç çalınsa bile geçerlilik penceresi dakikalarla sınırlı kalır. Yenileme belirteçlerini güvenli, httpOnly çerezlerde saklamak ve iptal edilebilir tutmak da kritik bir önlemdir.
Yetkilendirme (Authorization) ve en küçük ayrıcalık
Kimlik doğrulama "kimsin?" sorusunu yanıtlar; yetkilendirme ise "bunu yapmaya iznin var mı?" sorusunu. Bu ikisini karıştırmak en sık görülen ve en pahalı güvenlik hatalarından biridir. Bir kullanıcının kimliğinin doğrulanmış olması, her kaynağa erişebileceği anlamına gelmez.
OWASP API listesinin en üst sıralarında yer alan iki risk, doğrudan yetkilendirme hatalarından kaynaklanır: nesne düzeyinde bozuk yetkilendirme (BOLA) ve işlev düzeyinde bozuk yetkilendirme. BOLA, bir kullanıcının istekteki nesne kimliğini değiştirerek başkasının verisine erişmesidir. Klasik örnek, /api/kullanici/123/faturalar uçnoktasında 123'ü 124 yaparak başka birinin faturalarına ulaşmaktır. Savunma, her istekte istenen kaynağın gerçekten isteyen kullanıcıya ait olduğunu sunucuda doğrulamaktır:
app.get('/api/kullanici/:id/faturalar', kimlikDogrula, (req, res) => {
// İstenen id, kimliği doğrulanmış kullanıcıyla eşleşmeli
if (req.params.id !== req.kullanici.kullaniciId) {
return res.status(403).json({ hata: 'Erisim reddedildi' })
}
// ... faturaları getir
})
İşlev düzeyinde yetkilendirme ise, sıradan bir kullanıcının yalnızca yöneticilere açık olması gereken uçnoktalara (örneğin kullanıcı silme) erişmesini engeller. Bu kontrolleri merkezî bir ara katman (middleware) ile uygulamak, her uçnoktada tekrar yazmaktan hem daha güvenli hem de bakımı kolaydır. Temel ilke en küçük ayrıcalıktır: her belirteç, her servis ve her kullanıcı yalnızca işini yapmak için gereken minimum yetkiye sahip olmalıdır.
Rate limiting ve kötüye kullanım önleme
Oran sınırlama (rate limiting), bir istemcinin belirli bir zaman diliminde yapabileceği istek sayısını kısıtlar. Bu, hem hizmet reddi (DoS) saldırılarına hem de kaba kuvvet ile parola tahminine, hem de API'nizin maliyetini patlatan kötüye kullanıma karşı temel bir savunmadır. Oran sınırı olmayan bir giriş uçnoktası, saldırganın saniyede binlerce parola denemesine açık kapı bırakır.
Etkili bir oran sınırlama stratejisi katmanlıdır:
- IP adresi bazında genel bir sınır koyarak ham trafik patlamalarını engelleyin.
- Kimliği doğrulanmış kullanıcı veya API anahtarı bazında daha hassas sınırlar uygulayın.
- Giriş, parola sıfırlama ve doğrulama gibi hassas uçnoktalara çok daha sıkı özel sınırlar getirin.
- Sınır aşıldığında 429 durum kodu ve Retry-After başlığı dönerek meşru istemcilere ne zaman yeniden deneyebileceklerini bildirin.
Basit bir oran sınırlama yapılandırması şöyle görünür:
import rateLimit from 'express-rate-limit'
const girisLimiti = rateLimit({
windowMs: 15 * 60 * 1000, // 15 dakika
max: 5, // pencere başına en fazla 5 deneme
message: { hata: 'Cok fazla deneme, lutfen sonra tekrar deneyin' },
})
app.post('/api/giris', girisLimiti, girisYap)
Oran sınırlamayı tek başına yeterli görmeyin; bot trafiğine karşı CAPTCHA, anormal davranış tespiti ve dağıtık saldırılara karşı bir önbellek/proxy katmanı ile birlikte kullanmak çok daha dirençli bir savunma kurar.
Girdi doğrulama ve enjeksiyon savunması
Bir API'ye gelen her veri parçası, aksi kanıtlanana kadar düşman kabul edilmelidir. Girdi doğrulama, yalnızca beklenen formatta, tipte ve aralıkta verinin sisteme girmesine izin vererek hem güvenliği hem de veri bütünlüğünü korur. Doğrulanmamış girdi; SQL injection, NoSQL injection ve komut enjeksiyonu gibi saldırıların kapısını aralar.
Doğru yaklaşım, kara liste (yasak olanları engelle) değil beyaz liste (yalnızca izin verileni kabul et) mantığıdır. Bir şema doğrulama kütüphanesi kullanmak bu işi hem güvenli hem de okunabilir hâle getirir:
import { z } from 'zod'
const kayitSemasi = z.object({
eposta: z.string().email(),
parola: z.string().min(10).max(128),
yas: z.number().int().min(18).max(120),
})
app.post('/api/kayit', (req, res) => {
const sonuc = kayitSemasi.safeParse(req.body)
if (!sonuc.success) {
return res.status(400).json({ hata: 'Gecersiz girdi' })
}
// sonuc.data artık güvenle kullanılabilir
})
Enjeksiyona karşı en güçlü savunma ise veritabanı katmanında parametreli sorgular kullanmaktır; kullanıcı girdisi asla doğrudan sorguya birleştirilmemelidir. Girdi doğrulama ile parametreli sorguları birlikte kullanmak, enjeksiyon ailesinin büyük çoğunluğunu kapatır.
Taşıma güvenliği: TLS, HTTPS ve CORS
API ile istemci arasındaki trafiğin tamamı şifrelenmiş olmalıdır. HTTPS (TLS) olmadan, ağ üzerindeki herhangi biri belirteçleri, parolaları ve hassas veriyi düz metin olarak okuyabilir. Bu, üzerinde tartışılmayacak bir asgari gerekliliktir. TLS'i zorunlu kılmak için Strict-Transport-Security başlığını kullanmak, tarayıcının yalnızca güvenli bağlantı kurmasını garantiler. Güvenlik başlıklarının tamamını nasıl yapılandıracağınızı web güvenliği başlıkları yazımızda ayrıntılı bulabilirsiniz.
Tarayıcıdan tüketilen API'lerde CORS (Cross-Origin Resource Sharing) yapılandırması da kritiktir. CORS, hangi kaynakların (origin) API'nize tarayıcı üzerinden erişebileceğini belirler. Sık yapılan ve tehlikeli bir hata, geliştirme kolaylığı için tüm kaynaklara izin veren joker yapılandırmayı üretimde bırakmaktır. Doğru yaklaşım, yalnızca güvendiğiniz kaynakları açıkça beyaz listeye almaktır:
import cors from 'cors'
const izinliKaynaklar = ['https://uygulamaniz.com', 'https://panel.uygulamaniz.com']
app.use(cors({
origin: (kaynak, callback) => {
if (!kaynak || izinliKaynaklar.includes(kaynak)) {
callback(null, true)
} else {
callback(new Error('CORS tarafindan engellendi'))
}
},
credentials: true,
}))
OWASP API Security Top 10: açık ve önlem tablosu
OWASP, API'lere özgü riskleri ayrı bir listede toplamıştır. Aşağıdaki tablo bu listenin en kritik kategorilerini, tipik örneklerini ve önlemlerini özetler:
| Risk | Tipik örnek | Birincil önlem |
|---|---|---|
| Nesne düzeyinde bozuk yetkilendirme (BOLA) | id değiştirilerek başkasının verisine erişim | Her istekte sahiplik doğrulama |
| Bozuk kimlik doğrulama | Zayıf JWT, kaba kuvvet koruması yokluğu | MFA, kısa ömürlü belirteç, oran sınırı |
| Aşırı veri ifşası | Uçnoktanın tüm modeli döndürmesi | Yanıtı yalnızca gerekli alanlarla sınırlama |
| Kaynak ve oran tüketimi | Sınırsız istek veya büyük sorgu | Rate limiting, sayfalama, sorgu maliyeti sınırı |
| İşlev düzeyinde bozuk yetkilendirme | Sıradan kullanıcının yönetici uçnoktasına erişmesi | Merkezî rol tabanlı yetki kontrolü |
| Kütle atama (mass assignment) | İstemcinin rol gibi alanları gönderip değiştirmesi | Girdi alanlarını açıkça beyaz listeye alma |
| Hatalı yapılandırma | Açık hata mesajları, eksik başlıklar | Sıkılaştırma, güvenlik başlıkları |
| Güvenli olmayan üçüncü taraf API | Doğrulanmadan tüketilen dış servis verisi | Dış yanıtları da doğrulama ve sınırlama |
Bu tabloyu bir denetim listesi gibi kullanarak mevcut API'nizdeki her satırın karşılandığından emin olabilirsiniz.
Aşırı veri ifşası ve kütle atama
İki sessiz ama yaygın risk, API yanıtlarının ve isteklerinin içeriğiyle ilgilidir. Aşırı veri ifşası, bir uçnoktanın ihtiyaç duyulandan fazla veri döndürmesidir. Geliştiriciler çoğu zaman veritabanı nesnesini olduğu gibi serileştirip döndürür; bu da parola hash'i, iç notlar veya başka kullanıcılara ait alanların yanlışlıkla istemciye sızmasına yol açar. Çözüm, yanıtı her zaman açıkça tanımlanmış bir çıktı şemasıyla sınırlamaktır; "her şeyi döndür, arayüz zaten göstermez" yaklaşımı tehlikelidir çünkü saldırgan ham yanıtı doğrudan görebilir.
Kütle atama ise tersidir: istemcinin gönderdiği nesneyi olduğu gibi modele yazmak. Bir kullanıcı kayıt isteğine rol alanını ekleyip kendini yönetici yapabiliyorsa, bu bir kütle atama açığıdır. Savunma, hangi alanların istemciden kabul edileceğini açıkça beyaz listeye almaktır. Hem girdi hem çıktı tarafında "yalnızca gerekli alanlar" disiplinini uygulamak, bu iki riski birden kapatır.
Loglama, izleme ve anomali tespiti
Bir API'yi güvene almak yalnızca saldırıları engellemek değil, aynı zamanda olup biteni görebilmektir. Yetersiz günlükleme, ihlallerin uzun süre fark edilmemesinin başlıca nedenidir. Başarısız kimlik doğrulama denemeleri, yetkilendirme reddedilmeleri, oran sınırı aşımları ve kritik işlemler merkezî olarak günlüklenmeli ve anlamlı alarmlara bağlanmalıdır.
Etkili bir izleme yaklaşımı şunları içerir: anormal trafik desenlerini (örneğin tek bir kaynaktan ani istek patlaması) tespit eden alarmlar, hata oranlarındaki sıçramaları yakalayan panolar ve olay müdahale planı. Önemli bir uyarı: günlüklere asla parola, belirteç veya hassas kişisel veri yazmayın; aksi halde günlük dosyasının kendisi bir veri sızıntısı kaynağına dönüşür. API'lerin sürekli izlenmesi ve sağlığının takibi, çoğu işletmenin tek başına sürdürmekte zorlandığı bir iştir; bakım, izleme ve destek hizmetimiz kapsamında bu süreci uçtan uca üstleniyoruz.
REST ve GraphQL'e özgü güvenlik riskleri
REST ve GraphQL, farklı mimari modeller oldukları için farklı güvenlik dikkatleri gerektirir. REST API'lerde her uçnokta ayrı bir yetkilendirme yüzeyidir; yüzlerce uçnoktanın her birinde tutarlı kontrol uygulamak en büyük zorluktur. Bu yüzden REST'te merkezî ara katmanlar ve tutarlı kimlik doğrulama desenleri kritiktir.
GraphQL'de ise tek bir uçnokta üzerinden esnek sorgular yapılır; bu esneklik güçlü bir avantaj olduğu kadar yeni riskler de getirir. İç içe ve derin sorgular, sunucuyu aşırı yükleyen sorgu bombalarına yol açabilir; bu yüzden sorgu derinliği sınırlama ve sorgu maliyeti analizi şarttır. Ayrıca GraphQL'in introspection özelliği, şemanızın tamamını dışa açabilir; üretimde bunu kısıtlamak iyi bir pratiktir. Yetkilendirmenin alan (field) düzeyinde uygulanması da GraphQL'e özgü bir gerekliliktir. İki mimariyi performans, esneklik ve güvenlik açısından derinlemesine karşılaştırdığımız REST vs GraphQL yazımız, doğru mimariyi seçerken bu güvenlik boyutunu da değerlendirmenize yardımcı olur.
Sırların yönetimi (secrets management)
API güvenliğinin sıkça ihmal edilen ama kritik bir parçası, sırların (API anahtarları, veritabanı parolaları, şifreleme anahtarları, üçüncü taraf belirteçleri) yönetimidir. En sık ve en tehlikeli hata, bu sırları kaynak koduna gömüp sürüm kontrolüne işlemektir. Bir kez depoya giren sır, geçmişte silinse bile commit geçmişinde kalır ve depoya erişen herkese açıktır.
Doğru yaklaşımın temel ilkeleri şunlardır:
- Sırları asla kaynak koduna yazmayın; ortam değişkenlerinde veya özel bir gizli anahtar yöneticisinde tutun.
- Üretim, test ve geliştirme ortamları için ayrı sırlar kullanın.
- Sırları düzenli olarak ve bir sızıntı şüphesi durumunda derhal yenileyin (rotasyon).
- Her servise yalnızca ihtiyaç duyduğu sırlara erişim verin; en küçük ayrıcalık ilkesini sırlara da uygulayın.
Bu disiplinleri otomatik bir sürece bağlamak, insan hatasını en aza indirir ve güvenli dağıtımın temelini oluşturur.
Türkiye pazarında güvenli API entegrasyonu
Türkiye'de işletmeler, ödeme sağlayıcıları, e-fatura sistemleri, kargo entegrasyonları ve bankacılık servisleriyle yoğun biçimde API üzerinden çalışır. Bu entegrasyonların her biri, hem teknik hem de yasal (KVKK) açıdan yüksek güvenlik standartları gerektirir. Bir ödeme entegrasyonundaki güvenlik açığı yalnızca veri kaybı değil, doğrudan finansal kayıp ve itibar zedelenmesi anlamına gelir.
Bu nedenle yerel pazarda API tasarlarken üç noktayı her zaman önceliklendiriyoruz: hassas verinin (özellikle ödeme ve kimlik bilgilerinin) asla gereğinden fazla saklanmaması, tüm entegrasyon trafiğinin şifrelenmesi ve denetim izlerinin (audit log) eksiksiz tutulması. Güvenli ve ölçeklenebilir entegrasyonları en baştan doğru kurmak için API entegrasyon hizmetimiz kapsamında üçüncü taraf servisleri güvenli biçimde bağlıyor, mevcut API'lerinizi denetliyoruz. Yeni bir uygulamanın güvenli mimarisini sıfırdan kurmak gerektiğinde ise web geliştirme hizmetimiz devreye girer.
Sıkça Sorulan Sorular
API anahtarı mı yoksa JWT mi kullanmalıyım?
İkisi farklı sorunları çözer. API anahtarları, sunucudan sunucuya entegrasyonlar ve kullanım takibi için uygundur. JWT ise kullanıcı oturumlarını durumsuz biçimde yönetmek için idealdir; özellikle mobil uygulamalar ve tek sayfa uygulamalarında. Çoğu olgun sistem ikisini birlikte kullanır: dış entegrasyonlar için API anahtarı, kullanıcı oturumları için JWT.
JWT belirteçlerinin ömrü ne kadar olmalı?
Erişim belirteçlerini kısa tutun; 5 ile 15 dakika tipik bir aralıktır. Uzun ömürlü erişim isteyen senaryolar için yenileme belirteci (refresh token) kullanın ve bunu güvenli, httpOnly bir çerezde saklayın. Kısa ömür, bir belirteç çalınsa bile saldırganın elindeki zaman penceresini en aza indirir.
Rate limiting tek başına DoS saldırılarına karşı yeterli mi?
Hayır. Oran sınırlama, uygulama düzeyinde temel bir savunmadır ve kaba kuvvet ile kötüye kullanıma karşı çok etkilidir. Ancak büyük ölçekli dağıtık (DDoS) saldırılara karşı, önünde bir CDN veya WAF gibi ağ düzeyinde koruma katmanına da ihtiyaç duyarsınız. Katmanlı savunma her zaman tek bir önlemden güçlüdür.
GraphQL, REST'ten daha mı güvensizdir?
Hayır, doğası gereği daha güvensiz değildir; farklı güvenlik dikkatleri gerektirir. GraphQL'in esnekliği, sorgu derinliği ve maliyet sınırlaması gibi ek kontrolleri zorunlu kılar. Bu kontroller doğru uygulandığında GraphQL en az REST kadar güvenli olur. Önemli olan mimariye uygun savunmaları kurmaktır.
Küçük bir uygulamada bu önlemlerin hepsi gerekli mi?
Önlemleri risk seviyesine göre önceliklendirmek mantıklıdır, ancak bazıları büyüklükten bağımsız zorunludur: HTTPS, doğru kimlik doğrulama, yetkilendirme kontrolü ve girdi doğrulama her uygulamada bulunmalıdır. Oran sınırlama ve gelişmiş izleme ise uygulama büyüdükçe ve trafik arttıkça önem kazanır. İyi haber, bu temellerin baştan kurulduğunda çok düşük maliyetli olmasıdır.
Sonuç
API güvenliği, modern yazılım mimarisinin pazarlık edilemez bir bileşenidir. Kimlik doğrulamadan yetkilendirmeye, oran sınırlamadan girdi doğrulamaya, taşıma güvenliğinden sır yönetimine kadar her katman, bütünün dayanıklılığına katkıda bulunur. Tek bir zayıf halka, en iyi tasarlanmış sistemi bile savunmasız bırakabilir. Bu yüzden güvenliği sonradan eklenen bir yama olarak değil, API'nin doğduğu andan itibaren tasarımın bir parçası olarak ele almak gerekir. Her isteğe kimliğini kanıtlatmak, her erişimi yetkiyle doğrulamak ve her girdiyi düşman kabul etmek; bu üç disiplin bir araya geldiğinde API'niz saldırıların büyük çoğunluğuna karşı dirençli hâle gelir.
KaliteliWebsite olarak İstanbul'dan tüm Türkiye'ye hizmet veren bir yazılım ajansı kimliğiyle, güvenli REST ve GraphQL API'leri tasarlıyor, mevcut entegrasyonlarınızı denetliyor ve açıkları kalıcı olarak kapatıyoruz. Projeleriniz için fiyatlarımız 10.000 TL'den başlıyor ve her potansiyel iş için ücretsiz keşif görüşmesi sunuyoruz. API mimarinizi birlikte güvene almak, üçüncü taraf entegrasyonlarınızı sağlamlaştırmak veya yeni bir projeye güvenli bir temelle başlamak için bizimle iletişime geçin; size pazarlama vaatleri değil, mühendislik temelli net bir yol haritası sunalım.