Capability Library · Pack detail

notion v1.0.0

Notion API on the customer's workspace: search and query pages and data sources read-only, create pages, update pages (including trash and content-erasing flags), and trash blocks.

Review state: draft· Not in the distributable release manifest

Release identity

SHA-256 of the pack file bytes: 958f43936c33473f62d277720af3b1d30dbde08a842f2ed8b05b7c1091813857

Not in the distributable release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.

Capabilities (5)

notion.search v1.0.0R0

Action
read
Endpoint
POST https://notion-api.invalid/v1/search
Connector
http
Custody
customer_vault
Credential ref
secret-ref-notion-integration-token
Data class
internal

Search pages and data sources shared with the connection: a POST-with-query-body endpoint registered read-only at the read floor. Body shape: an optional query string, a filter object selecting object type (page or data_source), a sort direction, and the documented pagination fields start_cursor and page_size. The operation reference page (POST /v1/search) was retrieved on 2026-09-21 and confirms this path and request-body contract.

notion.data_source.query v1.0.0R0

Action
read
Endpoint
POST https://notion-api.invalid/v1/data_sources/DATA_SOURCE_ID/query
Connector
http
Custody
customer_vault
Credential ref
secret-ref-notion-integration-token
Data class
pii

Query one data source: a POST-with-query-body endpoint registered read-only at the read floor; the operation reference page (query a data source) was retrieved on 2026-09-21 and confirms this exact path and the complete request contract. Body shape: filter and sort clauses (including compound and/or filter groups) plus the documented pagination fields start_cursor and page_size, with the filter_properties query parameter narrowing returned schema properties. Data source rows frequently describe people (contacts, employees, customers), so the read is registered at the pii class; declare internal only after the owner classifies the base. DATA_SOURCE_ID is a placeholder the deployment binds before enabling.

notion.page.create v1.0.0R2

Action
create
Endpoint
POST https://notion-api.invalid/v1/pages
Connector
http
Custody
customer_vault
Credential ref
secret-ref-notion-integration-token
Data class
internal

Create one page under a parent page or data source; a created page can later be trashed, so create sits at the R2 floor for reversible writes. The registration does not restrict the body, so the caller chooses the parent and properties; the operation reference page (POST /v1/pages) was retrieved on 2026-09-21 and confirms the path and that the body carries parent, properties, optional children and an optional template — a selected template is applied asynchronously by Notion after the API request finishes, and the integration must hold Insert Content capabilities on the parent or the call fails with 403.

notion.page.update v1.0.0R3

Actions
update, delete
Endpoint
PATCH https://notion-api.invalid/v1/pages/PAGE_ID
Connector
http
Custody
customer_vault
Credential ref
secret-ref-notion-integration-token
Data class
internal

Update one page. The retrieved documentation shows the request body can update properties, icon, cover and lock state, but can ALSO set in_trash:true (trashing the page) and erase_content:true — which the documentation states deletes all of the page's block children and 'cannot be reversed using the API'. The registration does not restrict the request body, so the capability's worst-case effect is irreversible content erasure: it declares update and delete at the R3 floor — delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) and cannot be taken without a person. A deployment needing property-only updates at R2 must remove this capability and register a body-restricted surface elsewhere; an installer's intention is not a restriction. The connection must hold update content capabilities on the page or the call fails with 403. PAGE_ID is a placeholder the deployment binds before enabling.

notion.block.delete v1.0.0R3

Action
delete
Endpoint
DELETE https://notion-api.invalid/v1/blocks/BLOCK_ID
Connector
http
Custody
customer_vault
Credential ref
secret-ref-notion-integration-token
Data class
internal

Trash one block, including page blocks: the retrieved documentation states the call sets the block to in_trash:true and that it can be restored via the update APIs. Restore availability does not lower the floor: delete is one of the IRREVERSIBLE ACTIONS and registers at R3. The connection must hold update content capabilities on the block or the call fails with 403. BLOCK_ID is a placeholder the deployment binds before enabling.

Credential reference

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference
secret-ref-notion-integration-token
Custody
customer_vault
Injection
header (Authorization)

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.

Resources

  • notion-workspace (site, pii): https://notion-api.invalid/v1

Pack notes and exclusions

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 retrieved 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 retrieved 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 — a share cannot be un-seen once the other party has it — so it would register as share at the R3 floor, but no publish or page-sharing endpoint page could be retrieved this session (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, a high-blast-radius change needing its own review), block content append and update, and the OAuth token exchange for public connections. Tiering rationale: notion.page.update registers update AND delete at R3 because the retrieved 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 an installer's intention is not a restriction; a deployment needing property-only updates at R2 must remove this capability rather than rely on caller intent.

Review record

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.