Google, içerikleri tercih ettiğiniz dile çevirmek için yapay zeka teknolojisini kullanır. Yapay zeka çevirilerinde hata olabilir.

Kullanım sınırları

Google Takvim API'si, tüm kullanıcılar tarafından adil bir şekilde kullanılmasını sağlamak için kotalara sahiptir. Calendar API'yi kullanırken dikkate alınması gereken üç önemli sınırlama vardır:

API kullanım kotaları: Proje ve kullanıcı başına uygulanır. Daha fazla bilgi için Calendar API kullanım kotası türleri başlıklı makaleyi inceleyin.
Genel Google Takvim kullanım sınırları: Google Takvim API'si, Google Workspace sisteminin genel performansını korumak için sınırlamaları olan paylaşılan bir hizmettir. Daha fazla bilgi için Takvim kullanım sınırlarından kaçınma başlıklı makaleyi inceleyin.
İşlem sınırları: Bu sınırlar herhangi bir zamanda kısıtlanabilir. Örneğin, tek bir takvime hızlı bir şekilde art arda yazmaya çalışırsanız.

Calendar API kotaları

İki tür kota uygulanır:

Proje başına dakika başına: Google Cloud projenizin bir dakikada yapabileceği istek sayısıdır.
Kullanıcı başına her projede bir dakika içinde gönderilen istek sayısı: Belirli bir kullanıcının Cloud projenizde gönderebileceği istek sayısıdır. Bu sınır, kullanımın kullanıcılarınız arasında adil bir şekilde dağıtılmasını sağlamanıza yardımcı olmayı amaçlar.

Kotalar, kayan bir zaman aralığı kullanılarak dakika başına hesaplanır. Bir dakika içinde dakika başına kotanızı aşan hızlı bir trafik artışı, ortalama kullanımınızın kotalar dahilinde kalmasını sağlamak için bir sonraki pencerede sıklık sınırlamasına neden olur.

Aşağıdaki tabloda bu sınırlar ayrıntılı olarak açıklanmıştır:

Kullanım sınırı türü	Sınır
Proje başına dakikalık	10.000 istek
Proje başına kullanıcı başına dakikalık	600 istek

Günlük faturalandırma eşiği

Proje başına günlük sınır, Google Cloud projenizin ücretlendirme uygulanmadan önce 24 saatlik bir süre içinde kullanabileceği maksimum istek sayısını tanımlar.

Bu eşiğin altındaki kullanım için ek ücret alınmaz ve Google Cloud hesabınız faturalandırılmaz. Faturalandırmayla ilgili tüm ayrıntılar 2026'nın ilerleyen dönemlerinde, değişiklikler geçerlilik kazanmadan en az 90 gün önce paylaşılacak.

Bu günlük eşik sınırının artırılmasını talep edemezsiniz.

Aşağıdaki tabloda sınırla ilgili ayrıntılar verilmiştir:

Eşik sınırı türü	Sınır
Proje başına günlük	1.000.000 istek

Daha fazla bilgi için Temsilci araçları ve API'ler için Google Workspace standartlaştırılmış modeli başlıklı makaleyi inceleyin.

Zamana dayalı kota hatalarını çözme

Zamana dayalı tüm hatalar için (X dakikada en fazla N istek) kodunuzun istisnayı yakalamasını ve cihazlarınızın aşırı yük oluşturmamasını sağlamak için kesilmiş eksponansiyel geri yükleme kullanmasını öneririz.

Eksponansiyel geri yükleme, ağ uygulamaları için standart bir hata işleme stratejisidir. Eksponansiyel geri yükleme algoritması, istekler arasında eksponansiyel olarak artan bekleme süreleri kullanarak istekleri yeniden dener. Bu süre, maksimum geri yükleme süresine kadar artar. İstekler hâlâ başarısız oluyorsa istekler arasındaki gecikme süresinin, istek başarılı olana kadar zaman içinde artması önemlidir.

Örnek algoritma

Eksponansiyel geri yükleme algoritması, istekleri eksponansiyel olarak yeniden dener ve yeniden denemeler arasındaki bekleme süresini maksimum geri yükleme süresine kadar artırır. Örneğin:

Google Takvim API'ye istek gönderme
İstek başarısız olursa 1 + random_number_milliseconds bekleyin ve isteği yeniden deneyin.
İstek başarısız olursa 2 + random_number_milliseconds bekleyin ve isteği yeniden deneyin.
İstek başarısız olursa 4 + random_number_milliseconds bekleyin ve isteği yeniden deneyin.
Bu şekilde maximum_backoff kez devam eder.
Maksimum deneme sayısına ulaşana kadar beklemeye ve yeniden denemeye devam edin ancak denemeler arasındaki bekleme süresini artırmayın.

Bu örnekte:

Bekleme süresi min(((2^n)+random_number_milliseconds), maximum_backoff) olup n her iterasyon (istek) için 1 artırılır.
random_number_milliseconds, 1.000'den küçük veya 1.000'e eşit rastgele bir milisaniye sayısıdır. Bu sayede, birçok istemcinin bir durum nedeniyle senkronize edildiği ve hepsinin aynı anda yeniden deneme yaparak senkronize dalgalar halinde istek gönderdiği durumlar önlenir. random_number_milliseconds değeri, her yeniden deneme isteğinden sonra yeniden hesaplanır.
maximum_backoff genellikle 32 veya 64 saniyedir. Uygun değer, kullanım alanına bağlıdır.

İstemci, maximum_backoff süresine ulaştıktan sonra yeniden denemeye devam edebilir. Bu noktadan sonraki yeniden denemelerde bekleme süresinin artırılmasına gerek yoktur. Örneğin, bir istemci 64 saniyelik bir maximum_backoff süresi kullanıyorsa bu değere ulaştıktan sonra her 64 saniyede bir yeniden deneyebilir. Bir noktada, istemcilerin süresiz olarak yeniden denemesi engellenmelidir.

Yeniden denemeler arasındaki bekleme süresi ve yeniden deneme sayısı, kullanım alanınıza ve ağ koşullarınıza bağlıdır.

Fiyatlandırma

Google Takvim API'nin tüm standart kullanımları ek ücret ödemeden kullanılabilir. Kota istek sınırlarının aşılması durumunda 2026'nın ilerleyen dönemlerinde Google Cloud Faturalandırma Hesabınızdan ücret alınması planlanmaktadır. Daha fazla bilgi için Temsilci araçları ve API'ler için Google Workspace standartlaştırılmış modeli başlıklı makaleyi inceleyin.

Kota artışı isteme

Projenizin kaynak kullanımına bağlı olarak kota düzenlemesi isteğinde bulunabilirsiniz. Bir hizmet hesabı tarafından yapılan API çağrılarının tek bir hesap kullandığı kabul edilir. Kota düzenlemesi başvurusunda bulunmak onay alacağınıza dair bir garanti teşkil etmez. Kota değerini önemli ölçüde artıracak kota ayarlama isteklerinin onaylanması daha uzun sürebilir.

Her projenin kotası aynı değildir. Zaman içinde Google Cloud'u daha fazla kullandıkça kota değerlerinizi artırmanız gerekebilir. Kullanımda kayda değer bir artış bekliyorsanız Google Cloud Console'daki Kotalar ve Sistem Sınırları sayfasından proaktif olarak kota düzenlemesi isteyebilirsiniz.

Daha fazla bilgi için aşağıdaki kaynaklara göz atın:

Sorun giderme

Kotalardan biri aşılırsa sıklık sınırlaması uygulanır ve sorgularınıza yanıt olarak 403 usageLimits durum kodu veya 429 usageLimits durum kodu alırsınız.

Bu durumda aşağıdakileri deneyebilirsiniz:

Tüm en iyi uygulamaları takip ettiğinizden emin olun: Eksponansiyel geri yükleme kullanın, trafik kalıplarını rastgele hale getirin ve push bildirimleri kullanın.
Projeniz büyüyorsa ve daha fazla kullanıcınız varsa kota artışı isteyebilirsiniz.
Kullanıcı başına kota sınırlarına ulaşırsanız aşağıdakileri yapabilirsiniz:
- Hizmet hesabı kullanıyorsanız yükü kullanıcılara paylaştırın veya birden fazla hizmet hesabı arasında bölün.
- Kullanıcı başına kotanın artırılmasını talep edebilirsiniz ancak genel olarak bu kotanın varsayılan değerin üzerine çıkarılması önerilmez. Bunun nedeni, uygulamanızın diğer sınır türlerine (ör. genel takvim kullanım sınırları veya operasyonel sınırlar) ulaşmaya başlayabilmesidir.
Üretim projenize benzer bir yapılandırmaya sahip, yalnızca test amaçlı ayrı bir proje kaydederek kota sınırlarınızı test edin. Daha fazla bilgi için Kota sınırı işlemeyi test etme bölümüne bakın.

Trafik düzenlerini rastgele hale getirme

Takvim istemcileri, birden fazla istemcinin aynı anda işlem yapması nedeniyle ani trafik artışlarına neden olabilir. Örneğin, Takvim istemcileri için gece yarısı tam senkronizasyon yapmak yaygın bir kötü uygulamadır. Bu durum, dakikalık kotanızın aşılmasına neden olur ve sıklık sınırlaması ile geri çekme işlemlerine yol açar.

Bunu önlemek için trafiğinizin mümkün olduğunca gün içine yayılmasını sağlayın. Müşterinizin günlük senkronizasyon yapması gerekiyorsa müşterinin rastgele bir zaman (her müşteri için farklı) belirlemesini sağlayın. Bir işlemi düzenli olarak yapmanız gerekiyorsa aralığı +/-%25 oranında değiştirin. Bu sayede trafik daha dengeli bir şekilde dağıtılır ve çok daha iyi bir kullanıcı deneyimi sunulur.

Push bildirimlerini kullanma

Yaygın kullanım alanlarından biri, kullanıcının takviminde bir değişiklik olduğunda işlem yapmaktır. Burada bir anti-pattern, ilgilenilen her takvimi tekrar tekrar yoklamaktır. Bu, kotanızın tamamını çok hızlı bir şekilde tüketir. Örneğin, uygulamanızın 5.000 kullanıcısı varsa ve her kullanıcının takvimini dakikada bir kez sorguluyorsa bu, herhangi bir işlem yapılmadan önce bile dakikada en az 5.000 kota gerektirir.

Sunucu tarafı uygulamalar, push bildirimlerine kaydolabilir. Bu sayede, ilgilendiğiniz bir şey olduğunda sizi bilgilendirebiliriz. Bu yöntemlerin ayarlanması daha fazla çalışma gerektirir ancak kotanızın çok daha verimli kullanılmasını sağlar ve daha iyi bir kullanıcı deneyimi sunar. Bildirim almak istediğiniz eventType belirttiğinizden emin olun. Daha fazla bilgi için Push bildirimleri başlıklı makaleyi inceleyin.

Hizmet hesaplarıyla doğru tahsis

Uygulamanız alan genelinde yetki kullanarak istek gönderiyorsa varsayılan olarak hizmet hesabından "proje başına kullanıcı başına dakika başına" kotaları için ücret alınır. Kimliğine büründüğünüz kullanıcıdan ücret alınmaz. Bu, hizmet hesabının birden fazla kullanıcının takviminde çalışıyor olsa bile kotasının dolabileceği ve sıklık sınırlamasına tabi tutulabileceği anlamına gelir.

Her bir kullanıcıyı benzersiz şekilde tanımlayan rastgele bir dize (en fazla 40 karakter) belirtmek için quotaUser URL parametresini (veya x-goog-quota-user HTTP üstbilgisini) kullanarak bu durumun önüne geçebilirsiniz. Calendar API, bu değeri yalnızca kota hesaplamaları için kullanır.

Kullanıcı başına sıklık sınırlarını farklı kullanıcılar arasında zorunlu kılmak için quotaUser kullanmak istiyorsanız isteklerinizin aşağıdaki koşulları karşılaması gerekir:

IP kısıtlamalı bir API anahtarı ekleyin: key sorgu parametresinde bir API anahtarı iletin ve bu anahtarı, arka uç sunucularınızın herkese açık IP adreslerini belirten IP adresi kısıtlamaları ile yapılandırın. API anahtarını atlarsanız veya IP adresi kısıtlamalarını yapılandırmazsanız Calendar API, quotaUser parametresini yoksayar ve kimliği doğrulanmış hesaptan (ör. hizmet hesabı) kota ücreti alır.
X-Goog-User-Project üstbilgisini atla: quotaUser kullanan isteklerde X-Goog-User-Project HTTP üstbilgisi göndermeyin. Kullanıcı projesi sağlandığında kota ilişkilendirmesi için API anahtarı geçersiz kılınır. Bu nedenle, Takvim API'si quotaUser değerini yoksayar.

Daha fazla bilgi için Kullanıcı başına istekleri sınırlama başlıklı makaleyi inceleyin.

Kota sınırı yönetimini test etme

Uygulamanızın, pratikte kota sınırlarına ulaşma durumunu sorunsuz bir şekilde yönetebildiğinden (ör. eksponansiyel geri yükleme ile yeniden denemeler yoluyla) emin olmak ve kullanıcılarınızın karşılaşabileceği olası rahatsızlıkları en aza indirmek için senaryonuzu gerçek bir ortamda test etmenizi önemle tavsiye ederiz.

Gerçek uygulama kullanımınıza müdahale etmeden test yapmak için Google Cloud Console'da yalnızca test amaçlı ayrı bir proje kaydetmenizi ve ardından OAuth kullanıcı rızası ekranını üretim projenize benzer şekilde yapılandırmanızı öneririz. Ardından bu proje için yapay olarak düşük kota sınırları belirleyebilir ve uygulamanızın davranışını gözlemleyebilirsiniz.

Takvim MCP sunucusu kotaları

Takvim MCP sunucusu, sorgu maliyeti tahsis metriği kullanır. Aşağıdaki tablolarda, her bir Takvim MCP sunucusu yönteminin sorgu maliyeti bölümlere göre ayrıntılı olarak açıklanmıştır:

Takvim MCP kotaları