Skip to content

How to create Google calendar events

Creating events on Google Calendar through the native API means dealing with Google’s restricted scope requirements right away. Unlike reading events, which only needs a sensitive scope, write access requires the calendar scope, classified as restricted, and that triggers a full third-party security assessment before your app can go to production. On top of that, Google has its own conferencing auto-creation behavior, event type restrictions, and color ID system that you’ll need to account for.

Nylas gives you a single Events API that handles event creation across Google, Microsoft, iCloud, and Exchange. This guide walks through creating events on Google Calendar accounts and covers the Google-specific behavior you should know about.

Why use Nylas instead of the Google Calendar API directly?

Section titled “Why use Nylas instead of the Google Calendar API directly?”

Writing to Google Calendar introduces more friction than most developers expect:

  • Restricted scope required for writes - Reading events uses the sensitive calendar.events.readonly scope, but creating events requires the restricted calendar scope. That means a third-party security assessment before you can launch.
  • Google Meet auto-creation - Google’s conferencing auto-attach behavior is provider-specific. Setting it up through the native API requires understanding conferenceData and createRequest fields that don’t exist on other providers.
  • Event type restrictions - You can’t create focusTime, outOfOffice, or workingLocation events through any API. These are managed exclusively through the Google Calendar UI.
  • Provider-specific fields - Color IDs, room resources, and event visibility settings all work differently on Google than on Microsoft or iCloud.

If Google Calendar is your only target and you want full control over every Google-specific field, the native API works. But if you need multi-provider support or want to avoid the security assessment process, Nylas is the faster path to production.

You’ll need:

New to Nylas? Start with the quickstart guide to set up your app and connect a test account before continuing here.

Creating events requires the calendar scope, which Google classifies as restricted. This is a step up from what you need to just read events:

Scope tierExampleWhat’s required
Non-sensitivecalendar.readonly (metadata only)No verification needed
Sensitivecalendar.events.readonlyOAuth consent screen verification
Restrictedcalendar.events, calendarFull security assessment by a third-party auditor

The calendar.events scope is enough for creating and modifying events, but most apps use the broader calendar scope to also manage calendars. Both are restricted and require a security assessment before production use.

Nylas handles token refresh and scope management, but your GCP project still needs the correct scopes configured. See the Google provider guide for the full setup.

Make a Create Event request with the grant ID and a calendar_id query parameter. You can use primary to target the user’s default calendar.

You’re about to send a real event invite! The code samples below send an email from the connected account to any email addresses in the participants field. Make sure you actually want to invite those addresses before running this.

Nylas returns the created event with an id you can use for subsequent updates or deletions. The same code works for Microsoft, iCloud, and Exchange accounts with no provider-specific changes.

The notify_participants query parameter controls whether Google sends email invitations to people listed in the participants array. It defaults to true, so participants receive calendar invitations automatically unless you explicitly disable it.

curl --request POST \
--url "https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/events?calendar_id=primary&notify_participants=true" \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <NYLAS_API_KEY>' \
--header 'Content-Type: application/json' \
--data '{
"title": "Project sync",
"when": {
"start_time": 1700000000,
"end_time": 1700003600
},
"participants": [
{ "email": "[email protected]" }
]
}'

When notify_participants=false, Google creates the event on the organizer’s calendar only. Participants don’t receive an email invitation or an ICS file, and the event does not appear on their calendars.

A few provider-specific details that matter when creating events on Google Calendar and Google Workspace accounts.

This is the biggest difference from reading events. Any operation that creates, updates, or deletes events needs the calendar or calendar.events scope, both of which are restricted. Google requires a third-party security assessment before your app can request these scopes in production. During development, you can use the scopes with test users, but plan for the assessment timeline (it can take several weeks) before launching.

See the security assessment guide for details on what the process involves.

You can automatically generate a Google Meet link when creating an event by including conferencing.autocreate in your request body:

{
"conferencing": {
"provider": "Google Meet",
"autocreate": {}
}
}

No extra OAuth scopes are needed for Google Meet auto-creation since conferencing is considered part of the event. You can also manually attach a Meet, Zoom, or Microsoft Teams link by passing the conferencing.details object instead. See the conferencing guide for all the options.

Google Calendar supports special event types like focusTime, outOfOffice, and workingLocation, but you can’t create these through any API. They’re managed exclusively through the Google Calendar UI. The Events API only creates default type events. If your app needs to display these special types, you can read them from existing calendars, but you can’t programmatically create them.

Google supports numeric color IDs for event-level color overrides. Pass a string value from "1" through "11" in the event’s color_id field to set the color. These map to Google Calendar’s fixed color palette. Other providers handle event colors differently or not at all, so don’t rely on this field if you’re building for multiple providers.

To create an all-day event, use the datespan format in the when object instead of start_time/end_time. The end date is exclusive, meaning it should be the day after the last day of the event:

{
"when": {
"start_date": "2025-06-15",
"end_date": "2025-06-16"
}
}

A two-day event on June 15-16 would have end_date set to "2025-06-17". This matches the iCalendar spec and Google’s own behavior, but it catches people off guard.

Google Workspace accounts support booking meeting rooms by including room resource email addresses in the resources field. Rooms must belong to the user’s Google Workspace organization. Personal Google accounts don’t have access to room resources.

{
"resources": [
{
"email": "[email protected]"
}
]
}

You can create recurring events by including an recurrence array with RRULE strings. Google keeps existing overrides when you modify a recurrence pattern, which is different from Microsoft where overrides get removed on pattern changes. For all the details on creating and managing recurring events, see the recurring events guide.

Google enforces calendar API quotas at two levels:

  • Per-user: Each authenticated user has per-minute and daily limits for API calls
  • Per-project: Your GCP project has an overall daily limit across all users

Write operations are more heavily rate-limited than reads. If your app creates events for many users, you’ll hit project quotas faster than you might expect. Use webhooks instead of polling to track event changes, and consider setting up Google Pub/Sub for real-time sync with lower latency.