I’ve successfully configured Google Calendar to send push notifications to my system whenever a new event is created. However, the challenge I’m facing is that the notification doesn’t include any data in the POST body. Here are the relevant headers I receive with the notification:
Despite following the correct setup, I always receive the same resource ID for every new event created, which makes it impossible to determine the individual event that triggered the notification. What’s the correct method for obtaining the event ID of the newly created event?
Your webhook notification is working fine - Google doesn’t send event data in the POST body on purpose (performance and security reasons). You need to use that notification as a trigger to pull the actual changes through the API.
When your webhook gets hit, immediately call the events.list API method on the calendar that changed. Use the updatedMin parameter and set it to your last sync time. You’ll get back only the events modified since then.
About the resource ID issue - that X-Goog-Resource-ID header is for the calendar itself, not individual events. It stays the same because you’re watching the whole calendar for changes.
I’d recommend setting up a simple local database table to track the last modification time for each event. When you process the updated events from your API call, compare them against your stored timestamps to see what actually changed. This catches cases where users edit multiple events at once or modify older events you might miss otherwise.
Yeah, this caught me off guard too when I first set up calendar webhooks. The notification is just a “hey, something happened” ping with no event details.
You need to make a separate API call when you get that webhook. I use the events.list endpoint with updatedMin set to just before you started watching.
Here’s what tripped me up for weeks - don’t just grab the newest event and assume that triggered the webhook. Multiple events can change at once, or someone might’ve edited an old event.
Learned this the hard way when our system kept missing updates because we only looked at the most recent event. Turns out users were editing events from last week and we completely ignored those changes.
Now I fetch all events modified since my last successful sync and process the entire batch. Store your last sync timestamp locally, then when the webhook hits, query everything updated since that point.
One more gotcha - set your updatedMin to maybe 30 seconds before your actual last sync time. I’ve seen the webhook arrive before the event fully propagates through Google’s systems, so you might miss it if your timing’s too tight.
Google Calendar push notifications don’t include event data in the payload for security reasons. You’re just getting a ‘something changed’ signal. That X-Goog-Resource-ID is the calendar’s resource ID, not an individual event ID - that’s why it stays the same. To get the actual event details, you’ll need to call the events.list endpoint with updatedMin set to your last sync timestamp. Store when you last synced successfully, then when a notification comes in, query for events modified since that time. I ran into this same issue and found that keeping a local sync token works way better than timestamps. Use the syncToken parameter in your events.list calls - Google sends back a sync token with each response that you can use next time to only grab changes since your last sync. This handles rapid updates and edge cases much better than the timestamp approach.