Outlook.com changes an event's change key seconds after creating it
Updated
TL;DR
On Outlook.com, a newly created event's changeKey moved 0.5 to 2.5 seconds after the create, with nothing else about the event changed, in 6 creates out of 6 on October 26, 2026. An update or delete that sends the change key the create returned, to guard against overwriting someone's edit, is refused as a conflict. Compare the event's content instead of the change key, and re-read once before giving up.
What we saw
Microsoft Graph gives every event a changeKey, which changes whenever the event changes. Sending it back with an update is the usual way to make sure you don't overwrite an edit someone made in Outlook since you read the event.
Observed on Outlook.com, 2026-10-26
We created events through Graph and read them back a few seconds later. The change key had moved on every one: 6 creates out of 6, between 0.5 and 2.5 seconds after the create, with no other field changed.
An update sent with the change key from the create's response was refused as a conflict, although nobody had touched the event.
Something on Outlook.com's side touches every new event shortly after it is created. Nothing in the event's content changes, only the stamp.
Why it matters
If your app creates an event and then lets a person edit it, the first edit fails. The usual reaction is to retry without the check, which removes the protection the change key was there for. On a calendar people share, that means silently overwriting their changes.
What to do
- Compare content, not the stamp. Keep a digest of the event fields you care about (title, times, attendees, description, location and so on), leaving out stamps such as
changeKeyandlastModifiedDateTime. Treat the event as changed only when the digest differs. - Re-read before writing. When you hold a version, read the event, compare its digest with yours, and send the update with the change key you just read. A real change made in between is still refused; a change key that moved on its own is not.
- Retry a few times on a fresh read when Graph still answers with a conflict and the content has not changed.
How Pyas handles it
An Outlook event's version in Pyas is a digest of the event as Pyas returns it, without Outlook's stamps, so it changes when the event does and not when only the change key does. When you send If-Match with that version, Pyas checks it against a fresh read, then writes with the change key it just read; if Outlook moved the key on its own in between, the write is tried again on a fresh read, up to three times. A write without a version sends no change key at all.