1. Overview
The Notion integration uses an internal integration secret to read pages, data sources, comments, and nested content explicitly shared with the integration.
Creating the integration does not expose the whole Notion workspace. A workspace owner must add the integration to the pages or data sources Seedling should read, and child access follows Notion's sharing behavior.
2. Connection and scope
Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.
- Internal integration
- A Notion workspace owner creates an internal integration, enables the required read capabilities, and copies its internal integration secret.
- Personal or workspace connection
- The Notion bot or connection identity is verified before storage. Resource access remains limited to pages and data sources shared with that integration.
3. Notion data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Pages and blocks
- Page identity, properties, rich text, nested blocks, parent relationships, authorship, and update context.
- Data sources
- Data-source schemas, properties, rows represented as pages, and their parent relationships.
- Comments and users
- Comments and user information without email addresses for attribution when available to the integration.
4. Read-only permission contract
The internal integration should enable only the capabilities used by Seedling.
- read_content — read pages, data sources, properties, and nested blocks shared with the integration.
- read_comments — read comments on authorized Notion content.
- read_user_information_without_email — read names and profile identity for attribution without requesting user email addresses.
- Seedling does not require insert_content, update_content, or user email access.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
- Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
- Sharing a Notion parent may expose its children to the integration under Notion's native rules. Seedling never treats an unshared neighboring page or workspace membership as authorization.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized Notion records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored Notion credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.