TL;DR

We trusted Google’s published quota (600 requests per minute per user and 10,000 per minute per application) , but hidden limits caused quotaExceeded errors after just a handful of requests.

We tried every recommended technique—back‑off, batch processing, splitting events and using multiple accounts—but nothing prevented the errors .

Google support’s only answer was to pay and wait 60 days — not feasible when your webinar is next week.

We switched to generating .ics files and providing an “Add to calendar” button; Gmail recognises these attachments so users can add events with one click .

Introduction

When we organise webinars at mentor.sh, we often manage hundreds of registrations. In one recent marketing campaign, more than 500 people registered within a few hours. Based on documentation from Google and third‑party vendors, we believed the Google Calendar API would comfortably handle this traffic because it advertises 600 requests per minute per user and 10,000 requests per minute per application . With those limits on paper, sending 500 invites seemed like a walk in the park. In practice, the path was covered in banana skins. We’re sharing this story so others can avoid slipping on the same obstacles.

Published quotas versus hidden limits

Google’s documentation differentiates between a per‑minute project quota and a per‑minute project‑per‑user quota. It recommends techniques like exponential back‑off and randomising traffic to avoid spikes . However, it never discloses the actual per‑user limits, and external sources indicate that only 600 requests per minute are guaranteed . Our console showed a daily quota of one million requests and 600 requests per minute; we believed we were far below those thresholds. Despite this, the system returned quotaExceeded errors after just a handful of requests .

Further digging uncovered several undocumented usage restrictions. Google Workspace support articles warn that sending invitations to 10,000 external guests or creating more than 100,000 events in a short time can trigger throttling for hours or months . Other reports note that a single user can only invite 100‑300 guests per event before encountering rate‑limit errors . It’s like playing a game where the rules change mid level — the documentation points one way, but hidden quotas lurk in the shadows. Alarmingly, increasing these limits requires paying at least $100 and waiting 60 days for the changes to take effect .

A May 2025 thread in Google’s Calendar help community described a booking SaaS that created fewer than 900 events over several months, far below the published quotas, yet still encountered persistent 403 errors . A community expert replied that many additional rate and quota limits exist across different time windows and that Google intentionally does not document them clearly . These reports reinforce that developers cannot reliably predict when the API will throttle them.

Our attempts to work within the API

We adopted Google’s recommended best practices—implemented exponential back‑off, randomised retries and used the batch endpoint. We tried every option we could think of, yet invites continued to fail. Even when sending fewer than ten requests per second, errors persisted. Facing this, we explored a range of solutions:

Adjusting the back‑off algorithm. We tuned delay intervals and jitter values, but the API still returned 403 and 429 errors .
Reducing API insistence. We lowered concurrent requests and allowed longer gaps between calls, hoping to avoid triggering per‑user limits. This only slowed delivery while errors continued.
Processing attendees in batches. Although Google’s batch endpoint counts a batch as a single request, large batches appeared more likely to be throttled .
Creating separate events per attendee. We experimented with one event per person; this removed the guest list limit but increased calendar clutter — imagine 500 one‑off “webinar” events cluttering your calendar.
Creating multiple events with limited guest counts. For example, ten events with fifty attendees each. This worked briefly before running into the same underlying quota issues.
Using multiple Google accounts. We rotated between several service accounts in a round‑robin pattern to distribute load. It felt like playing whack‑a‑mole — as soon as one account reached its limit, another popped up.
Consulting community resources. We scoured forums and found reports from other developers experiencing persistent 403 errors while operating well below the per‑minute quotas — misery loves company . Expert responses highlighted that Google enforces additional hidden quotas across seconds, days and weeks that are not clearly documented .

Despite these efforts, every attempt produced the same quotaExceeded errors; we never reached the published quotas, yet the API would not relent. Google’s own guidelines state that exceeding undisclosed thresholds leads to throttling with no immediate remedy . When we contacted support, they offered no workaround other than paying and waiting two months . Waiting for 60 days was impossible for a webinar scheduled in a week. We were not unwilling to pay, but we do not run our infrastructure on Google Cloud and could not hold our audience hostage while the limits were lifted.

A pragmatic alternative: .ics files

Given the unpredictability and opaque throttling, we decided to eliminate the dependency on the Google Calendar API entirely. Instead of programmatically inviting each registrant, our platform now generates an .ics calendar file on the fly and presents an “Add to calendar” button in the user interface and email notifications. .ics files are a standard format supported by all major calendar providers. Marketing platforms such as HubSpot recommend including them alongside Google Calendar links for maximum compatibility . Gmail automatically detects .ics attachments and displays an “Add to Google Calendar” button, allowing recipients to add the event with a single click . As a side benefit, direct invites from unknown senders are often muted by Gmail and Google Calendar, whereas .ics files respect the user’s default notification settings.

Our updated approach removes the risk of hitting hidden quotas and gives attendees more control over their calendars. It also simplifies our backend: we generate the .ics file containing the webinar date, time, description and join link, then include it in the confirmation email and on the event page. Users can add the event to Google Calendar, Outlook, Apple Calendar or any other service without reliance on Google’s API.

Lessons learned

This experience taught us that external APIs—especially those tied to consumer platforms—can have hidden constraints that documentation doesn’t reveal. When building high‑reliability systems, we must design around these limitations or choose alternatives that put the user in control. By switching to downloadable calendar invites, we improved robustness, avoided surprise throttling and provided a better experience for attendees. We share this story not to complain but to offer lessons learned, hoping that other teams can avoid the frustration and wasted time we experienced. We’ve been there — we feel your pain — and we hope this write‑up spares you some headaches.

Upcoming sessions

We continue to host live webinars and group sessions at mentor.sh. Here are two upcoming events you might be interested in:

The Software Engineer’s Guide to Salary Negotiation – an in‑depth workshop by David Guida focused on negotiating compensation packages effectively. Learn more and register here: https://mentor.sh/mentors/davidguida/5.