Mobil uygulamada API entegrasyonu, uygulamanın dış sistemlerle güvenli ve kontrollü şekilde veri alışverişi yapmasıdır. Kullanıcı telefonda “sipariş ver”, “ödeme yap”, “konumumu göster”, “randevu oluştur” veya “AI raporu üret” butonuna bastığında arka planda genellikle bir API çalışır.
Bir mobil uygulama yalnızca ekrandan ibaret değildir. Asıl değer; verinin doğru sistemden gelmesi, kullanıcının yetkisine göre işlenmesi, ödeme ve bildirim gibi kritik süreçlerin kesintisiz çalışmasıyla ortaya çıkar. Bu nedenle mobil uygulama geliştirme projelerinde API entegrasyonu, tasarım kadar erken planlanması gereken teknik bir katmandır.
Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu projelerinde gördüğümüz temel gerçek şu: API süreci başta iyi modellenmezse uygulama yayına çıktıktan sonra performans, güvenlik, bakım maliyeti ve kullanıcı deneyimi tarafında zincirleme sorunlar oluşur. Özellikle ödeme, üyelik, bildirim, ERP, kargo, harita ve yapay zekâ servisleri kullanan projelerde API mimarisi doğrudan ürün kalitesini belirler.
Google’ın Android güvenlik rehberi, uygulama ile sunucu arasındaki iletişimde güvenli bağlantı kullanımını temel prensiplerden biri olarak ele alır. Apple tarafında da URLSession ile yapılan HTTP bağlantılarında App Transport Security yaklaşımı HTTPS kullanımını varsayılan güvenlik beklentisi haline getirir. OWASP MASVS ise mobil uygulama güvenliği için kimlik doğrulama, veri saklama, ağ iletişimi ve platform etkileşimlerini birlikte değerlendiren otoriter bir standarttır.
API, “Application Programming Interface” ifadesinin kısaltmasıdır. Mobil uygulama açısından API; uygulamanın backend, üçüncü parti servisler veya kurumsal sistemlerle konuşmasını sağlayan sözleşmedir.
Bir yemek sipariş uygulamasında restoran listesi, kampanya kodu, sepet, ödeme ve kurye takibi ayrı API uçlarıyla çalışabilir. Bir emlak uygulamasında ilan arama, favoriye alma, harita filtreleme, mesajlaşma ve yetki belgesi doğrulama farklı endpoint’ler üzerinden yürür. Bir sağlık veya eğitim uygulamasında ise kullanıcı rolleri, içerik erişimi, video akışı, bildirim ve raporlama servisleri API katmanına bağlanır.
Mobil uygulamada API entegrasyonu yalnızca “veri çekmek” değildir. Doğru entegrasyon şu sorulara net cevap verir:
Bu sorular yanıtlanmadan yapılan entegrasyon, ilk testlerde çalışıyor görünse bile canlı kullanımda kırılgan hale gelir.
Mobil uygulamada API katmanı genellikle üç ana parçanın arasında çalışır: mobil istemci, backend ve dış servisler. Mobil istemci iOS veya Android uygulamadır. Backend; kullanıcı, iş kuralı, yetki, loglama ve veritabanı süreçlerini yönetir. Dış servisler ise ödeme sağlayıcısı, harita servisi, kargo sistemi, CRM, ERP, SMS, e-posta veya AI servisleri olabilir.
Örneğin kullanıcı mobil uygulamada ödeme yaptığında işlem akışı şu şekilde ilerleyebilir:
Bu akışta mobil uygulamanın doğrudan ödeme sağlayıcısına tüm kritik bilgileri göndermesi doğru değildir. İş kuralları ve güvenlik kontrolleri backend tarafında kalmalıdır. Bu yüzden API entegrasyonu, mobil uygulama projesinin yalnızca teknik ayrıntısı değil, ürünün omurgasıdır.
API mimarisi planlanırken REST, GraphQL, WebSocket, webhook ve SDK entegrasyonları farklı kullanım alanlarına göre seçilir.
| Entegrasyon türü | Kullanım alanı | Mobil uygulama örneği | Dikkat edilmesi gereken nokta |
|---|---|---|---|
| REST API | Standart veri okuma/yazma | Profil güncelleme, ilan listeleme, sipariş oluşturma | Endpoint versiyonlama ve hata formatı net olmalı |
| GraphQL | Esnek veri sorgulama | Kişiselleştirilmiş ana sayfa, karmaşık filtreler | Query karmaşıklığı ve cache stratejisi kontrol edilmeli |
| WebSocket | Gerçek zamanlı iletişim | Mesajlaşma, canlı takip, anlık bildirim | Bağlantı kopması ve yeniden bağlanma senaryosu yazılmalı |
| Webhook | Dış sistemden olay alma | Ödeme sonucu, kargo durumu, ERP stok güncellemesi | İmza doğrulama ve tekrar eden istek yönetimi yapılmalı |
| SDK entegrasyonu | Hazır mobil kütüphane kullanımı | Harita, analiz, push notification, sosyal giriş | SDK izinleri, boyutu ve gizlilik etkisi incelenmeli |
Basit uygulamalarda REST API çoğu zaman yeterlidir. Gerçek zamanlı mesajlaşma, canlı konum takibi veya anlık açık artırma gibi senaryolarda WebSocket ya da benzeri kalıcı bağlantı çözümleri gerekir. Ödeme, kargo ve ERP gibi sistemlerde ise webhook mekanizması kritik hale gelir.
İyi API entegrasyonu kod yazmadan önce başlar. Özellikle özel yazılım geliştirme projelerinde her dış sistemin dokümantasyonu, limitleri, güvenlik yöntemi ve test ortamı ayrı ayrı incelenmelidir.
Atalay Tech tarafında mobil uygulama projelerinde API entegrasyonunu genellikle keşif, teknik tasarım, MVP geliştirme, test, yayın ve bakım şeklinde ele almak daha sağlıklı sonuç verir.
| Aşama | Amaç | Tipik çıktı | Ortalama süre |
|---|---|---|---|
| Keşif | API ihtiyaçlarını ve veri akışını netleştirmek | Entegrasyon listesi, veri modeli, risk notları | 2-5 gün |
| Teknik tasarım | Endpoint, auth, cache ve hata formatını belirlemek | API sözleşmesi, sequence diagram, test senaryoları | 3-7 gün |
| MVP geliştirme | Kritik akışları çalışır hale getirmek | Login, listeleme, ödeme veya ana iş akışı | 2-5 hafta |
| Test | Gerçek cihaz, ağ ve hata senaryolarını doğrulamak | Test raporu, hata listesi, güvenlik kontrolü | 1-3 hafta |
| Yayın | Store ortamına uygun yapılandırma yapmak | Production build, canlı API, izleme ayarları | 3-10 gün |
| Bakım | Sürüm, hata, performans ve yeni servisleri yönetmek | Log takibi, versiyon güncelleme, iyileştirme | Sürekli |
Bu tablo her proje için birebir aynı değildir. Bir randevu uygulamasında takvim API’si daha ön plandayken, bir B2B sipariş uygulamasında ERP ve stok entegrasyonu daha fazla efor gerektirir. Bir AI destekli mobil uygulamada ise backend, model sağlayıcısı, kullanıcı kotası ve çıktı denetimi birlikte tasarlanmalıdır.
Keşif aşamasında en sık atlanan konu, üçüncü parti API’nin test ortamıdır. Bazı servisler iyi dokümantasyon sunar ama sandbox ortamı gerçek sistemle aynı davranmaz. Örneğin ödeme sağlayıcısı testte başarılı dönerken canlıda 3D Secure, kart bankası veya webhook gecikmesi farklı sonuç üretebilir.
Teknik tasarım aşamasında API sözleşmesi yazılı hale getirilmelidir. Endpoint adı, HTTP metodu, istek gövdesi, cevap formatı, hata kodu, rate limit, auth yöntemi ve versiyon politikası net değilse mobil ekip ile backend ekip arasında sürekli yorum farkı oluşur.
Mobil uygulamada API entegrasyonunun en kritik kısmı güvenliktir. Web uygulamalarından farklı olarak mobil uygulama istemcisi kullanıcının cihazında çalışır. Bu cihaz root edilmiş, jailbreak yapılmış, proxy ile izleniyor veya tersine mühendislik araçlarıyla analiz ediliyor olabilir.
Bu yüzden API güvenliği yalnızca “HTTPS kullandık” seviyesinde kalmamalıdır. OWASP MASVS, mobil uygulama güvenliğini ağ iletişimi, kimlik doğrulama, kriptografi, veri saklama ve platform etkileşimleriyle birlikte değerlendirir. Android Developers da güvenli iletişim, izin yönetimi ve verinin korunması konusunda uygulama geliştiricilerine ayrı rehberler sunar.
Mobil API güvenliğinde temel kontroller şunlardır:
En yaygın hata, API anahtarını mobil uygulamanın içine gömmektir. Mobil uygulama dosyaları analiz edilebilir; bu nedenle kritik sırlar istemci tarafında tutulmamalıdır. Harita gibi bazı servislerde mobil anahtar kullanılabilir ama domain, bundle ID, package name, imza ve kota sınırlarıyla kısıtlanmalıdır.
Ödeme, sağlık, finans veya üyelik verisi işleyen uygulamalarda KVKK etkisi ayrıca değerlendirilmelidir. Kullanıcının açık rızası, veri saklama süresi, hesap silme akışı ve log kayıtları yalnızca hukuk metniyle değil, teknik mimariyle de desteklenmelidir.
API entegrasyonu yalnızca başarılı cevaplara göre yazılırsa uygulama canlıda zayıf görünür. Mobil ağlar değişkendir; kullanıcı metroda, asansörde, otoparkta veya zayıf Wi-Fi bağlantısında olabilir. API 200 ms’de de dönebilir, 8 saniyede de zaman aşımına uğrayabilir.
Bu nedenle mobil uygulama tarafında her API çağrısı için yükleniyor durumu, boş veri durumu, hata mesajı, tekrar dene aksiyonu ve gerekiyorsa offline görünüm tasarlanmalıdır.
Bir saha satış uygulamasında temsilci müşteri ziyareti sırasında internet bağlantısını kaybedebilir. Eğer ürün kataloğu, müşteri bilgisi ve taslak siparişler lokal cache ile tutuluyorsa iş akışı devam eder. Bağlantı geldiğinde veriler kuyrukla backend’e gönderilir. Bu yaklaşım ilk geliştirmede ek efor ister ama gerçek kullanımda ciddi verim sağlar.
Cache tarafında dikkat edilmesi gereken konu verinin hassasiyetidir. Ürün listesi, kategori, şehir listesi veya sabit içerikler cache için uygundur. Sağlık raporu, ödeme sonucu, özel mesaj veya kimlik verisi gibi alanlarda cache daha dikkatli tasarlanmalıdır.
| Veri türü | Cache uygunluğu | Örnek | Not |
|---|---|---|---|
| Sabit referans verisi | Yüksek | Şehir listesi, kategori, para birimi | Uzun süreli cache kullanılabilir |
| Liste verisi | Orta | Ürünler, ilanlar, etkinlikler | Sayfalama ve yenileme zamanı belirlenmeli |
| Kullanıcıya özel veri | Düşük-Orta | Profil, favoriler, sepet | Oturum kapanınca temizlenmeli |
| Hassas veri | Düşük | Sağlık bilgisi, ödeme sonucu, özel mesaj | Şifreleme ve kısa saklama süresi gerekir |
| Gerçek zamanlı veri | Düşük | Canlı konum, anlık mesaj | WebSocket veya polling stratejisi gerekir |
Hata mesajları da ürün deneyiminin parçasıdır. “Bir hata oluştu” yerine kullanıcıya ne yapabileceğini söyleyen kısa mesajlar tercih edilmelidir. Örneğin “Bağlantı zayıf görünüyor. Sipariş taslak olarak kaydedildi, internet geldiğinde tekrar göndereceğiz.” mesajı hem güven verir hem destek talebini azaltır.
Mobil uygulamada API entegrasyonu maliyeti; entegrasyon sayısına, dış servis kalitesine, güvenlik seviyesine, test ortamına, veri modeline ve canlı operasyon beklentisine göre değişir. Buradaki rakamlar proje kapsamı çıkarılmadan kesin teklif değildir; Türkiye pazarındaki 2026 yazılım ajansı eforlarına göre tahmini aralıklardır.
| Kapsam | Tipik entegrasyonlar | Tahmini süre | Tahmini maliyet |
|---|---|---|---|
| MVP | Login, profil, listeleme, basit bildirim, temel backend | 4-8 hafta | 180.000 TL - 450.000 TL + KDV |
| Orta ölçek | Ödeme, harita, push notification, panel, raporlama | 8-14 hafta | 450.000 TL - 1.200.000 TL + KDV |
| Kurumsal | ERP/CRM, kargo, rol bazlı yetki, webhook, loglama, SLA | 12-24 hafta | 1.200.000 TL - 3.500.000 TL + KDV |
| Regülasyonlu yapı | KVKK, gelişmiş audit log, hassas veri, güvenlik testi | 16-28 hafta | 2.000.000 TL - 5.000.000 TL + KDV |
Maliyet farkının nedeni çoğu zaman ekran sayısı değil, entegrasyon riskidir. Örneğin 8 ekranlı bir ödeme ve ERP uygulaması, 25 ekranlı ama yalnızca içerik gösteren bir uygulamadan daha zor olabilir. Çünkü ödeme, stok, fatura, iade ve kullanıcı yetkisi aynı anda doğru çalışmalıdır.
mobil uygulama fiyatları aracını kullanarak fikir aşamasındaki bir ürün için daha net bir başlangıç aralığı çıkarılabilir. Ancak API entegrasyonu bulunan projelerde en doğru yaklaşım, önce servis listesini ve kritik akışları netleştirip ardından kapsamı parçalara ayırmaktır.
mobil uygulama yaptırmak isteyen işletmeler için API kapsamının erken konuşulması önemlidir. “Sonradan bağlarız” denilen ödeme, ERP veya CRM entegrasyonları, veri modeli başta yanlış kurulduysa daha pahalı revizyonlara yol açabilir.
Mehmet, 38 yaşında bir toptan satış şirketinin operasyon yöneticisi olsun. Şirketin saha ekibi müşterilerden WhatsApp, telefon ve e-posta ile sipariş alıyor. Stok bilgisi ERP’de, müşteri cari bilgisi muhasebe sisteminde, teslimat süreci ise kargo panelinde tutuluyor.
Mehmet’in hedefi, bayi ve saha ekibinin tek mobil uygulama üzerinden ürün görmesi, stok kontrol etmesi, sipariş oluşturması ve tahsilat durumunu izlemesi. Bu senaryoda mobil uygulamanın yalnızca güzel görünmesi yeterli değildir; uygulama en az dört farklı sistemle konuşmalıdır.
Böyle bir projede API entegrasyonu şu şekilde kurgulanabilir:
Bu yapı küçük görünse de arka planda ciddi iş kuralı barındırır. Cari limiti aşan sipariş ne olacak? Stok iki kullanıcı tarafından aynı anda seçilirse öncelik kimin? ERP geçici olarak yanıt vermezse sipariş kuyruğa mı alınacak, kullanıcıya hata mı gösterilecek? API entegrasyonu bu soruların tamamını kapsar.
Atalay Tech’in mobil uygulama ve web platformu projelerinde benimsediği yaklaşım, önce kritik iş akışını ortaya çıkarmak, ardından entegrasyonu MVP ve ileri fazlar olarak bölmektir. Böylece ürün daha erken test edilir, riskli servisler baştan görünür hale gelir ve gereksiz geliştirme maliyeti azaltılır.
Mobil uygulama backend’i için Laravel, özellikle panel, API, queue, bildirim, dosya yönetimi ve kullanıcı yetkilendirme ihtiyaçlarında güçlü bir altyapı sunar. Laravel yazılım geliştirme projelerinde Sanctum, policy yapısı, queue sistemi, job mimarisi ve loglama katmanı mobil API entegrasyonları için sık kullanılan bileşenlerdir.
Laravel tabanlı bir mobil API’de tipik yapı şu şekilde kurgulanabilir:
Backend tarafında en önemli karar, mobil uygulamanın doğrudan dış servislere bağımlı hale getirilmemesidir. Örneğin kargo firmasının API formatı değişirse mobil uygulamanın store’dan yeni sürüm beklemesine gerek kalmadan backend adaptörü güncellenebilmelidir.
Bu nedenle entegrasyonlarda “adapter” mantığı değerlidir. Ödeme sağlayıcısı, kargo servisi veya ERP sistemi doğrudan uygulama geneline yayılmaz; ayrı servis sınıfları üzerinden soyutlanır. Böylece ileride sağlayıcı değişirse kod tabanının tamamı değil, ilgili entegrasyon katmanı güncellenir.
API entegrasyonu canlıya alınmadan önce yalnızca “çalışıyor mu?” diye bakmak yeterli değildir. Özellikle mobil uygulamalarda eski uygulama sürümleri, zayıf bağlantılar, store onay süreci ve cihaz çeşitliliği hesaba katılmalıdır.
Canlıya çıkmadan önce şu kontrol listesi kullanılabilir:
Postman’ın 2025 State of the API raporu, API’lerin yalnızca teknik bağlantı aracı değil; güvenlik, gelir modeli, AI agent kullanımı ve ekip iş birliği açısından stratejik bir katman haline geldiğini vurgular. Bu nedenle API entegrasyonu tek seferlik geliştirme kalemi gibi değil, ürün yaşam döngüsünün sürdürülebilir bir parçası gibi ele alınmalıdır.
Kaynaklar:
Mobil uygulama API entegrasyonu olmadan genellikle yalnızca statik ekranlardan oluşur. Kullanıcı girişi, ödeme, harita, bildirim, mesajlaşma, sipariş, randevu, stok, profil ve raporlama gibi dinamik işlemler API ile çalışır. API, mobil uygulamanın backend ve dış servislerle güvenli biçimde konuşmasını sağlar. Bu sayede kullanıcı verisi merkezi olarak yönetilir, iş kuralları backend tarafında uygulanır ve uygulama farklı platformlarda tutarlı davranır. Özellikle iOS ve Android uygulamaların aynı veriyle çalışması için API katmanı zorunlu hale gelir.
Aynı şey değildir, fakat birbirine çok yakındır. Backend geliştirme; veritabanı, iş kuralları, kullanıcı yetkileri, admin paneli, dosya yönetimi, bildirim ve raporlama gibi sunucu tarafı yapıları kapsar. API entegrasyonu ise mobil uygulamanın bu backend veya üçüncü parti servislerle nasıl konuşacağını tanımlar. Örneğin Laravel ile geliştirilen backend, mobil uygulamaya REST API sunabilir. Aynı backend ödeme sağlayıcısı, ERP veya kargo servisiyle de entegre olabilir. Sağlıklı projelerde backend mimarisi ve API entegrasyonu birlikte tasarlanır.
Süre, entegrasyon sayısına ve dış sistemlerin kalitesine göre değişir. Basit bir login, profil ve listeleme API’si birkaç hafta içinde tamamlanabilir. Ödeme, harita, push notification ve yönetim paneli içeren orta ölçekli bir yapı 8-14 hafta sürebilir. ERP, CRM, kargo, webhook, rol bazlı yetki ve detaylı loglama içeren kurumsal projelerde süre 12-24 haftaya çıkabilir. En büyük zaman kaybı genellikle kodlamadan değil; eksik API dokümantasyonu, test ortamı farkları ve değişen iş kurallarından kaynaklanır.
API güvenliği HTTPS, token yönetimi, yetkilendirme, rate limit, güvenli veri saklama, log hijyeni ve webhook doğrulama adımlarıyla sağlanır. Mobil uygulama istemcisi güvenilir kabul edilmemelidir; çünkü uygulama dosyaları analiz edilebilir ve cihaz trafiği proxy araçlarıyla izlenebilir. Bu nedenle kritik kontroller backend tarafında yapılmalıdır. Kullanıcının başka bir kullanıcının verisine erişememesi, token süresinin doğru yönetilmesi ve hassas bilgilerin loglara yazılmaması temel güvenlik beklentileridir. OWASP MASVS bu konuda iyi bir referans standardıdır.
Çoğu mobil uygulama için REST API yeterli ve daha kolay yönetilebilir bir tercihtir. Profil, sipariş, listeleme, favori, bildirim ve ödeme gibi standart akışlarda REST sade bir yapı sunar. GraphQL ise ekranların çok farklı veri kombinasyonlarına ihtiyaç duyduğu, özellikle kişiselleştirilmiş ana sayfa veya karmaşık filtreleme senaryolarında avantaj sağlar. Ancak GraphQL tarafında query karmaşıklığı, cache, yetkilendirme ve performans kontrolü daha dikkatli tasarlanmalıdır. İlk ürün sürümünde REST ile başlamak, ihtiyaç büyüdükçe GraphQL değerlendirmek çoğu proje için daha güvenli ilerler.
Çünkü maliyeti belirleyen ana unsur ekran sayısı değil, entegrasyon riskidir. Bir uygulamada yalnızca içerik listeleniyorsa API yapısı daha basit olabilir. Ancak ödeme, ERP, kargo, rol bazlı yetki, webhook, stok senkronizasyonu, canlı bildirim ve KVKK hassasiyeti varsa geliştirme eforu artar. Dış servisin dokümantasyonu, sandbox kalitesi, hata kodları, rate limitleri ve destek hızı da maliyeti etkiler. Bu yüzden API entegrasyonu olan mobil projelerde önce teknik keşif yapılması, ardından MVP ve ileri fazların ayrılması daha doğru bütçe planı sağlar.
Doğru versiyonlama yapılmadıysa bozulabilir. Mobil uygulamalar web uygulamalarından farklıdır; kullanıcı eski uygulama sürümünü telefonunda kullanmaya devam edebilir. Backend tarafında API cevabı aniden değişirse eski mobil sürümler hata verebilir. Bu nedenle `/v1`, `/v2` gibi versiyonlama, geriye dönük uyumlu cevap formatı ve kontrollü geçiş planı gerekir. Kritik değişikliklerde mobil uygulama zorunlu güncelleme mekanizması da tasarlanabilir. Sağlıklı API yönetimi, yeni özellik eklerken mevcut kullanıcıların deneyimini bozmamayı hedefler.
Atalay Tech, mobil uygulama, web platformu ve AI entegrasyonu projelerinde önce iş akışını ve sistem bağımlılıklarını netleştirir. Ardından API ihtiyaçları; kullanıcı rolleri, veri modeli, güvenlik seviyesi, dış servisler, test ortamı ve yayın sonrası bakım gereksinimleriyle birlikte ele alınır. Proje kapsamı MVP ve ileri fazlar olarak ayrılır. Böylece ilk sürümde en kritik değer üreten entegrasyonlar tamamlanır, daha karmaşık ERP, CRM, ödeme veya AI servisleri kontrollü şekilde büyütülür. Bu yaklaşım hem teknik riski hem de gereksiz geliştirme maliyetini azaltır.
Mobil uygulamada teknik borç; hızlı teslim, eksik test, zayıf mimari ve plansız bakım yüzünden uygulamanın zamanla pahalı, kırılgan ve yavaş geliştirilir hale gelmesidir. Bu rehber; teknik borcu önlemek için mimari, test, sürümleme, bakım ve maliyet kararlarını somut örneklerle açıklar.
Mobil uygulama güncelleme süreci yalnızca yeni sürüm yüklemek değildir. Kapsam analizi, sürüm notu, test, mağaza onayı, kademeli dağıtım, hata takibi ve bakım planı birlikte yönetildiğinde uygulama daha stabil, güvenli ve sürdürülebilir olur.
Mobil uygulama bakım ve destek süreci; yayındaki bir uygulamanın güvenli, hızlı, güncel ve kullanıcı beklentilerine uygun kalmasını sağlar. Bu rehberde bakım kapsamını, destek seviyelerini, maliyet aralıklarını, mağaza uyumluluğunu, güvenlik kontrollerini ve Atalay Tech'in proje sonrası yaklaşımını pratik örneklerle in
