Google Calendar API Quotas and Limits

What are the Google Calendar API quota limits?

The Google Calendar API quota limits are 10,000 requests per minute per project and 600 requests per minute per user per project for Cloud projects created on or after May 1, 2026. Projects that used the API between November 2025 and April 2026 keep their previously set quotas for now.

Quotas are calculated per minute using a sliding window, so a burst that exceeds the limit in one minute triggers rate limiting in the next window until average usage falls back under the cap. Google also added a daily billing threshold of 1,000,000 requests per day per project. Usage under the threshold costs nothing today; per the Calendar API usage limits, full billing details arrive later in 2026 with at least 90 days' notice, and the threshold itself can't be increased.

What is the difference between 403 and 429 quota errors?

Google Calendar API returns quota errors as HTTP 403 or HTTP 429, both carrying the usageLimits domain. A 403 with reason userRateLimitExceeded means one user blew past the 600-per-minute per-user limit, while rateLimitExceeded arrives as either status code.

Google's Calendar API error guide says rateLimitExceeded errors “can return either 403 or 429 error codes—currently they are functionally similar and should be responded to in the same way, by using exponential backoff.” The 429 status itself comes from RFC 6585, published in April 2012, which defines it as “Too Many Requests.” See RFC 6585 for the formal definition.

A third reason, quotaExceeded, signals general Calendar usage limits that protect Google's infrastructure from abuse and is unrelated to your per-minute project quota. The error body below is the exact 403 payload from Google's documentation, so you can match on the reason field rather than the status code.

{
  "error": {
    "errors": [
      {
        "domain": "usageLimits",
        "reason": "rateLimitExceeded",
        "message": "Rate Limit Exceeded"
      }
    ],
    "code": 403,
    "message": "Rate Limit Exceeded"
  }
}

How does exponential backoff work for Calendar API errors?

Exponential backoff for Calendar API quota errors waits min((2^n) + random_ms, maximum_backoff) between retries, where random_ms is up to 1,000 milliseconds of jitter and maximum_backoff is typically 32 or 64 seconds.

The jitter matters more than it looks. Without it, hundreds of clients that got rate limited in the same window all retry at the same instant and produce synchronized waves that keep tripping the limit. Google recommends recalculating the random component on every retry and capping total attempts so clients never retry indefinitely. After the wait reaches the 64-second ceiling, retries continue at that fixed interval instead of growing further.

This shell wrapper applies truncated backoff to any command, including a CLI calendar read. It retries up to 6 times, doubling the wait from 2 seconds to a 64-second cap with up to 1 second of jitter, then gives up with a non-zero exit code.

attempt=0
until nylas calendar events list --days 7 --json; do
  attempt=$((attempt + 1))
  [ "$attempt" -gt 6 ] && echo "giving up after 6 retries" && exit 1
  wait=$(( 2 ** attempt ))
  [ "$wait" -gt 64 ] && wait=64
  sleep $(( wait + RANDOM % 2 ))
done

How do I read Google Calendar without burning project quota?

Reading Google Calendar through the Nylas CLI consumes none of your Cloud project's Calendar API quota because no Cloud project is involved: OAuth, token refresh, retries, and pagination run through the Nylas API instead. One command lists events from Google, Outlook, and iCloud calendars with identical flags.

The nylas calendar events list command defaults to the next 7 days and 10 events, auto-paginates above 200 results, and emits JSON with --json for scripting. For free/busy lookups, nylas calendar availability check answers in one call what would otherwise be a freebusy query you'd have to budget against your per-user limit.

# List the next 7 days of events as JSON
nylas calendar events list --days 7 --limit 50 --json

# Check free/busy for two people over the next 8 hours
nylas calendar availability check --emails alice@example.com,bob@example.com --duration 8h

For cron jobs and CI, authenticate once with nylas auth config --api-key instead of a browser flow. Setup steps live in the getting started guide. Provider-side limits still exist upstream, but the retry and pagination logic that handles them is no longer code you maintain.

How do I request a Google Calendar API quota increase?

Request a Google Calendar API quota increase from the Quotas & System Limits page in the Google Cloud console. Approval isn't guaranteed, requests for large jumps take longer to review, and the 1,000,000-request daily billing threshold can't be raised at all. Only the two per-minute limits are adjustable.

Two planning details from the Calendar API usage limits page catch teams off guard. First, API calls made by a service account count as a single user, so a backend that syncs 5,000 calendars through one service account hits the 600-per-minute per-user ceiling long before the 10,000-per-minute project limit. Setting the quotaUser parameter spreads that usage across logical users. Second, not all projects carry the same quotas, and Google notes that growing usage might require requesting higher values, so check your actual numbers before sizing a sync job.

Google advises requesting adjustments proactively when you expect a usage spike rather than after the 403s start. If your workload is read-heavy calendar sync rather than event writes, compare the math against a quota-free CLI read first; the increase request may be unnecessary.

Next steps

• Calendar API Time Zone Handling Explained — IANA vs Windows zone IDs, all-day events without zones, DST drift…
• Gmail API quotas in 2026 — the parallel May 1, 2026 changes on the email side: quota units, method costs, and billing threshold
• Google Calendar API pagination — pageToken, syncToken, and 410 GONE handling for full calendar syncs
• Email API rate limits compared — Gmail quota units, Microsoft Graph throttling, and provider retry strategies side by side
• OnSched vs Nylas — scheduling API alternatives when booking volume outgrows quota budgets
• Acuity Scheduling API alternative — developer-first scheduling without per-seat pricing
• Calendar events list command — every flag for bounded, paginated event reads
• Calendar availability check command — free/busy lookups across participants
• Full command reference — every flag and subcommand documented
• Calendar API usage limits — Google's official quota table and backoff algorithm
• Calendar API error reference — every error code with its JSON payload
• RFC 6585 — the standard that defines HTTP 429 Too Many Requests