Google Calendar Kurum Takvimleri API'de Nasıl Filtrelenir?

Kısa yanıt

Google Workspace kullanan bir randevu otomasyonunda yalnızca kuruma ait takvimleri listelemek istiyorsanız, Calendar API calendarList.list çağrısındaki showOwnOrganizationOnly filtresini değerlendirin. Google'ın 14 Temmuz 2026 sürüm notu, bu filtrenin genel kullanıma açıldığını bildiriyor. API başvurusu parametrenin yalnızca Google Workspace kullanıcıları için geçerli olduğunu ve varsayılanının false olduğunu açıklıyor. Filtreyi açmadan önce ürünün harici paylaşılan takvimlere gerçekten ihtiyaç duyup duymadığını belirleyin. Kurum dışı bir uzmanla ortak takvim kullanıyorsanız, filtre o kaynağı listeden çıkarabilir; bu bir erişim hatası değil, seçtiğiniz kapsamın sonucu olabilir.

Randevu akışında takvim listesi neden önemlidir?

Bir randevu sistemi çoğu zaman etkinlik oluşturacağı takvimi bir seçim listesinden alır. Kullanıcının kişisel, ekip, harici paylaşılan ve eski takvimleri aynı listede görmesi yanlış takvime kayıt açma riskini artırır. Öte yandan listeyi gereğinden fazla daraltmak, gerçekten kullanılan bir paylaşılan kaynağı gizleyebilir. Önce hangi takvimin hangi hizmet veya ekip için kullanıldığını belgeleyin. “Hekim takvimi”, “görüşme odası” ve “müşteriyle ortak proje takvimi” aynı sahiplik kuralına uymayabilir.

Bu filtrenin amacı takvim listesi kapsamını belirlemektir. Randevunun çift rezervasyona açık olup olmaması, etkinlik yetkisi ve özel etkinlik görünürlüğü ayrı kararlardır. Dolayısıyla liste temizlendi diye kaynak çakışması çözülmüş sayılmaz. Mevcut randevu sisteminizde Google Calendar randevu kimliği eşleme yazımız bir etkinliği kendi kayıtlarınızla ilişkilendirmeyi anlatır; burada ise etkinlik oluşturulmadan önce hangi takvimlerin kullanıcıya sunulacağını tasarlıyoruz.

Hangi kullanıcıda hangi sonucu beklemelisiniz?

İlk kabul testi için üç hesap belirleyin: kurum içi Workspace kullanıcısı, dışarıdan paylaşılmış takvimi olan kurum içi kullanıcı ve mümkünse kurum hesabı olmayan bir kullanıcı. Her hesapta aynı API çağrısını filtre kapalı ve açık biçimde yapın. Dönen takvim ID'lerini karşılaştırın; yalnızca ekranda görünen adlara bakmayın. Adlar değişebilir veya aynı olabilir, ID ise uygulama eşlemesi için daha güvenilir anahtardır. Google belgesinin Workspace sınırlamasını göz önünde bulundurarak kurum dışı hesap için kesin bir sonuç varsaymayın; bu hesap türünde filtreyi kullanıp kullanmayacağınızı ürün gereksinimine göre belirleyin.

Kurum içi bir takvim görünmüyorsa hemen filtreyi suçlamayın. Önce kullanıcının gerçekten o takvime erişimi olup olmadığını, takvimin listede gizli durumda bulunup bulunmadığını ve API isteğinde başka filtreler kullanılıp kullanılmadığını kontrol edin. showHidden ve minAccessRole gibi parametreler de sonucu etkileyebilir. Özellikle yönetici hesabının gördüğü takvimlerle son kullanıcının gördüklerini eşit kabul etmeyin. Randevu kaydını yapan hesabın yetkisi, listeyi görüntüleyen hesabın yetkisinden farklıysa ayrıca test gerekir.

API isteğini nasıl sınarsınız?

Önce mevcut uygulamanın yaptığı calendarList.list isteğini kaydedin. Yetki belirtecini veya müşteri e-posta adresini rapora taşımayın. Testte yalnızca parametreleri, beklenen takvim ID kümesini ve sonuç kodunu tutun. showOwnOrganizationOnly=true ile ilk sayfanın items listesini alın. Ardından nextPageToken varsa bütün sayfaları gezip toplam küme üzerinde karşılaştırma yapın. İlk sayfada bir takvimin görünmemesi, tüm sonuçlarda olmadığı anlamına gelmez.

API başvurusu maxResults için sayfa boyutu sınırı ve nextPageToken ile sonraki sayfaya geçişi tanımlar. Bu yüzden çok takvimli bir ekipte tek yanıtı eksiksiz liste sanmayın. İstek başarısızsa HTTP kodunu, parametreleri ve yetki kapsamını birlikte inceleyin. Başvuru, bu çağrı için farklı Calendar OAuth kapsamlarını listeler; gereğinden geniş yetki istememek için uygulamanın gerçekten yaptığı işlemi esas alın. Listeleme ihtiyacı ile etkinlik yazma ihtiyacını aynı izin gibi ele almayın.

Senkronizasyon belirteciyle sınır

Google'ın API başvurusu, showOwnOrganizationOnly ile artımlı senkronizasyon belirtecinin aynı istekte kullanılamayacağını belirtiyor. Bu ayrıntı önemlidir: mevcut takvim önbelleğiniz nextSyncToken ile güncelleniyorsa yeni filtreyi aynı sorguya ekleyerek güvenli geçiş yapamazsınız. Filtreli tam listeyi ayrı alıp yerel takvim kümesini yeniden kurma kararını değerlendirin. Eski kayıtları hemen silmek yerine yeni ve eski ID kümelerinin farkını inceleyin.

Bir takvim yeni filtrede yok diye daha önce açılmış randevu etkinliklerini otomatik taşıma veya silme kararı vermeyin. Eski kayıtların bağlı olduğu takvim farklı bir organizasyona ait olabilir ve işletme o takvimi hâlâ kullanıyor olabilir. Önce bu durumun gerçek bir değişiklik mi, erişim kaybı mı, yoksa filtreleme sonucu mu olduğunu insan tarafından onaylatın. 410 gibi süresi dolmuş senkronizasyon hatasında Google, önbelleğin temizlenip tam eşitleme yapılmasını tarif eder; bunu filtre geçişinden ayrı bir hata yolu olarak test edin.

Ekran ve operasyon kararları

API filtresini doğrudan kullanıcı ekranına yansıtmak tek seçenek değildir. Kurum takvimlerini ana listede gösterebilir, gerekli harici takvimleri ayrı bir seçim veya yönetici onayıyla ekleyebilirsiniz. Bu karar işletmenin randevu akışına bağlıdır. Örneğin dış danışmanla yapılan görüşmeler kurum içinde izleniyorsa harici takvimi saklamak işleri zorlaştırabilir. Her takvim için gösterilen ad, sahiplik, erişim rolü ve kullanım amacı açıklanabilir olmalıdır.

Kullanıcı yanlış takvimi seçerse geri alma yolu da tasarlayın. Randevu oluşturma öncesi onay ekranında takvimin adını ve saat dilimini gösterin. Başarısız etkinlik oluşturma durumunda talebi “kesinleşti” olarak işaretlemeyin. Takvim listesi filtresi, uygunluk kontrolünün yerine geçmez; seçilen takvimdeki meşgul saatleri ayrıca sorgulamak gerekir. Ekip kaynağı değiştiğinde varsayılan takvim ayarının sessizce eski ID'ye bağlı kalmadığını periyodik kontrol edin.

Yayın öncesi kabul ve destek

Kabul tablosuna filtre kapalı ve açık listeyi, bütün sayfaları, kurum dışı paylaşılan takvimi, gizli takvimi, yetkisiz kullanıcıyı ve senkronizasyon yolunu yazın. Her satır için beklenen ID kümesi ile görünen ekranı karşılaştırın. Fark varsa önce API verisini, sonra uygulama önbelleğini inceleyin. Üretime geçince küçük bir kullanıcı grubunda yanlış takvim seçimi ve görünmeyen kaynak bildirimlerini izleyin. Bu güncelleme, her işletmede aynı takvim mimarisini zorunlu kılmaz.

Randevu veya teklif akışınız Google Workspace takvimleriyle bağlıysa, Webinle otomasyon yazılımları hizmeti kapsamında mevcut takvim listesini, erişim rollerini ve kabul testlerini birlikte değerlendirebilirsiniz. Teklif için örnek bir takvim seçimi sorunu ve beklenen iş akışını paylaşmanız yeterlidir; canlı kimlik bilgilerini göndermeyin.