Is the Google Calendar API free? Quotas, limits and the 2026 changes
Updated
TL;DR
Yes, for now: Google says "All standard use of the Google Calendar API is available at no additional cost." The quotas are 10,000 requests per minute per project, 600 per minute per user per project, and a daily billing threshold of 1,000,000 requests per project. Google plans to charge for usage above the limits "later in 2026" with at least 90 days' notice, and has not published a price or a start date.
Is it free?
Google's quota page for the Calendar API, last updated September 11, 2026, says: "All standard use of the Google Calendar API is available at no additional cost."
There is no per-request price today and no paid tier to sign up for. That is set to change for heavy users, as covered below.
The current quotas
| Quota | Limit |
|---|---|
| Requests per minute per project | 10,000 |
| Requests per minute per user per project | 600 |
| Daily billing threshold per project | 1,000,000 requests |
All three come from the quota page. The per-minute quotas can be raised: you request an adjustment from the Quotas & System Limits page in the Google Cloud console, and Google notes approval isn't guaranteed. The daily threshold can't: "You cannot request an increase on this daily threshold limit."
The per-user limit is the one most apps meet first. A sync job that walks one user's calendars in a tight loop can reach 600 requests a minute long before the project gets near 10,000.
Which quotas your project has
Google changed the numbers on May 1, 2026. In its words, "As of May 1, 2026, the usage limits for this API were updated." Two rules decide which numbers apply to you:
- "Google Cloud projects that made any use of this API between November 2025 and April 2026 will continue with their previously set usage quotas."
- "Cloud projects created on or after May 1, 2026 are subject to the new API quotas."
Google has not published the previous numbers, so an older project can't compare its quotas with the table above from the docs alone. The Quotas & System Limits page in the console shows what your project actually has.
What happens when you exceed them
The Calendar API answers with 403 or 429 and one of three reasons, listed in Google's error reference.
userRateLimitExceeded (403)
"One of the limits from the Developer Console has been reached." The message is "User Rate Limit Exceeded". Google's suggestions are to follow its quota practices, raise the per-user quota in the console, and use exponential backoff.
rateLimitExceeded (403 or 429)
"The user has reached Google Calendar API's maximum request rate per calendar or per authenticated user." Google says these "can return either 403 or 429 error codes" and "should be responded to in the same way, by using exponential backoff".
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "rateLimitExceeded",
"message": "Rate Limit Exceeded"
}
],
"code": 403,
"message": "Rate Limit Exceeded"
}
}quotaExceeded (403): "Calendar usage limits exceeded."
This one is different. It doesn't come from your project's quota. Google's description: "The user reached one of the Google Calendar limits in place to protect Google users" against abusive behavior. A short backoff won't clear it.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"message": "Calendar usage limits exceeded.",
"reason": "quotaExceeded"
}
],
"code": 403,
"message": "Calendar usage limits exceeded."
}
}Google's Workspace admin help lists the limits behind it and how long each takes to recover:
| Action in a short period | Limit | Recovery |
|---|---|---|
| Invitations to people outside the user's domains | 10,000 | "Possibly a month" |
| Events created | more than 100,000 | "Possibly several months" |
| Calendars created | more than 60 | "Possibly several hours" |
| Calendar shares | 750 | "Possibly several hours" |
Google's help page doesn't say whether API calls count toward these limits differently from the Calendar app, and doesn't define "a short period". Apps that create many events or send many external invitations from one account are the usual cause. The fix is to spread that work across the accounts it belongs to, not to retry.
The planned charges
Google announced the change on its Workspace developer tools page: "As of May 1, 2026, we are adjusting usage quotas across several Google Workspace product APIs", "starting with Gmail API, Google Calendar API, and Google Drive API." Quotas already in place "will remain unchanged for at least 60 days."
Then, "Later in 2026, following 90 days of notice":
- "Quota increase requests will require Google Cloud billing to be enabled."
- "API usage over standard daily thresholds will generate charges on your Google Cloud bill."
The quota page puts it this way: "Exceeding the quota request limits is planned to incur charges to your Google Cloud billing account later in 2026." And: "Full billing details will be shared later in 2026 with at least 90 days' notice before any changes take effect."
Google expects "less than 1% of active developers will need to move beyond the standard usage tier".
What Google has not announced
As of October 28, 2026:
- No price per request, or per thousand requests.
- No date charges start, beyond "later in 2026" and at least 90 days' notice.
- Whether charges apply only above the 1,000,000 daily threshold, or also when per-minute quotas are exceeded. The two Google pages word this differently.
- The quota numbers projects had before May 1, 2026.
Anyone quoting a Calendar API price today is guessing. The quota page is where Google has said the details will be shared.
Staying under the limits
Google's quota page recommends:
- Back off on time-based errors. Catch the error and retry with truncated exponential backoff.
- Use push notifications instead of polling. A push channel tells you when a calendar changed, and a sync token fetches only what changed. See calendar webhooks and push subscriptions.
- Spread out scheduled work. A daily sync should run at a random time, and recurring jobs should vary their interval by about 25% either way.
- Set quotaUser with domain-wide delegation. A service account acting for many users looks like one user to the per-user quota. The
quotaUserURL parameter, or thex-goog-quota-userheader, says which user to charge the request to.
Retries are also where duplicates come from. If a create request times out and you retry it, make sure the retry can't create the event twice.
How Pyas handles it
With Pyas Auth, requests run on Pyas's Google Cloud project, so they count against its project quota, not one of yours.
Pyas renews Google push channels itself and sends you changes as signed webhooks, such as event.created, event.updated and event.deleted, so you don't poll calendars to find changes. Webhooks are retried up to 8 attempts and can be replayed.
Writes accept an Idempotency-Key header, and Pyas keeps the answer for 24 hours, so retrying a create after a timeout returns the first result instead of a second event.
Pyas's own pricing is per connected account: free for 3, Starter at $15 a month for 10, Growth at $45 for 60 and Scale at $75 for 200. See pricing.
Common questions
Do I need a billing account to use the Calendar API?
Not today. Google says quota increase requests will need billing enabled once the changes announced for later in 2026 take effect.
Can I get more than 1,000,000 requests a day?
Not by asking. Google says you cannot request an increase on the daily threshold. Google's announcement says usage over the standard daily thresholds will be charged once billing starts.
Why do I get quotaExceeded when my project is nowhere near its quota?
Because quotaExceeded is a per-user Calendar limit, not a project quota. Check how many events or external invitations the account created recently.
Does a 429 mean something different from a 403 rateLimitExceeded?
No. Google says both should be handled the same way, with exponential backoff.