Calendar Integrations: Cal.com, Google, Outlook

Voice agents that book, reschedule, or cancel appointments live or die on their calendar integration. A voice agent that guesses at availability or writes to the wrong calendar breaks the workflow it was built for. The good news: calendar APIs are mature in 2026, and the major platforms (Cal.com, Calendly, Google Calendar, Microsoft Outlook) all have clean APIs that voice agents can integrate with reasonably. The tricky parts are time zones, OAuth, concurrency, and handling the specific quirks of each platform.

This piece walks through integrating voice agents with the major calendar systems, the patterns that work, and what to watch out for.

TL;DR

• Cal.com and Calendly are designed for scheduling; integration is clean.
• Google Calendar and Outlook are general-purpose; integration requires more glue.
• OAuth 2.0 for user-scoped calendars; service accounts for admin-scoped.
• Time zones, recurrences, and availability windows are the main complexity.
• Test with real user calendars before production; sandbox behavior differs.

The four platforms

Cal.com. Open-source-core scheduling platform. Clean REST API. Booking-focused. Good for voice AI that books into specific event types.

Calendly. Closed-source scheduling platform. Good API. Booking-focused. Similar integration pattern to Cal.com.

Google Calendar. General-purpose calendar. Very mature API. Lots of edge cases. Most widely used.

Microsoft Outlook / Office 365. General-purpose calendar. Microsoft Graph API. Enterprise-heavy.

Each has its own auth model, data model, and quirks.

Cal.com integration

API base: https://api.cal.com/v2/

Auth: API key (personal or team).

Key endpoints:

• GET /slots/available — query availability.
• POST /bookings — create a booking.
• PATCH /bookings/{id} — update.
• DELETE /bookings/{id} — cancel.

Simple, REST-native, event-type-centric. Cal.com models "event types" (e.g., "30-minute Discovery Call") and availability flows from the event type's rules.

Voice agent flow:

1. User requests booking.
2. Agent queries available slots for the specific event type.
3. Agent offers 2–3 slots.
4. Agent creates booking.
5. Cal.com sends confirmation to user.

Calendly integration

API base: https://api.calendly.com/

Auth: OAuth 2.0 or personal access token.

Key endpoints:

• GET /event_type_available_times — availability.
• POST /scheduled_events (indirect via invitee flow) — book.
• GET /users/me — current user context.

Calendly's booking flow is typically a two-step — generate a booking URL, send to user. For voice AI, this is awkward. Some integrations work around it with server-side booking APIs.

Google Calendar integration

API base: https://www.googleapis.com/calendar/v3/

Auth: OAuth 2.0 (user-scoped) or service account with domain-wide delegation (admin-scoped).

Key endpoints:

• GET /calendars/{calendarId}/events — list events.
• POST /calendars/{calendarId}/events — create event.
• GET /freeBusy — availability query across calendars.
• PATCH /calendars/{calendarId}/events/{eventId} — update.
• DELETE /calendars/{calendarId}/events/{eventId} — cancel.

Availability querying is via freeBusy API:

POST /freeBusy
{
  "timeMin": "2026-04-16T09:00:00Z",
  "timeMax": "2026-04-17T17:00:00Z",
  "items": [{"id": "[email protected]"}]
}

Returns busy periods; available slots are the complement.

Outlook (Microsoft Graph) integration

API base: https://graph.microsoft.com/v1.0/

Auth: OAuth 2.0 (user-scoped) or application permissions (admin-scoped).

Key endpoints:

• GET /me/calendar/events — list events.
• POST /me/calendar/events — create event.
• POST /me/calendar/getSchedule — availability query.
• PATCH /me/calendar/events/{id} — update.
• DELETE /me/calendar/events/{id} — cancel.

Similar capability to Google Calendar but Microsoft-Graph-flavored. Availability via getSchedule.

OAuth flow

For user-scoped calendars:

1. Voice agent redirects user (one-time) to OAuth consent screen.
2. User approves.
3. Code returned; voice agent exchanges for access + refresh tokens.
4. Tokens stored encrypted.
5. Access tokens expire (usually 1 hour); refresh token used to get new ones.

Handle refresh-token rotation, expiration, revocation.

Service accounts / admin-scoped

For office deployments where all staff calendars are accessed centrally:

• Google: service account with domain-wide delegation.
• Microsoft: application permissions granted by admin consent.

Simpler runtime (no user OAuth per call) but requires admin setup.

Time zones — the #1 bug

Every calendar API has time zone rules. Missteps cause user-visible bugs:

• Caller in Pacific time asks for "Thursday at 10 AM."
• Agent books in Eastern time by default.
• Caller shows up at 7 AM their time, confused.

Rules:

• Capture caller's time zone explicitly, or infer from area code + confirm.
• Pass the time zone explicitly in every API call.
• Confirm back to the caller in their time zone.
• Store the appointment in the calendar owner's time zone.
• Send notifications in the caller's time zone.

Availability-query strategy

To offer relevant slots:

1. Determine what event types / meeting types apply.
2. Determine participant calendars (solo, group, round-robin).
3. Query each calendar's free/busy.
4. Compute intersection.
5. Apply business rules (work hours, buffer, max bookings per day).
6. Return 2–3 slots to the caller.

This is more complex than a single API call — often requires multiple queries + logic.

Concurrency and locking

Two callers ask for the same slot. Without locking:

Caller A: requests 10 AM slot → succeeds.
Caller B: requests same 10 AM slot → also succeeds.
Double-booked.

Google Calendar and Outlook don't have native slot-locking — the window between read (availability) and write (book) is where races happen.

Mitigations:

• Optimistic: book, detect conflict, offer alternative.
• Pessimistic: application-level lock on slot during booking flow.
• Event idempotency keys (where supported).

Event metadata

When creating events, populate:

• Title — descriptive ("Cleaning appointment — Jamie Patel").
• Attendees — caller and provider.
• Location — physical or video link.
• Description — agent-generated summary.
• Reminders — configurable.
• Conferencing — Google Meet, Microsoft Teams, Zoom link auto-generation.

Recurring events

For recurring bookings (weekly therapy, monthly grooming):

• Use the platform's RRULE syntax.
• Handle series vs single-instance modifications.
• Consider holiday and exception dates.

Calendar-level recurrence is cleaner than creating N events.

Webhooks (Push notifications)

Google and Outlook support push notifications on calendar changes:

• Event created / updated / canceled.
• Useful for voice AI to stay in sync if humans make changes directly.

Setup involves subscription management; renewal every few days.

Booking confirmation flow

After booking:

• Calendar system sends email invite (if configured).
• Voice AI can also send SMS confirmation with details.
• Voice AI logs booking in CRM / ticketing.

Triple-confirmation (voice + email + SMS) reduces no-shows.

See sending SMS follow-ups from voice agents.

Cancellation handling

When user cancels:

• Free up the slot.
• Notify attendees.
• Log cancellation in CRM.
• Offer to reschedule during the call.

Make cancellation easy — friction here costs retention.

Common pitfalls

Time zone assumptions. Caller in Pacific time, system defaulting to UTC or Eastern. Bugs at scale.

Stale availability. Caching availability for minutes → offering slots that got taken.

Overlapping event types. Cal.com / Calendly allow multiple event types per host. Avoid overlapping by explicit querying per event type.

Permission issues. OAuth scope insufficient, or service account not delegated to target user.

Notification chaos. Multiple systems sending confirmations → user gets 4 emails and an SMS. Pick one, consolidate.

Integration architecture

Pattern:

• Voice agent → middleware → calendar API.
• Middleware handles:
  • OAuth token storage and refresh.
  • Time zone normalization.
  • Multi-calendar availability queries.
  • Caching (with short TTL).
  • Locking during booking.

Testing

• Sandbox / test calendars — Google and Microsoft provide developer accounts.
• Realistic data — multiple time zones, recurring events, conflicting calendars.
• Edge cases — DST transitions, all-day events, multi-day events.
• Error paths — auth expired, API rate limited, slot taken mid-flow.

Related reading

• Twilio + Voice Agents: A Complete Guide
• How to Integrate Voice Agents with a Custom REST API
• Sending Voice Agent Transcripts to Slack
• Connecting Voice Agents to Snowflake or BigQuery
• How to Port a Phone Number to Your Voice Agent

FAQ

Which calendar system is easiest to integrate with? Cal.com. Clean API, booking-focused, open source.

What about Zoom / Microsoft Teams meetings? Auto-create meeting links during event creation — both Google and Microsoft support this natively.

Can we handle no-show cancellations? Not directly via calendar API. Use attendance signals (Zoom join data, e.g.) to mark no-shows in CRM.

What about appointment buffers? Configured in the calendar or scheduling tool — Cal.com event types support buffers natively. For Google/Outlook, implement in availability logic.

How do we handle out-of-office / vacation blocks? They show as busy time in free/busy queries. Voice agent sees them as unavailable.