Summary
Notion's 2025 API added a new views resource that lets integrations read and manipulate the saved views on a database (list, board, timeline, calendar, ...). Until now views were Notion-UI-only. The new endpoints:
GET /v1/views
POST /v1/views
GET /v1/views/:id
PATCH /v1/views/:id
DELETE /v1/views/:id
POST /v1/views/:id/query
GET /v1/views/:id/query_results
DELETE /v1/views/:id/query
No CLI surface for any of this yet.
When this matters
- Users who want to script a specific UI view (e.g. "query the 'Active Projects' view the team already uses") instead of reconstructing the filter + sort from scratch.
- Exporting / backing up the view layout of a complex database.
Open questions before building
- Is there actual demand? Views are a less common automation target than databases/pages; may be safe to defer until someone files a concrete request.
- The
views/:id/query async pattern (create query → poll results → delete query) is different from the synchronous /databases/:id/query. The CLI will want a high-level wrapper that hides the polling.
Priority
Low. Parked here as a placeholder so the coverage gap is tracked; do not start work until there's a user asking for it.
Summary
Notion's 2025 API added a new
viewsresource that lets integrations read and manipulate the saved views on a database (list, board, timeline, calendar, ...). Until now views were Notion-UI-only. The new endpoints:No CLI surface for any of this yet.
When this matters
Open questions before building
views/:id/queryasync pattern (create query → poll results → delete query) is different from the synchronous/databases/:id/query. The CLI will want a high-level wrapper that hides the polling.Priority
Low. Parked here as a placeholder so the coverage gap is tracked; do not start work until there's a user asking for it.