Notion package v1.0.0

A Notion connection (integration) token for the customer's workspace, held in the client's own secret manager. The retrieved documentation names three bearer-token kinds — an installation access token from an internal connection, an OAuth access token from a public connection, and a personal access token; this pack registers the internal-connection token, issued in Notion's developer portal when a workspace admin creates the connection. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'.

The token's reach is limited to the pages and data sources a workspace member has explicitly shared with the connection, and to the capabilities (read, update, insert content) chosen at creation — choose the minimum: the retrieved delete-block and patch-page documentation both state the call fails with 403 unless the connection holds update content capabilities, so a read-mostly deployment should withhold update capability and accept that the write capabilities in this pack will fail closed.

Lifecycle: the retrieved authorization guide describes the internal-connection installation access token as static — the connection sends the same token in every API request — and does not document token expiry, nor whether regenerating or disabling a connection invalidates already-issued tokens; that documentation gap stands after retrieval of the authorization guide on 2026-09-21, so the deployment must confirm revocation behaviour in the developer portal before enabling and must treat disabling issuance as not necessarily invalidating already-issued tokens until confirmed; a revoked or rejected value fails closed.

Rotation ownership: the external deployment process that creates the connection in the developer portal also owns ongoing rotation and replacement of the stored value — AAES creates nothing and the injector performs no token lifecycle; name the owning team in the deployment's custody configuration before enabling.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'notion-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the real Notion API host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the reviewed documentation names the base URL as https://api.notion.com with the /v1 path prefix. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. PAGE_ID, BLOCK_ID and DATA_SOURCE_ID in the endpoint paths are placeholders the deployment binds before enabling.

Notion-Version pinning: the reviewed documentation requires a Notion-Version request header on every call, and the operation and authorization pages retrieved on 2026-09-21 show '2026-03-11' as the current documented version — that is the version this pack's registered contracts (search, page create and update, data source query, block delete) were reviewed against, so the deployment must send 'Notion-Version: 2026-03-11' on every call; adopting any newer version is a re-review trigger, not a configuration detail.

The registered endpoint fixes the URL; the pinned version header completes the reviewed contract.

Documented exclusions: this pack does not register public sharing of a page to the web ('Share to web' / publish).

Sharing a page publicly is a share effect — disclosed information cannot be made private again once the other party has it — so it would register as share at the minimum R3 tier, but no publish or page-sharing endpoint page could be retrieved during the documented review (publish-page and update-page-settings returned 404, and the retrieved PATCH page documentation shows public_url only as a response field): rather than guess an endpoint, this pack registers no sharing operation at all.

Further documented exclusions: user and bot management, comments, file uploads, data source schema updates (updating a data source alters the schema of a whole database, an extensive change needing its own review), block content append and update, and the OAuth token exchange for public connections.

Approval classification: notion.page.update registers update and delete at R3 because the reviewed documentation shows the same request body can set in_trash (trashing the page) and erase_content, which the documentation states deletes all of the page's block children and 'cannot be reversed using the API' — an unrestricted request body defeats a lower tier, and intended limits need a separate enforceable control; a deployment needing property-only updates at R2 must remove this capability rather than rely on caller intent.