GitHub fatura otomasyonu artık kişisel erişim anahtarına bağlı değil
GitHub, 26 Ağustos 2026 tarihli sürüm duyurusuyla GitHub Enterprise Cloud’daki kurumsal faturalandırma REST API’lerini GitHub App kurulum erişim anahtarlarına açtı. Enterprise sahipleri bir uygulamaya Enterprise billing için salt okunur veya okuma-yazma izni verebiliyor; böylece kullanım raporları, bütçeler ve maliyet merkezleri artık bir enterprise sahibi ya da billing manager’a ait kişisel erişim anahtarına bağlı olmadan işlenebiliyor.
Değişikliğin aynı gün kullanıma girdiği, GitHub’ın sayfalarını düzenli izleyen Breakwatch değişiklik kaydında da yeni bir GitHub Apps özelliği olarak yer alıyor. Ancak mevcut entegrasyonlar kendiliğinden dönüşmüyor: uygulamanın kurumsal izni istemesi, enterprise hesabına kurulması ve isteklerde installation access token kullanması gerekiyor.
Otomasyon kimliği çalışandan GitHub App kurulumuna geçiyor
Yeni seçenek, zamanlanmış fatura işinin kimliğini belirli bir kişinin hesabından ayırıyor. Kişisel erişim anahtarının sahibi rol değiştirdiğinde, kurumdan ayrıldığında veya anahtar iptal edildiğinde ortaya çıkan doğrudan bağımlılık; enterprise düzeyinde onaylanan uygulama kurulumu ve bu kurulum adına üretilen erişim anahtarıyla değiştirilebiliyor.
Bu değişiklik kişisel erişim anahtarlarını kaldırmıyor ve kurumları zorunlu bir geçişe tabi tutmuyor. Başlıktaki “bağlı değil” ifadesinin sınırı da bu: GitHub Enterprise Cloud, aynı kurumsal faturalandırma işlemleri için artık kişiye ait belirtecin yanında desteklenen bir uygulama kimliği sunuyor.
Kurulum anahtarı, GitHub App’in izinlerinden daha geniş bir erişim sağlamıyor. Uygulamanın enterprise hesabında kurulu olması ve çağrılan uç noktanın gerektirdiği Enterprise billing düzeyine sahip bulunması gerekiyor; yalnızca bir GitHub App kaydetmek fatura verilerini erişilebilir hâle getirmiyor.
Salt okunur ve okuma-yazma izinleri farklı işleri kapsıyor
İzin ayrımı, rapor üretmek ile mali yapılandırmayı değiştirmek arasındaki sınırı belirliyor. Yalnız finans veya BI sistemine veri aktaran bir otomasyon için salt okunur düzey yeterliyken bütçe ya da maliyet merkezi kayıtlarını değiştiren işlemler okuma-yazma düzeyini gerektiriyor.
- Enterprise billing — read: Kurumsal kullanım raporlarını almak, mevcut bütçeleri görüntülemek ve maliyet merkezlerini okumak.
- Enterprise billing — read and write: Okuma işlemlerine ek olarak bütçeleri ve maliyet merkezlerini oluşturmak, güncellemek veya silmek; maliyet merkezlerine kaynak eklemek ya da bu ilişkileri kaldırmak.
Bu matris, yalnız raporlama yapan iş için yazma yetkisinin gerekli olmadığını gösteriyor. Raporlama ile bütçe yönetiminin ayrı uygulamalara veya ayrı denetlenen iş akışlarına bölünmesi GitHub’ın zorunlu tuttuğu bir mimari değil; en az ayrıcalık ilkesini uygulamak isteyen kurumların tercih edebileceği bir düzen.
Aynı uygulama hem raporlama hem değişiklik yapacaksa okuma-yazma izni bütün kurulum anahtarlarına bu geniş kapsamı taşır. Bu nedenle yetki seçimi uygulamanın ileride yapabileceği varsayılan işlere göre değil, gerçekten çağırdığı uç noktalara göre belirlenmeli.
Kişisel erişim anahtarından geçiş kontrollü yapılmalı
Geçiş yalnızca Authorization başlığındaki değerin değiştirilmesi değildir. Kimlik türüyle birlikte uygulama kaydı, enterprise kurulumu, izin onayı ve kurulum anahtarı üretme süreci de otomasyonun parçası hâline gelir.
- Mevcut kişisel erişim anahtarının çağırdığı kullanım, bütçe ve maliyet merkezi uç noktalarını envantere alın.
- Her çağrıyı okuma veya değişiklik işlemi olarak sınıflandırın; yalnız raporlayan iş için read düzeyini seçin.
- Enterprise billing iznini isteyen GitHub App’i kaydedin ve uygulamanın enterprise hesabına kurulmasını sağlayın.
- Çalışma anında enterprise kurulumuna ait installation access token üretin ve REST isteklerinde kişisel erişim anahtarının yerine kullanın.
- Eski ve yeni akışı aynı enterprise slug’ı, raporlama dönemi ve filtrelerle çalıştırarak dönen kayıtları karşılaştırın.
- Eski anahtara bağlı çağrı kalmadığı doğrulandıktan sonra kişisel belirteci iş akışından ve ilgili secret kayıtlarından çıkarın.
Karşılaştırmada yalnız başarılı HTTP durum koduna bakmak yeterli olmaz. Dönem, hesap düzeyi veya maliyet merkezi filtresi farklıysa iki kimlik yöntemi aynı API’ye erişse bile sonuç kümeleri değişebilir; doğrulama bu parametreler sabit tutularak yapılmalı.
Yazma çağrısı bulunan bir entegrasyonda raporlama bölümü ayrıca sınanmalı. Geçişi kolaylaştırmak için bütün uygulamaya okuma-yazma izni vermek işlevsel olabilir, ancak salt okunur raporlama görevine gereksiz değişiklik yetkisi de kazandırır.
Kurulum anahtarı dört kurumsal kullanım raporunu okuyabiliyor
GitHub Billing usage API referansı, Enterprise billing read iznine sahip bir GitHub App installation access token ile erişilebilen dört enterprise raporunu belgeliyor: AI kredisi kullanımı, premium istek kullanımı, maliyet merkezine göre kullanım ve toplulaştırılmış kullanım özeti.
Uç noktaların kapsamları aynı değil. AI kredisi, premium istek ve kullanım özeti raporlarında son 24 aylık veri erişilebilirken maliyet merkezine göre ayrıntılı kullanım raporu yalnız enhanced billing platform erişimi bulunan enterprise hesaplarında kullanılabiliyor. Ayrıntılı kullanım uç noktası varsayılan olarak bir maliyet merkezine atanmamış kullanımı; kullanım özeti ise tüm maliyet merkezlerini döndürüyor.
Filtreler de rapora göre değişiyor. AI kredisi ve premium istek uç noktaları zamanın yanı sıra organization, user, model, product ve cost_center_id alanlarıyla süzülebiliyor. Kullanım özetinde repository ve SKU seçenekleri bulunurken ayrıntılı kullanım raporu yıl, ay, gün ve cost_center_id ile daha dar bir filtre kümesi sunuyor.
Yanıt şemaları tek tip değil: ayrıntılı kullanım kaydında quantity alanı bulunurken toplulaştırılmış yanıtlarda grossQuantity, discountQuantity ve netQuantity alanları yer alabiliyor. Kimlik değişikliği bu nedenle veri eşleme kodunu değiştirmese bile, mevcut entegrasyonun kullandığı uç nokta ve alanların yeni akışta aynı kaldığı doğrulanmalı.
Yeni izin mevcut iş akışlarını otomatik dönüştürmüyor
Yayımlanan özellik, GitHub Enterprise Cloud’da kişiden bağımsız bir kimlik seçeneği oluşturuyor; eski kişisel erişim anahtarlarının devre dışı bırakıldığı anlamına gelmiyor. Zorunlu bir geçiş tarihi veya mevcut belirteçleri otomatik olarak GitHub App kurulumuna taşıyan bir mekanizma açıklanmış değil.
Kurumsal ekipler açısından değişmeyen temel sınır, erişimin enterprise düzeyinde onaylanması. Uygulama gerekli izni istemedikçe, enterprise hesabına kurulmadıkça ve uygun kurulum anahtarı kullanılmadıkça faturalandırma uç noktalarına erişemiyor. Bundan sonraki uygulama kararı, yalnız raporlama yapan işleri read düzeyinde tutmak ile bütçe ve maliyet merkezi yönetimini ayrı bir okuma-yazma akışına ayırmak arasında olacak.
Ayrıca okuyun:
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.