agenthub · notion.write
Update a Notion page or database row's properties. The deterministic write counterpart to the Notion read node.
Why the node earns its place
The typical use is a status sync: a milestone is reached, so advance a row's Stage. Same per-caller connection as reading, same rule that no secret sits on the canvas.
Because the write sets a named field to a value, a repeat converges on the same state — which is what makes it safe for a run that resumes and executes it twice.
How it works at run time
property to one value, or a whole properties map, which wins when both are given.What you wire
Configuration
| Key | Type | Default & options | What it does |
|---|---|---|---|
| connection * | string | default "notion" | The connection to write through (auth_layer tool_id). Resolved per-caller at run time. Never a secret. |
| page_id | string | — | The page / database-row id to update — the `id` notion.read returns for each row. Overridable via the `page_id` input so an upstream node (e.g. a fan-out row) can drive it. |
| property | string | — | Single property name to set, e.g. 'Stage'. Use with `value`. For multi-property updates use the `properties` map instead. |
| value | string | — | Value for `property`. Supports {{context_key}} interpolation. For a select, just the option name (e.g. 'account_created'); a number, the bare number; a checkbox, '__YES__' / '__NO__'. |
| properties | object | — | Advanced: a full {name: value} map (wins over property/value). Date props split into 'date:<prop>:start' etc.; checkbox uses '__YES__'/'__NO__'; relations take an array of page ids/URLs. |
What usually goes wrong
Watch for this
Property values are typed by Notion, and the encoding is particular: a select takes the bare option name, a number the bare number, a checkbox __YES__ or __NO__, a relation an array of ids, and a date splits across date:<prop>:start. A value in the wrong encoding fails at Notion, not on the canvas.
Behaviour & provenance