Şimdi açık konuşayım: GitHub App geliştiriyorsanız, hele kurumsal tarafta çalışan bir entegrasyon yazdıysanız, bu dertle muhtemelen uğraşmışsınızdır. Ben uğraştım, hem de baya uğraştım. Geçen yıl Logosoft’ta bir bankacılık müşterisi için GitHub App tarafında compliance odaklı bir araç geliştirirken, ekibin canını en çok sıkan şey enterprise seviyesinde installation ID bulmaktı; listeyi sayfa sayfa dolaşıyor, “acaba burada mı, yoksa öbür sayfada mı?” diye kendi kendimize bakıyorduk.
Neyse… GitHub sonunda bu boşluğu kapattı. 13 Mayıs 2026 itibarıyla Enterprise Installation API public preview’a geçti. Küçük gıbı duruyor, ama üretimde insanın elini ciddi rahatlatıyor.
Tam Olarak Ne Değişti?
Mesele şu: GitHub App’ler zaten organization, repository ve user seviyesinde “ben buraya kurulu muyum, kuruluysam installation ID’m ne?” diye sorabiliyordu. Üç ayrı endpoint vardı, ikisini gözünüz kapalı çalıştırıyordunuz. Ama enterprise seviyesinde aynı rahatlık yoktu. Yanı app’ınız bir enterprise’a kuruluysa, o ID’yi öğrenmek için GET /app/installations üzerinden bütün listeyi taramak zorundaydınız.
Düşünün — 50+ enterprise müşterisi olan bir app yazıyorsunuz; her token isteğinde pagination dönüyor, her sayfa için ayrı HTTP roundtrip gidiyor, sonra rate limit size hafiften el sallıyor. Kulağa küçük geliyor ama değil.
Yeni API basitçe şunu diyor: “Enterprise slug’ı ver, ben sana installation bilgisini geri vereyim.” Hepsi bu. Ama işte o “hepsi bu” dediğim şey, production’da latency’yi baya aşağı çekiyor.
Endpoint Tarafında Pratik Görünüm
API’nın kullanımı baya sade. Aşağıda kabaca nasıl göründüğünü gösteren bir örnek bırakıyorum:
GET /enterprises/{enterprise}/installation
Authorization: Bearer <JWT>
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2022-11-28Dönen response içinde id, account, permissions, events gıbı standart installation alanları geliyor. O ID’yi alıp POST /app/installations/{installation_id}/access_tokens çağrısıyla installation token’a çeviriyorsunuz. Klasik akış yanı, sadece ilk adım artık tek istekle çözülüyor.
Neden Önemli? “Küçük Bir Endpoint” Demeyin
İlk duyduğumda ben de “tamam güzel de, çok mu kritik?” dedim. Sonra eski projelere dönüp baktım. AZ-500 hazırlığı sırasında bir POC yapmıştım; GitHub Advanced Security taraması yapan custom bir App’ti bu. Test ortamında 3-4 enterprise vardı, sorun çıkmıyordu. Production’a geçince sayı 30+’a çıktı ve pagination yüzünden cold start süreleri 4-5 saniyeye kadar uzadı. Lambda timeout’a yaklaşınca insan ister istemez sınır oluyor.
Eh, Yanı bu API aslında üç ayrı problemi çözüyor:
- Latency: Tek HTTP çağrısı yapıyorsunuz, hedefe direkt gidiyor (bu kritik)
- Rate limit yükü: Pagination yapan app’ler primary rate limit’i hızlıca tüketiyordu, artık o yük azalıyor (bence en önemlisi)
- Kod karmaşıklığı: Pagination loop’unu ve “doğru installation hangisi” mantığını koddan silebiliyorsunuz
“Önemsiz” gıbı duran API ekleri çoğu zaman üretim ortamlarında en çok geri dönüş alan şeyler oluyor. Bu da öyle. Sessiz ilerliyor ama etkisi hissediliyor.
Eski Yöntemle Karşılaştırma
Şöyle bir tablo yapayım da kafada net otursun:
| Kriter | Eski Yöntem (Pagination) | Yeni Enterprise API |
|---|---|---|
| HTTP çağrı sayısı | N sayfa (N = installation/30) | 1 |
| Rate limit tüketimi | Yüksek | Düşük |
| Token alma süresi | Saniyeler | Milisaniye seviyesi |
| Kod kompleksitesi | Loop + filtre + edge case | Tek istek |
| Hedef bilinen mi? | Bilmiyorsanız tarıyordunuz | Slug ile direkt gidiyor |
Tabloya bakınca insanın içinden “bunu neden daha önce yapmadınız?” demek geliyor. Ama neyse, geç olsun güç olmasın.
Türkiye’deki Kurumsal Senaryolar Açısından
Küçük bir detay: Peki burada asıl iş nerede başlıyor? Türkiye tarafında Enterprise Cloud kullanan müşteri tabanı son 2 yılda gözle görülür biçimde büyüdü. Hele bir de bankacılık, telekom. Sigorta tarafında — KVKK ve regülasyon baskısı yüzünden — Enterprise Managed Users (EMU) tarafına geçişler hızlandı. Geçen ay bir telekom müşterisinde tam böyle bir migration projesindeydik. Bu konuyla ilgili preview ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Şimdi gelelim işin can alıcı noktasına. Bu konuyla ilgili Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımıza da göz atmanızı tavsiye ederim.
Kendi deneyimimden konuşuyorum, Böyle kurumlarda genelde merkezî bir DevOps ekibi oluyor. Altında 15-20 farklı iş birimi GitHub App formatında özel araç kullanıyor; security scanning, lisans uyumluluğu, audit trail, compliance raporlama… Her biri kendi App’iyle enterprise seviyesinde işlem yapıyor. Pagination problemi bu yapılarda kat kat daha can sıkıcı hâle geliyor. Bu konuyla ilgili CodeQL 2.25.4 Çıktı: Swift, C# ve Java Tarafında Neler Var? yazımıza da göz atmanızı tavsiye ederim.
Bilmem anlatabiliyor muyum, Bence Türk kurumsal pazarı açısından bu API’nın en büyük katkısı şu olacak: “GitHub App yazmak artık daha ucuz.”. Compute saatleri azalır, Function/Lambda timeout riski düşer, error handling sadeleşir. Bir CI/CD aracını sıfırdan yazmak yerine GitHub App üstüne inşa etmek daha cazip hâle geliyor. Buna paralel olarak Agent Pull Request’leri Her Yerde: Doğru Review Nasıl? yazımda değindiğim ajan-tabanlı review akışları da enterprise seviyesinde daha kolay kurulabilir hâle geliyor (eh, fena değil)
Enterprise vs Startup: Hangisi Ne Yapmalı?
Eğer küçük bir ekipseniz ve App’ınız sadece organization seviyesinde çalışıyorsa, bu değişiklik sızı doğrudan etkilemiyor. Eski organization installation endpoint’i hâlâ duruyor ve çalışıyor. Orada sorun yok.
Ama büyük bir kurumsal yapıdaysanız ve App’ınız enterprise seviyesinde permission istiyorsa — özellikle audit log, billing ya da security manager gıbı enterprise-scoped özelliklere dokunuyorsa — bu API’ye mümkün olan en kısa sürede geçin derim. Kod değişikliği gerçekten minimal; belki 20-30 satır kadar.
Geçiş İçin Pratik Adımlar
Bence, Eğer halihazırda pagination ile uğraşıyorsanız, geçiş senaryosu aslında baya temiz ilerliyor. Şöyle gidebilirsiniz:
- App’inizin permission scope’unu kontrol edin. Enterprise installation için “enterprise” target type’a uygun olması gerekiyor.
- Enterprise slug’ları bir config’e taşıyın. Eskiden installation listesinden filtrelediğiniz logic’i artık slug bazlı yapacaksınız.
- Eski pagination kodunuzu feature flag arkasına alın. Yeni API çalışmazsa eski yola düşsün (graceful fallback).
- Cache stratejinizi gözden geçirin. Installation ID’leri cache’liyorsanız TTL ayarlarınız değişebilir. (bence en önemlisi)
` Yeni endpoint’in latency ve error rate’ını Application Insights ya da benzeri bir araçla izleyin.
?Eksik Tarafı Yok mu?
Birinçisi, hâlâ JWT ile authentication gerekiyor — yanı App’inizin private key’ını taşımanız lazım. Buna alternatif bir OAuth flow olsa enterprise admin’ler için daha temiz olurdu. Ama bu zaten genel bir App authentication tartışması, bu endpoint’le ilgili değil.
İkincisi, dokümantasyon biraz hızlı yazılmış gıbı. Bazı edge case’ler (örneğin App, enterprise’a kuruluysa ama bir org’a da kuruluysa hangisi öncelikli, vs.) net değil. GitHub Community Discussion’da soranların hepsine cevap gelmiş değil henüz.
Üçüncüsü (yanlış duymadınız). Belki de en önemlisi: bu API public preview. GA olmadan kritik production akışlarına bağlamak risk. Microsoft Foundry tarafında GPT-5.5 Microsoft Foundry’de: Sahadan İlk Değerlendirme> yazısında da değinmiştim — preview yazılımın production’a alınması ayrı bir strateji gerektiriyor. Önce monitoring, sonra dilim dilim trafik.
Topluluk Geri Bildiriminin Gücü
Bir şey daha dikkatimi çekti: GitHub bu API’yi yapma kararını topluluk feedback’i üzerine almış. Yanı Enterprise Apps preview katılımcıları “ya kardeşim bu eksik” demiş, GitHub da “haklısınız” deyip yapmış. Açık iletişimin sonucu yanı.
Bunu önemsiyorum çünkü kurumsal yazılım dünyasında genelde tersi oluyor. Vendor’lar roadmap’lerini kendi kapalı kapıları ardında çiziyor, kullanıcıya yıllar sonra dokunabileceği bir şey veriyorlar. GitHub burada daha responsive davranmış. Açık Kaynağa İlk Katkı: GitHub’da Başlangıç Rehberi‘nde de bahsettiğim gıbı, açık ekosistemin gücü tam da burada — feedback loop kısa.
Sonuç: Küçük Ama Değerli
Özetle: Enterprise Installation API, sessiz ilerleyen. Enterprise GitHub App geliştirenler için baya işe yarayan bir ekleme. Pagination yükünü azaltıyor, kodu sadeleştiriyor, latency’yi düşürüyor. Public preview olduğu için production’a alırken dikkatli olmak lazım,. Denemeye başlamak bence mantıklı.
Benim önerim: önümüzdeki sprint’te bir saatinizi ayırın, App’inizdeki installation discovery logic’ını gözden geçirin. Pagination yapan kod varsa yeni endpoint’le karşılaştırın. Muhtemelen “biz neden bunu daha önce yapmadık” diyeceksiniz. Ben en azından öyle dedim.
Sıkça Sorulan Sorular
Enterprise Installation API hangı GitHub App’leri etkiliyor?
Aslında — hayır dür, daha doğrusu sadece enterprise seviyesinde permission istemiş. Birden fazla enterprise’a kurulu olan App’leri etkiliyor. Tek bir organization üzerinde çalışan App’lerde bir şey değişmiyor — eski organization installation endpoint’i hâlâ normal çalışıyor. Daha fazla bilgi için SPFx 1.23 Geldi: Yeoman’a Veda, CLI Dönemi Başlıyor yazımıza bakabilirsiniz. Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımızda bu konuya da değinmiştik.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bu API GA olana kadar production’da kullanmalı mıyım?
Açıkçası, duruma göre değişir. Mission-critical bir akıştaysa graceful fallback ile devreye alın —. Yeni endpoint patlarsa eski pagination yöntemine otomatik düşsün (en azından benim deneyimim böyle). İç araçlar ve düşük riskli senaryolarda işe doğrudan kullanabilirsiniz. Bence en mantıklısı önce internal tool’larda test etmek.
Installation token alma süresi gerçekten ne kadar düşüyor?
Benim test ortamımda, mesela 30+ enterprise olan bir App’te, ortalama 2.8 saniyeden yaklaşık 400 milisaniyeye düştü. Tabii bu sayı installation sayınıza ve coğrafi konumunuza göre değişiyor. Ama tek istek olduğu için iyileşme garanti — ne kadar ölür, o ayrı mesele.
Bunu biraz açayım.
Eski pagination yöntemini kullanmaya devam edebilir mıyım?
Evet, GET /app/installations endpoint’i hâlâ aktif ve deprecate da edilmedi. Ama yeni endpoint çok daha verimli; ileride zaten standart yöntem o olacak. Bence geçişi geciktirmenin pratik bir faydası yok.
Enterprise slug’ı nereden öğreneceğim?
Enterprise admin’inden alabilirsiniz ya da doğrudan enterprise URL’sinden çıkarabilirsiniz: github.com/enterprises/{slug}. Slug case-sensitive davranabiliyor — dokümantasyonda pek net değil. Tecrübeme göre tam yazımıyla göndermek en sağlıklısı.
Kaynaklar ve İleri Okuma
Doğrusu, GitHub Changelog: New enterprise installation API now in public preview
GitHub REST API Documentation — Apps
Authenticating as a GitHub App Installation
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
