API integration for Google Calendar
We build your Google Calendar connector
We wire the Google Calendar API into your scheduling to the Google Calendar API to create events, read availability and pick up moves made from the phone.
- Senior product team
- calendar sync in production
- from scoping to monitoring
What does the Google Calendar API provide and why connect it to your application?
The Google Calendar API lets your application read and write to the Google calendars of your users or your organisation. You integrate it to automatically create an event when a meeting is confirmed, display availability in a scheduler, or trigger a business action when an event is modified or cancelled. The practical result: the business schedule lives in the calendar that teams already open, and changes made from a mobile phone are immediately reflected in the software without any re-entry.
What our clients build on the Google Calendar API
Field jobs in the technician's calendar
Each job becomes an event with address, contact and a Meet link. No more pasted video URLs, no more missed appointments the technician never saw.
Slots offered against real free/busy
Freebusy queries several calendars before a slot is shown. You offer what is free, instead of discovering the clash afterwards.
Capacity read from the calendar
outOfOffice, focusTime and workingLocation become planning data. A practice or training centre stops keeping absences in a spreadsheet.
Sales meeting tied to the deal
Your business id travels in extendedProperties. If the slot is moved or cancelled in Google, the CRM knows without a mapping table that drifts.
What this changes in your planning
The engineering serves a measurable result: one calendar, real slots, no double entry.
Double entry stops
The product writes to Google, and reads back what the collaborator moved from their phone. The two calendars stop contradicting each other.
Slots people can actually keep
You no longer offer a time that is already taken. Fewer reschedules, fewer no-shows born from an invisible clash.
Meet without a workaround
The video link is created with the event. No reused conference that exposes a meeting to the wrong person.
Planning stays fresh without saturating Google
We listen for changes instead of rescanning every minute. The connector holds, including Workspace delegation.
How we deliver your Google Calendar connector
Scoping
Which calendars, which sync direction, which event types, Meet or not, which OAuth scope. Recurrence and time zones are listed before a line of code.
Development
syncToken per calendar, push channels renewed before expiry, quotaUser under delegation, business key in extendedProperties. A demo every week.
Acceptance
Mobile move, 410 on syncToken, expired channel, DST recurrence, forgotten conferenceDataVersion: each trap is replayed before cutover.
Monitoring
Alerts on 410, dead channels, 429. A watch log. You know a calendar is deaf before technicians' Monday morning.
What the Google Calendar API allows
- Events and business types
- Create, read, patch. eventType (default, outOfOffice, focusTime, workingLocation, birthday) is immutable after insert. fromGmail cannot be created via the API.
- Free/busy and calendar lists
- Freebusy across several calendars before any create. CalendarList and ACL so you see what the user actually sees, not what your database assumes.
- Google Meet via the API
- conferenceData.createRequest with hangoutsMeet and a client requestId. Creation is asynchronous (pending, success, failure). conferenceDataVersion=1 is required to keep the conference.
- Incremental sync and push
- nextSyncToken on the last page, then syncToken. Push only on Events, CalendarList, ACL and Settings. The notification has no body: you must re-read.
Google Calendar API vocabulary
- syncToken
- Increment token, present only on the last page. Replay it identically. If it expires, Google returns 410 Gone: that is not an anomaly, it is the signal to re-read everything.
- X-Goog-Resource-State
- State on the notification (sync, exists, not_exists). exists covers create, update and delete. The message number increases without being sequential: do not dedupe on it.
- extendedProperties
- Intended place for your business key, private or shared. The clean way to find your events after a move made in the Google UI.
- conferenceDataVersion
- Set to 1 on insert, update and patch, otherwise Meet is not persisted. The createRequest requestId must stay stable for idempotency.
- quotaUser
- Query parameter or x-goog-quota-user header. Without it, a Workspace service account consumes the per-user quota alone and hits 429 across hundreds of calendars.
- eventType
- Event type, immutable after creation. default, birthday, focusTime, fromGmail, outOfOffice, workingLocation. A client that freezes an exhaustive enum will break on the next type.
The real constraints of the Google Calendar API
The notification does not say what changed
Empty body, Content-Length 0, exists for everything. Any architecture that expects a payload is wrong: you re-read with syncToken. The handler only validates the channel token, enqueues, and returns 200.
Two rate limits, and a daily cap
10,000 requests per minute per project, 600 per minute per user. Daily threshold 1,000,000, not increasable. Billing for overage is announced for later in 2026, with at least 90 days' notice.
No automatic channel renewal
Recreate the watch with a different id before expiry, and accept a window where two channels deliver the same signal. Google offers no HMAC: the channel token is the defence.
Recurrence, time zones, frozen filters
IANA end.timeZone is required on a recurrence. A syncToken is incompatible with a filter that moves (timeMin, singleEvents). A full sync at midnight is a documented anti-pattern: Google asks for a random hour, plus or minus 25%.
Google Calendar API or Microsoft Graph?
Two work calendars. The right one follows the installed estate, not a technical preference.
| Criterion | Google CalendarThis page | Microsoft OutlookGraph calendar and mail |
|---|---|---|
| Typical estate | Google Workspace | Microsoft 365, French SMEs and mid-market |
| Scope | Calendar, not mail | Calendar and mail on the same Graph |
| Notification | Push with no body, syncToken re-read | Graph subscription, id or rich payload |
| Availability | Freebusy | getSchedule and findMeetingTimes, rooms included |
| Video | Meet via conferenceData | Teams on the tenant, not this page |
| Webhook signature | No HMAC, channel token only | Graph subscription validation, then re-read |
| The right case | Your teams live in Google Calendar | Your teams live in Outlook |
Both combine on a mixed estate. That is a scoping call, not a final choice. Calendly and Cal.com cover booking, not the work calendar.
What we measure on a Google Calendar integration
The other calendar APIs
If not everyone lives in Google, these options belong in the scoping conversation.
Google CalendarWe build your Google Calendar connectorThis page
Microsoft OutlookCalendar and mail via Microsoft Graph, often already on the tenant.
CalendlyHosted booking, not a work calendar.
Cal.comOpen-source booking engine, self-hostable.We combine Google Calendar with
The stack around Calendar on our projects.
Google Calendar integration: your questions
Two mechanisms, not one. Push (watch) tells you something happened, without saying what: the notification has no body. Incremental sync (syncToken) then re-reads only the changes, deletions included. Persist one token per calendar, treat 410 as a nominal path (purge and full resync), and put your business id in extendedProperties so you do not depend on a parallel table. A full scan at a fixed hour is the anti-pattern Google documents.
OAuth 2.0 (or Workspace domain-wide delegation), a connector that creates and patches events with conferenceDataVersion=1 if you want Meet, Freebusy before a slot is shown, then watch plus syncToken for the return path. The hard part is not insert, it is channel renewal, quotaUser under delegation, and IANA time zones on recurrences. We scope which calendars, which direction, which types before writing the HTTP client.
A first useful flow, typically creating events in the collaborator's calendar with a business key, ships in two to three weeks. Two-way sync with push, 410 handling, Meet and Freebusy is closer to six to eight weeks depending on calendar count and recurrence complexity. We scope the perimeter up front and give a firm estimate before we start. This is a scoping call, written down before the first request, not an acceptance surprise.
No. They only carry headers (channel, exists or not_exists, a non-sequential number). exists means re-read, not created or deleted. Without a worker that re-reads on syncToken, you accumulate signals and no data. There is no HMAC: check the channel token against a table, return 200 immediately, and dedupe on the channel/resource pair, not on the message number. This is a scoping call, written down before the first request, not an acceptance surprise.
Follow the estate, not the developer's preference. Workspace: Calendar v3. Microsoft 365: Graph (events, calendarView, getSchedule). A mixed estate takes both connectors and a priority rule per person. Calendly and Cal.com do not replace this calendar: they carry booking, with their own availability rules. This is a scoping call, written down before the first request, not an acceptance surprise. Calendly and Cal.com sit on top, they do not replace the work calendar.
A Google Calendar integration project?
Let's talk. 30 minutes to scope your calendars, the sync direction and what the API really allows, then tell you plainly what is feasible.
Discuss my Calendar project