Google Ads API, yönetici hesaplarına yapılan hassas erişimi Google Cloud proje listesiyle sınırlandıran yeni bir güvenlik özelliğini pilot olarak açtı. Amaç, doğru OAuth yetkisine sahip görünen bir uygulamanın bile hesap, kullanıcı veya faturalandırma gibi hassas işlemlere sınırsız biçimde ulaşmasını engellemek. Pilot, API kullanan ajanslar, reklam teknolojisi sağlayıcıları ve kendi otomasyonunu geliştiren büyük reklamverenler için doğrudan operasyon konusu.
Bu bir genel dağıtım duyurusu değil. Google geliştiricilerden pilot başvurusu alıyor ve başvuruları inceliyor. Programa katılan bir yönetici hesapta hassas çağrılar yalnızca önceden onaylanmış Google Cloud projelerinden geldiğinde çalışıyor. Allowlist dışında kalan bir proje geçerli kimlik bilgilerine sahip olsa bile bu işlemlerde hata alıyor. Böylece çalınan veya yanlış yapılandırılan bir kimlik bilgisinin etkisi, ikinci bir proje güveni katmanıyla daraltılabiliyor.
Türkiye'de API üzerinden çok sayıda müşteri hesabı yöneten ajanslar için gelişme önemli. Tek bir yönetici hesapta kampanya yönetimi, raporlama, kullanıcı erişimi ve faturalandırma süreçleri birleştiğinde güvenlik olayı tek hesabı değil bütün müşteri portföyünü etkileyebilir. Pilot henüz zorunlu olmadığı için aceleyle mimari değiştirmek gerekmiyor. Ancak hangi uygulamanın hangi proje ve yönetici hesap adına çağrı yaptığını bugün çıkaramayan ekipler, özellik yaygınlaştığında hazırlıksız kalır.
Güvenlik katmanı nasıl çalışıyor?
Başvuru en üst düzey Google Ads yönetici hesap kimliğiyle yapılıyor. Google, kullanılacak Cloud projelerini ve hesap hiyerarşisini değerlendirerek onaylı bir liste kuruyor. Bağlı alt hesaplar, yönetici hiyerarşisi içinde korumayı devralabiliyor. Bir hesap bu ilişkiden çıkarıldığında aynı korumaya artık güvenemiyor.
Kapsam bütün API çağrılarını eşit biçimde engellemek değil. Google'ın duyurusu hesap, kullanıcı ve faturalandırma gibi hassas alanları öne çıkarıyor. Onaylı olmayan Cloud projesinden gelen bu tür çağrılar başarısız oluyor. Normal kampanya operasyonlarının tam listesi, hata kodlarının ayrıntısı ve pilot sonrasındaki zorunluluk takvimi henüz genel bir standart olarak açıklanmış değil.

Görsel, aynı anahtarın onaylı proje hattında geçerken listede olmayan hatta durdurulmasını anlatan Fark Studio illüstrasyonudur. Resmî ürün ekranı değildir.
Bu model OAuth'un veya geliştirici tokenının yerine geçmiyor. Kullanıcı yetkilendirmesi, token erişim seviyesi, iki adımlı doğrulama ve hesap izinleri çalışmaya devam ediyor. Yeni katman, “bu kimlik bilgisi hangi uygulama projesinden kullanılabilir?” sorusuna ek bir cevap veriyor.
Kimleri etkiliyor?
Birinci grup, kendi Google Ads API entegrasyonunu çalıştıran ajanslar ve performans ekipleri. Rapor çekme, bütçe değiştirme, kampanya oluşturma veya kullanıcı yönetimi yapan servislerin Cloud proje sahipliği açık olmalı. Aynı kimlik bilgisini geliştirici dizüstüsünde, üretim sunucusunda ve üçüncü taraf otomasyonda paylaşmak riski büyütür.
İkinci grup, müşterilerine reklam yönetimi yazılımı sunan martech ve adtech sağlayıcıları. Çok kiracılı uygulamalarda proje, ortam ve müşteri sınırları birbirine karışıyorsa allowlist tek başına yeterli olmaz. Yetkilerin en az ayrıcalıkla verilmesi, işlem kayıtlarının merkezi tutulması ve müşteri hesabı bağlantılarının düzenli gözden geçirilmesi gerekir.
Üçüncü grup, dış ajansa veya otomasyon tedarikçisine yönetici hesap erişimi veren markalar. Marka ekibi API kodunu yazmasa bile hangi sağlayıcının hangi uygulama üzerinden işlem yaptığını bilmek zorunda. Sözleşmedeki “güvenli entegrasyon” ifadesi teknik proje kimliği ve erişim kapsamıyla doğrulanmadıkça operasyonel kanıt sayılmaz.
Kesinleşen ve belirsiz kalan noktalar
Kesinleşenler şunlar: özellik pilot aşamasında; katılım başvuruyla gerçekleşiyor; hassas çağrılar onaylı Cloud proje listesine bağlanıyor; liste dışındaki uygulamalar hata alabiliyor; yönetici hesap hiyerarşisi korumanın kapsamını belirliyor. Google, yeni uygulama onay sürecinde yaklaşık on iş günlük inceleme süresi planlanmasını istiyor.
Belirsizler de kararın parçası. Pilotun ne zaman ve hangi hesaplara genel olarak açılacağı açıklanmadı. Hassas işlem listesinin zamanla genişleyip genişlemeyeceği bilinmiyor. Performans kazancı vaat edilmiyor; bu özellik güvenlik ve erişim denetimi için tasarlanıyor. Bugün programa katılmayan hesabın yakında engelleneceği sonucunu çıkarmak doğru değil.
Pilot öncesi sekiz adımlı hazırlık
1. API envanterini çıkarın. Üretim, test, raporlama, veri ambarı ve üçüncü taraf araçların kullandığı bütün Cloud projelerini listeleyin.
2. Yönetici hesap ağacını çizin. Hangi alt hesabın hangi üst yönetici üzerinden koruma devralacağını ve hangi bağlantının geçici olduğunu belgeleyin.
3. Kimlik bilgilerini ayırın. Geliştirme, test ve üretimde aynı sır veya refresh tokenı kullanmayın. Paylaşılan kimlik bilgisini merkezi bir sır yönetiminde döndürün.
4. Yetki kapsamını daraltın. Uygulama yalnızca rapor okuyorsa kullanıcı veya faturalandırma işlemi yapabilen geniş bir rol vermeyin.
5. Cloud proje sahipliğini doğrulayın. Eski çalışanların, tedarikçilerin veya kişisel Google hesaplarının kalıcı yönetici olmadığını kontrol edin.
6. Başarısız çağrıları görünür kılın. Allowlist kaynaklı hatayı normal kota veya bağlantı hatasından ayıracak alarm ve kayıt alanı hazırlayın.
7. Kopma senaryosunu test edin. Bir alt hesap yönetici hiyerarşisinden ayrılırsa hangi otomasyonların çalışmayı bırakacağını kontrollü ortamda sınayın.
8. Pilot başvurusunu değişiklik takvimine alın. Google incelemesi ve uygulama onayı için en az on iş günü pay bırakın; yoğun kampanya döneminin ortasında geçiş yapmayın.

Dört kapı, kimlik bilgisi, yönetici hiyerarşisi, işlem gözlemi ve son onayı aynı hazırlık hattında birleştiriyor.
Bu çalışma performans pazarlama, veri ve analitik ile kurumsal web ekiplerinin ortak sorumluluğudur. Güvenlik kontrolü yalnızca geliştiricinin omzunda kaldığında, medya ekibi erişim kesintisini kampanya sorunu sanabilir.
Şimdi ne yapılmalı, nerede beklenmeli?
Bugün yapılması gereken, başvurudan önce envanter ve sahiplik temizliğidir. Çok sayıda müşteri hesabında değişiklik yapan üretim entegrasyonu varsa pilot uygunluğu değerlendirilmelidir. Tek kullanımlık raporlar veya küçük hesaplar için aceleyle yeni organizasyon kurmak yerine resmî başvuru koşullarını ve mevcut erişim modelini karşılaştırın.
Beklenmesi gereken nokta genel dağıtım varsayımıdır. Google bir zorunluluk tarihi vermedi. Pilot sonucunu, desteklenen hesap yapılarını ve hassas çağrı kapsamını görmeden bütün entegrasyonu yeniden yazmak gereksiz olabilir. Ancak “henüz zorunlu değil” diyerek proje kimliklerini ve erişim kayıtlarını belirsiz bırakmak da savunulabilir değildir.
Fark Studio yorumu: API güvenliği artık tek bir tokenı gizlemekten ibaret değil. Güven zinciri; insan hesabı, yönetici hesap, Cloud projesi, uygulama ortamı ve izin verilen işlem birlikte doğrulandığında anlamlı. Reklam otomasyonunuzun erişim haritasını çıkarıp pilot hazırlığını kampanya sürekliliğiyle birlikte planlamak isterseniz Fark Studio ile iletişime geçebilirsiniz.
Kaynaklar
Google Ads Developer Blog, Google Ads API pilot: Secure API Access to your Manager Accounts, 5 Ağustos 2026. Pilot kapsamı, başvuru, allowlist ve hata davranışının resmî birincil kaynağı.
Search Engine Land, Google launches Secure API Access pilot for manager accounts, 5 Ağustos 2026. Duyurunun ajans ve reklamveren etkisini özetleyen ikincil kaynak.



