I’m working on a side project that uses Notion’s API. I saw they have webhooks that can send notifications when stuff happens in your workspace. I want to use this to get alerts when pages in my database are added or removed.
The problem is I can’t figure out what exactly gets sent in these webhook events. Notion’s docs show some sample payloads but it’s hard to understand what’s actually included. My main question is whether the webhook event contains all the page details like titles and custom fields, or if it only sends basic info like the page ID.
I’m specifically curious about the page.created event. Does it include all the page properties I’ve set up in my database, or does it just give me minimal data like the parent database ID? I can’t test this myself right now because I’d need to deploy an endpoint to receive the webhooks and my project isn’t ready for deployment yet.
Has anyone actually worked with Notion webhooks before? It would be really helpful to know what kind of data structure to expect when these events fire.
Yeah, Notion webhooks are pretty bare-bones. I’ve built a content management system with them and the page.created event only gives you the basics - page ID, parent database, timestamp, and event type. That’s it. No page title, no custom properties, nothing useful really. You’ll need to make a second API call with that page ID to get the actual content and properties. It’s annoying but makes sense performance-wise. Here’s what I’d do: grab the webhook notification, then immediately hit the Pages API to pull the full page data. Pro tip - cache your database schema ahead of time so you know what properties to expect. Makes validation and processing way smoother.
Notion’s bare bones webhook payloads are such a pain. You’re constantly writing the same fetch logic to grab actual page data after every webhook ping.
Hit this exact problem on a project syncing Notion database changes with our team dashboard. Instead of building all that webhook handling and API logic from scratch, I used Latenode.
You can create a workflow that catches the Notion webhook, automatically makes the follow-up API call for all page properties, then does whatever you need with that data. No deployment headaches or endpoint management.
Built one that listens for page.created events, grabs custom fields from our project database, and pushes data to Slack and our internal tools. Takes 10 minutes versus hours of coding.
Way better than handling webhook parsing and API orchestration manually. You can test directly in the platform too - no ngrok or local servers.
I built a project tracker with Notion webhooks and the payload structure is frustratingly minimal. When page.created fires, you get the page object but most fields are null or empty. The webhook just confirms something happened and gives you an ID.
What caught me off guard - even basic stuff like the page title isn’t included. You literally get the page ID, some parent database metadata, and timestamps. That’s why everyone makes those follow-up API calls.
Learned this the hard way: batch your API requests if you’re expecting multiple webhook events quickly. Notion’s rate limits will bite you if you make individual calls for every webhook ping. The webhook structure hasn’t changed much this past year, so the minimal payload approach seems intentional.
honestly, the webhook limitation makes sense from notion’s side, but it’s super frustrating. just finished implementing this for a client tracker and yep - webhook gives you basically nothing useful. page id and that’s it. had to write a whole separate function to immediately fetch the actual page data whenever a webhook hits. i get why they do it performance-wise, but man it doubles the work.
Everyone hits the same wall with Notion’s weak webhook payloads. I wasted tons of time building this exact flow before finding a better way.
Webhook → API call → data processing gets old. You’re stuck dealing with rate limits, errors, and messy plumbing code.
I use Latenode now. Set up a webhook receiver that handles Notion API calls automatically. When page.created fires, it catches the webhook, grabs all your page properties at once, and routes the data wherever you want.
No more fetch logic or API orchestration headaches. The workflow does everything - catches webhooks, grabs custom fields, sends alerts. Much cleaner than rolling your own.
You can test everything right in the platform. No ngrok or deployment needed to see your data.
I’ve worked with Notion webhooks in a CMS before. The page.created event payload is pretty bare-bones - you’ll get the page ID, parent database ID, and timestamps, but that’s about it. No actual page properties or content in the webhook itself.
Here’s what happens: the webhook tells you something changed and gives you the page ID, but you’ll need a separate API call to grab the full page details and custom database fields. Notion does this on purpose to keep webhook payloads light and let you decide what extra data to pull.
I’d set up a local webhook receiver with ngrok for testing. You can see exactly what the payload looks like without deploying anything. Just remember you’ll need those follow-up API calls to get the actual page data you want.
yeah, notion webhooks are kinda annoying. they only send basic metadata - just the page id, creation date, and mod time. no actual page content. you’ll need a separate api call to grab properties and other data. i think they do this to keep payloads light, but it’s more work for us. def use ngrok for testing like the other person said - makes it easier to see what’s coming through.