Calendar API Integration: Real-Time Events, Free/Busy, Scheduling Links & Meeting Recordings Across Platforms

February 12, 2026

Calendar API integration connects your product to your customers' calendar, scheduling and meeting platforms (Google Calendar, Microsoft Outlook, Calendly, Zoom, Fathom and others) so it can read and write events, check free/busy, manage booking links and retrieve meeting recordings. With Unified.to's Calendar & Meetings API, one integration reaches 60 of these platforms, reading each one at request time with no customer records at rest. This guide covers what teams build with it, the problems that make calendar integrations hard (recurrence, deletions, change events), and when to build in-house instead.

For every object and field, see the Calendar & Meetings API overview. For the vendors' own APIs, see 27 Calendar APIs to Integrate With; to compare unified API platforms, see Best Unified API for Calendar and Meeting Integrations in 2026.

Meetings are created, rescheduled, canceled, converted into webinars, enriched with video links, and sometimes recorded with transcripts. Availability shifts constantly as new events are added. Recurring series split, single instances are edited, and conference links are regenerated.

When calendar data is stitched together with batch sync jobs or cached replicas, availability drifts, deleted events linger, and meeting links break.

Which platforms and objects does a calendar API integration cover?

Unified.to's Calendar & Meetings API covers six objects (calendars, events, busy times, scheduling links, recordings and webinars) across 60 calendar, scheduling, video and meeting-assistant platforms, such as:

• Google Calendar
• Microsoft Outlook / Office 365
• Apple iCloud
• Calendly
• Cal.com
• Acuity Scheduling
• Zoom (meetings & webinars)
• Google Meet
• GoTo
• Dialpad
• Fathom
• Fireflies
• and more

Unified.to reads and writes each source platform at request time and keeps no calendar records at rest; there is no replica database and no background sync job.

How do the six calendar objects behave in practice?

Each of the six objects has its own read and write support per integration, and the behaviour that trips teams up is where they differ from what the name suggests: busy is read-only, a link is not a meeting, and a webinar is not an event.

What do teams build with a calendar API integration?

Teams use calendar API integrations for in-app scheduling, availability-driven automation, meeting intelligence from recordings and transcripts, and cross-system workflows such as interview coordination and CRM meeting logging.

• In-app scheduling. Read free/busy and create the event in the user's own calendar, with a conference link, without sending users to a third-party booking tool.
• AI scheduling assistants. Let an agent read availability, propose times and create or move events through one API, or through Unified MCP tools.
• Workflow automation. Trigger follow-ups when an event is created, updated or cancelled, or when a recording becomes available, on integrations that emit those events.
• Post-meeting intelligence. Retrieve transcripts and provider summaries from Google Meet, Microsoft Teams, Webex, Fathom, Fireflies and others, and send them to summarization, extraction or search.
• Interview coordination. Combine ATS candidates and interviews with calendar availability; see interview coordination across ATS and calendar platforms.
• CRM meeting logging. Match attendees to CRM contacts by email and log the meeting against the deal or account.

Why are recurring events hard to integrate across providers?

Recurring events are hard because Google Calendar, Microsoft Graph and Zoom each model a series, its instances and single-instance edits differently, so the same "move one meeting" action takes different calls on each. Unified.to returns the series rule in recurrence and links instances to their series with recurring_event_id; pass expand=true on the event list to flatten a series into individual occurrences.

Google Calendar

• recurringEventId links instances to the series master
• originalStartTime identifies an occurrence
• Updating one instance requires patching the instance ID
• Updating 'this and following' requires splitting the series

Canceled events return minimal stubs and eventually disappear.

Microsoft Graph (Outlook)

• Series master and occurrence objects are separate
• seriesMasterId links occurrences to the master
• Deletions appear as @removed entries in delta queries
• Single-instance edits may not trigger distinct notifications

Developers must reconcile instance changes carefully.

Zoom Meetings

• Recurrence is defined at creation
• Occurrences are referenced by occurrence_id
• Deleting one occurrence requires passing occurrence_id
• Meeting IDs expire (30 days for non-recurring, 365 days for recurring)

How do you get calendar change events: native or virtual webhooks?

Unified.to delivers calendar change events two ways on supported integrations and objects: native webhooks, which forward the provider's own notifications as they arrive, and virtual webhooks, which check the provider on an interval where it has no usable push.

Which calendar integrations have native webhooks?

As of 1 October 2026, native event webhooks are listed on Google Calendar, Microsoft Outlook, Microsoft Teams, Calendly, Clio, Fathom and Webex; native recording webhooks on Calendly, Circleback, Fathom, Fellow, Grain, Modjo, tl;dv and Webex; and native webinar webhooks on Microsoft Teams and Webex. Zoom and Cal.com list no event webhooks, and busy (free/busy) has none on any integration.

What do virtual webhooks cover?

Virtual webhooks cover event changes on integrations such as Zoho Calendar, Zoom Calendar, Salesforce, Dialpad and SquareUp, and recording events on Fireflies, Granola, Google Meet and Microsoft Teams (as of 1 October 2026). They check on the interval you set (1-minute minimum on paid plans, 60 minutes on the trial), back off on the provider's retry-after hints, and bill only for pages delivered; checks that find nothing aren't billed. Virtual deleted events are reliable only on a short list of integrations, so on calendar integrations plan to detect deletions by comparing lists, or use a native webhook where the provider sends deletes.

How do calendar records link to people and other data?

Calendar records link to people through the HR & Directory employee: organizer.user_id, attendees[].user_id and a transcript speaker's user_id reference an HRIS employee, while external attendees carry only name and email. Event attachments carry an id for the File Storage file endpoint. Calendar objects carry no CRM contact IDs, so matching an attendee to a CRM contact is your application's job, usually by email.

Unified.to id values are Unified-minted; the provider's own ID is at raw.__id, which is what a passthrough call needs. The combination of connection_id and id identifies a calendar record.

How does Unified.to handle calendar and meeting data?

Unified.to keeps no calendar or meeting records at rest: events, attendees, transcripts and meeting media pass through on each request and are not stored. What it does store is connection credentials (encrypted at rest) and operational metadata in API call logs (status, timestamps, path, method, size and error description, with no request or response bodies), kept 60 days on Grow and Pro and 365 days on Scale.

• Encrypted in transit (TLS 1.2+); operational metadata encrypted at rest (AES-256)
• One region per workspace: US on every plan; EU or AU on Pro and Scale
• Admin and member roles; SAML SSO and IP restriction on Pro and Scale
• Customer-managed secrets (11 secrets managers) on Pro and Scale

Unified.to holds a SOC 2 Type II report and states GDPR, CCPA/CPRA, PIPEDA and HIPAA compliance, with a BAA on Scale. It is a subprocessor, because requests pass through it.

Should you build calendar integrations in-house or use a unified API?

Build in-house when one or two calendar providers are central to a niche product, such as a Google Calendar-only add-on; use a unified API when customers bring many calendar, scheduling and meeting tools and you would otherwise maintain each one's recurrence, webhook and auth model yourself.

• Build in-house if every customer uses the same provider, you need provider-specific features the normalized model doesn't carry and passthrough isn't enough, or calendar is the whole product.
• Use Unified.to if you need Google, Microsoft, iCloud, schedulers and meeting-assistant tools at once, want recordings and transcripts in the same model as events, or need calendar alongside ATS, CRM or HR data on one connection model.
• Cost to model. Unified.to Grow is from $750 a month for 750,000 API calls ($1.00 per 1,000 over), Pro $1,500 for 2M ($0.75), and Scale $3,000 for 6M ($0.50), with unlimited connections and a 30-day free trial on Grow and Pro. In-house cost is engineering time per provider plus maintenance as provider APIs change.

To compare unified API platforms for calendar and meetings, see Best Unified API for Calendar and Meeting Integrations in 2026.

Build Scheduling Features Without Owning Calendar Complexity

Calendar systems are deceptively complex:

• Recurring instance edits
• Conference link immutability
• Deletion semantics
• Provider-specific lifecycle states
• Recording retention policies
• Busy polling vs push updates

Unified abstracts this into:

• One event model
• One free/busy object
• One recording object
• One webhook interface

Read from the source at request time, with no customer records at rest.

If your product needs:

• Cross-platform scheduling
• Availability checks at request time
• Calendar sync
• Booking links
• Meeting recording retrieval
• Webinar creation
• Or AI-powered meeting workflows

You can build it once.

→ Start your 30-day free trial

→ Book a demo