An API that connects multiple Microsoft services, enabling data access and automation across platforms
Update the attendee list on the organizer’s event instance; an attendee’s mailbox contains its own meeting copy, and changing recipients must be performed by the meeting owner or organizer.
The screenshot confirms the observed result: the request sends [Email], receives 200 OK, but the returned attendee remains [Email].
What the 200 response means
isOrganizer: false means the calendar owner is not the event organizer.^1^ Outlook’s documented workflow permits the meeting owner to change attendees; a non-owner forwards the meeting request instead of editing its recipient list.^2^
The Graph Update event API documents attendees as updatable and returns 200 OK with the resulting event after a successful request.^3^ However, that reference does not explicitly document that PATCHing attendees on a non-organizer copy is guaranteed to return 200 as a no-op.
Therefore:
- Your result is consistent with attempting to modify the attendee’s local meeting copy.
- The returned original address shows that the requested recipient change was not persisted.
- Do not treat
200 OKalone as proof that every submitted property changed; compare the returned resource or perform a subsequent GET. - The exact silent no-op behavior should be treated as observed behavior, not a documented API contract.
Supported update pattern
- Read the event and check
isOrganizer. - If it is
false, do not PATCH itsattendees. - Obtain the corresponding event from the organizer’s calendar.
- GET that organizer event and preserve its intended attendee collection.
- Replace the old recipient entry with the new recipient in that collection.
- PATCH the organizer’s event using the updated collection.
- Verify the response and, if needed, GET the organizer event again.
Changes intended to propagate to attendees must be made to the organizer’s meeting instance.^4^
Example organizer-side request:
PATCH https://graph.microsoft.com/v1.0/users/{organizer-id}/events/{organizer-event-id}
Authorization: Bearer {token}
Content-Type: application/json
{
"attendees": [
{ "type": "required",
"emailAddress": {
"address": "[Email]",
"name": "Attendee name"
}
}
]
}
The example is abbreviated. Do not submit only this one entry if the meeting has other attendees. First GET the organizer event, modify the relevant entry, and submit the intended attendee list. Model an address correction as removing/replacing the old recipient and adding the new recipient—not as editing identity data on the attendee’s local copy. An attendees-only organizer update sends meeting updates only to attendees whose membership changed.^3^
The token requires Calendars.ReadWrite for user events.^3^
Locating the organizer event
The event ID from the attendee’s mailbox should not be assumed to be the organizer’s event ID. The cited Graph documentation does not provide a direct attendee-event-ID-to-organizer-event-ID conversion operation.
The most reliable application design is to retain the organizer mailbox and organizer-side event ID when creating or initially discovering the meeting. If that mapping was not retained, the organizer event must be located separately in the organizer’s calendar and validated before updating it. Do not PATCH a guessed match.
If the application cannot access the organizer’s calendar, it cannot perform this attendee-list correction through that organizer instance. Have the organizer update the meeting, obtain the required organizer-calendar authorization, or open a Microsoft support case if the silent 200 behavior itself needs confirmation as a service issue.
References