When you receive an event webhook from Nylas, a natural question is: who created this event? The answer depends on the calendar provider, because Google, Microsoft, and iCloud each model event ownership differently — and Nylas normalizes them into a common schema with two fields: organizer and creator.
These behaviors are provider-side logic and not Nylas-specific transformations
This guide explains exactly what those fields mean for each provider, when they diverge, and how to write reliable cross-provider logic.
organizer - The person the event is for — whose calendar "owns" it. For meetings, this is the person who sent the invite.
creator - The person who actually created the event. Usually the same as the organizer, but it differs in delegation and shared calendar scenarios.
Provider-by-Provider Behavior
Microsoft (Graph API)
What you get: organizer only. creator is always null.
Microsoft Graph returns an organizer field on events, and Nylas maps it directly:
{
"organizer": { "name": "Alice Chen", "email": "alice@company.com" },
"creator": null
} Key nuances:
organizer.emailis the person the meeting is organized for, not necessarily who pressed "Create."- Microsoft Graph does have an
isOrganizerboolean that indicates whether the synced user is the organizer of the event. Nylas does not currently expose this field.
Bottom line: For Microsoft, organizer.email is your only option and is reliable for the vast majority of cases.
Google (Calendar API)
What you get: Both organizer and creator, and they often differ.
Google Calendar has the richest ownership model. Both fields are populated:
{
"organizer": { "name": "Alice Chen", "email": "alice@company.com" },
"creator": { "name": "Alice Chen", "email": "alice@company.com" }
}Scenario 1: Shared / Group Calendars
When someone creates an event on a shared Google calendar, organizer becomes the calendar itself (not a person), while creator remains the human:
{
"organizer": {
"name": "Engineering Team",
"email": "c_abc123...@group.calendar.google.com"
},
"creator": {
"name": "Alice Chen",
"email": "alice@company.com"
}
}Scenario 2: External Invites (Cross-Provider)
When a Microsoft user invites a Google user, Google "re-parents" the event. On the Google user's calendar:
creator.email= the Google user (mailbox owner) — Google claims them as the "creator" of this copyorganizer.email= the original Microsoft organizer who sent the invite
{
"organizer": { "name": "External Person", "email": "someone@outlook.com" },
"creator": { "name": "Local User", "email": "localuser@gmail.com" }
}Scenario 3: Delegation
When an assistant creates an event on behalf of an executive on the executive's primary calendar:
creator.email= the assistantorganizer.email= the executive
{
"organizer": { "name": "CEO", "email": "ceo@company.com" },
"creator": { "name": "Executive Assistant", "email": "assistant@company.com" }
}Bottom line: Google gives you the most information. Use organizer.email as the default, but fall back to creator.email when the organizer is a shared calendar address.
iCloud (CalDAV)
What you get: Both fields, but with different sourcing than you might expect. Either or both can be absent.
iCloud uses CalDAV, where the ORGANIZER property maps to Nylas creator (not organizer), and the attendee with ROLE=CHAIR maps to Nylas organizer. If no CHAIR attendee exists, organizer falls back to creator. For personal events without participants, both fields are null — use the grant's email as fallback.
| CalDAV Source | Nylas Field |
|---|---|
ORGANIZER property | creator |
Attendee with ROLE=CHAIR | organizer |
| No CHAIR attendee | organizer falls back to creator |
| No attendees + no ORGANIZER | Both null → use grant email |
Bottom line: Check organizer first, then creator, then fall back to the grant email.
Updated
Comments
0 comments
Please sign in to leave a comment.