Webhooks and Notion integration: five outgoing events, zero incoming, and the case where you should not be using a webhook

Five. The Notion developer reference lists page.created, page.content_updated, page.locked, data_source.schema_updated, and comment.created. data_source.schema_updated replaces the old database.schema_updated which is deprecated after the 2022-06-28 API version. There are also page.properties_updated and page.deleted style events documented per the event reference, but the canonical core surface that ships in the docs and that every connection can subscribe to is the five named above. If you want a literal lookup: developers.notion.com/reference/webhooks.

No. Notion has no incoming webhook. The Notion docs describe webhooks as 'real-time updates from Notion. Whenever a page or database changes, Notion sends a secure HTTP POST request to your webhook endpoint.' That is one direction only. To push data into Notion you call the REST API at api.notion.com (POST /v1/pages, PATCH /v1/pages/{id}, etc.) or you go through a third-party platform like Make, Zapier, or n8n that wraps the same REST calls behind a webhook URL they host. Do not confuse Notion's no-code 'Send webhook' button action with an incoming webhook, that one is also outgoing (a button in Notion fires a POST out to a URL you specify).

Notion batches page.content_updated events to reduce 'redundant notifications.' If a user makes ten edits to a page over a minute, you do not get ten webhook deliveries, you get one (or a small number of) aggregated event(s). The exact window is not committed in the docs. The behavioral consequence: do not rely on page.content_updated for anything time-sensitive. If you need to know that a specific block changed within a few seconds, the webhook will not get you there. You either poll the page via the REST API on a tighter cadence or switch to a side-channel signal (file save, button press, calendar event) that fires the action you actually want.

The top-level fields are id (UUID), timestamp (ISO 8601), workspace_id, workspace_name, subscription_id, integration_id, type (e.g., page.created), authors (array of {id, type: person|bot|agent}), accessible_by (array of {id, type: person|bot}), attempt_number (1 to 8 for retries), entity ({id, type: page|block|database|data_source|comment}), and data (event-specific, often empty for page.content_updated). The Notion docs are explicit: 'the webhook acts as a signal that something changed, and it is up to your connection to follow up with a call to the Notion API to retrieve the latest content.' You do not get the new content in the body, you get a poke that says 'go fetch.'

When you create a webhook subscription in your integration settings, Notion POSTs a one-time body to your URL containing a single field: verification_token (a string starting with 'secret_'). You paste that token back into the Notion form to prove your endpoint is reachable. Until you do that, the subscription is created but not active and no events flow. Localhost endpoints are not reachable, so you need a public HTTPS URL even during development. ngrok, Cloudflare Tunnel, or a deployed staging endpoint are the usual answers.

Yes, this is the 'webhook actions' feature. In a database button or database automation you can add a 'Send webhook' action that POSTs to a URL of your choice. Two limits to remember: only database page properties can be sent (not the rich-text body of the page), and there is a maximum of five webhook actions per automation. This is the no-code path that does not require building a Notion integration. Pair it with an incoming-webhook receiver on the other side and you have a one-direction trigger pipeline.

When the trigger or the action lives on your computer, not in Notion or in another cloud service. Cases: you want a Notion task to be created when you save a file in a specific folder; you want Notion to update when a meeting actually starts on your local Calendar app and not just when an event is created in the cloud; you want a row to flip status when you finish a recording in QuickTime; you want to move text from a PDF you opened in Preview into a Notion page. None of these have a sender that can fire a webhook. They all have a local Mac event. The right primitive is a desktop agent that watches the local event and operates Notion's desktop app through the macOS accessibility tree. No public URL, no verification token, no batch delay. The price is that the operation runs on your Mac, not in a cloud.

Fazm is a macOS computer-use agent. It does not replace Notion's REST API and it does not replace a third-party automation platform. It does a thing those tools cannot do: when the trigger or action is local, it acts on Notion's desktop app directly through the AXUIElement tree. Concretely, Fazm reads buttons, menus, text fields, and tables in the Notion app the same way macOS VoiceOver does, by accessibility label and role. So 'when I save a file matching pattern X, append a row to my Notion ops database' is a single Fazm flow, no webhook, no integration token, no public URL. For everything else (Slack to Notion, Stripe to Notion, GitHub issue to Notion page) you keep using webhooks plus the REST API or a Make/Zapier scenario, and the answer in this guide stays the same.

If both ends are cloud services, you do not need to host anything. The shortest path is a Make or Zapier or n8n scenario with a 'Notion: page in database created/updated' trigger and a 'Slack: send message' action. Notion sends the outgoing webhook (or the platform polls), the platform translates, the platform calls Slack's API. If you want more control or you are passing PII you would rather not park inside a SaaS, run an n8n instance you host yourself, point Notion's webhook at it, write the Slack call as an HTTP node. If you are a developer and you want zero abstraction, register a webhook subscription in your Notion integration, run a small Node or Go service behind Cloudflare Tunnel, verify with the verification_token, post to Slack's incoming webhook in your handler.