Feature Request: Full API support for database subitems (create, read, update, delete)

[JaimeExternalia]

Summary

Notion's UI supports subitems in databases (subtasks / hierarchical items), but the REST API does not expose a first-class way to create, read, update, or delete them. This is a significant gap for developers building automation, integrations, or data pipelines on top of Notion.

---

Current behaviour

When subitems are enabled on a database, Notion automatically creates two relation properties:

• Sub-item – a relation pointing to child pages in the same database
• Parent item – a relation pointing to the parent page

These relation properties can be read via GET /pages/{page_id} and partially written via PATCH /pages/{page_id} (by updating the relation array). However:

1. There is no API endpoint to enable or configure subitems on a database programmatically.
2. There is no dedicated type for subitem relations in the TypeScript types — they appear as generic RelationPropertyItemObjectResponse, making it impossible to distinguish them from user-defined relations in a type-safe way.
3. The dependency / blocking relationships (also part of the subitems feature in the UI) are completely absent from the API.
4. Querying a database filtered by parent/child hierarchy (e.g., "give me all root-level items" or "give me all children of item X") requires fetching all pages and manually filtering by the relation property — there is no native filter for this.
5. The rollup property on subitems (e.g., rolled-up status, dates) is read-only and not writable via API.

---

Expected behaviour

• A way to enable subitems on a database via PATCH /databases/{database_id} (or equivalent).
• Dedicated TypeScript types that identify subitem relation properties (e.g., a is_subitem: true flag or a distinct property type).
• Filter support for querying subitems by parent/child relationship natively in POST /databases/{database_id}/query.
• CRUD support for the dependency/blocking relationships between items.

---

Use case / motivation

Teams that manage project work in Notion rely on subitems to break epics into tasks and tasks into subtasks. Any automation that needs to mirror this hierarchy (e.g., syncing with Jira, Linear, GitHub Issues, or custom reporting tools) is currently blocked because there is no reliable, type-safe way to:

• Create a subitem programmatically and attach it to a parent
• Query all children of a given item without fetching the entire database
• Know, from the API response alone, that a given relation property is the system-managed subitem relation vs. a user-defined one

This limitation makes Notion's database hierarchy a dead end for API-driven workflows.

---

Workaround (current, fragile)

// Identify subitem relation by name convention (brittle, breaks if user renames the property)
const subItemRelation = page.properties["Sub-item"];
if (subItemRelation?.type === "relation") {
  // treat as subitem — but there's no guarantee this is the system property
}

---

References

• Notion Help – Tasks and dependencies: https://www.notion.com/help/tasks-and-dependencies
• Notion API – Database properties reference: https://developers.notion.com/reference/database
• Notion API – Page properties: https://developers.notion.com/reference/page-property-values

[swotvibe]

yes< yes < yes