Google Calendar API 403 "rate limit exceeded" when the scheduler agent bulk-creates interview events
Adds backoff and pacing to a scheduler agent hitting Google Calendar quotas. Use it when bulk interview creation returns 403 rate-limit errors. Key trigger: bursts of creates push quota usage near 100 percent.
TL;DR: Slow down and retry smart: add exponential backoff with jitter on the 403s and pace event creation instead of bursting. The quota is real and the API will keep refusing until usage drops, so the fix is in the agent's send pattern, not in retrying harder.
Google Calendar API 403 "rate limit exceeded"- Confirm it is quota: check the 403 response details and the API quota page in Google Cloud Console. Expected: quota usage at or near 100 percent for the Calendar API.
- Add exponential backoff with jitter on 403 responses (for example 2s, then 4s, then 8s) with a sane max retry count. Expected: retries start succeeding instead of hard-failing.
- Pace the creates: add a rate limiter (a token bucket or fixed delay) so the agent never bursts. Expected: steady successful creates with no 403s.
- If legitimate volume still exceeds quota, request a quota increase in the Cloud Console. Expected: higher quota approved and headroom restored.
Use this when
- Bulk calendar writes return 403 rate-limit errors.
- The scheduler creates many interviews in a short window.
- Errors correlate with burst timing, not auth changes.
Not for this skill when
- The 403 says insufficient permissions (an auth scope problem).
- The 403 is a daily quota vs per-user quota issue (different fix per type).
- The error is 404 or 409 (different problems entirely).
Variant phrasings
- "Calendar API quota exceeded"
- "403 userRateLimitExceeded calendar"
- "Google Calendar API limit bulk create"
- "calendar rateLimitExceeded scheduler"
Why it happens
The Calendar API enforces per-user and per-project quotas, and scheduler agents that bulk-create interviews fire dozens of requests in seconds. The burst exhausts the quota window and every further request gets refused until it resets.
Edge cases
- Per-user and per-project quotas are separate; raising one may not fix the other.
- Backoff without jitter causes synchronized retries that re-trigger the limit (thundering herd).
- Calendar usage limits (events per calendar) are separate from API quotas.
- The batch endpoint still counts each sub-request against quota.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_DAmRclQW9aZ4KfaUx2aZGA