[feature]: Add API Endpoints for Creating and Editing Pages

[nkai777]

Is there an existing issue for this?

• I have searched the existing issues

Summary

Currently, the Plane API provides comprehensive endpoints for managing core resources like Issues, Projects, and Cycles. However, there appears to be no documented API support for programmatically creating or editing Pages. All page management must be done manually through the web interface. This limitation makes it difficult to automate documentation workflows, migrate knowledge bases from other systems, or build custom internal tools that interact with Plane's Pages feature.

Why should this be worked on?

I would like to request the addition of new API endpoints to allow for full CRUD (Create, Read, Update, Delete) operations on Pages. Specifically, the most critical additions would be:

Create a new Page:

An endpoint to create a new page within a specific project.

Method: POST

Endpoint: /api/v1/workspaces/{workspace_slug}/projects/{project_id}/pages/

Body: A JSON payload containing the page name and description (in the required rich text format).

Update an existing Page:

An endpoint to edit the name or content of an existing page.

Method: PATCH

Endpoint: /api/v1/workspaces/{workspace_slug}/projects/{project_id}/pages/{page_id}/

Body: A JSON payload with the fields to be updated.

Describe alternatives you've considered
The only current alternative is to create and edit all pages manually through the UI. This is not scalable for bulk operations, such as migrating documentation from a different platform, or for any form of automated content creation.

Additional context
Adding API support for Pages would unlock significant potential for automation and integration. It would allow teams to:

Build scripts to automatically generate meeting notes or project reports as Plane Pages.

Migrate existing knowledge bases from tools like Confluence or Notion into Plane.

Develop custom integrations that link external systems directly to Plane's documentation features.

This would make Pages a much more powerful and integral part of the Plane ecosystem for technical teams. Thank you for considering this feature.

[ma-gamp]

Is this feature request already implemented? According to the API doc there is already an API for creating a page: https://developers.plane.so/api-reference/introduction . But if i try to call /api/v1/workspaces/{workspace_slug}/projects/{project_id}/pages/ on my self hosted instance i get a 404.

[marinosabijan]

We need this ASAP for real-world automation use.

We just tried to build unattended Plane sync for a company docs/design-system corpus, and pages were the obvious target at first. In practice, we hit a hard wall on the supported API-key/public surface:

• page create: works
• page retrieve by known ID: works
• page list: we could not find a supported public/API-key route
• page update: not available on the api/v1 surface we tested
• page delete: not available on the api/v1 surface we tested
• page archive: we could not find a supported public/API-key route for this either

What we saw concretely:

• GET /api/v1/workspaces/{workspace}/projects/{project}/pages/{page_id}/ worked
• PATCH on that page route returned method-not-allowed on our setup
• DELETE on that page route returned method-not-allowed on our setup
• listing project pages was not exposed in the public docs/API surface we could use

That forced us to abandon pages entirely for automation and switch to work items as the mutable sync target, even though pages would be the much better product surface for docs.

The missing piece is not just create/retrieve. To make pages usable for automation, we really need full public/API-key support for:

1. list project pages
2. update project pages
3. delete or archive project pages
4. ideally update page description/content independently as well

Without that, teams doing repo -> Plane doc sync, release notes sync, or any docs-like automation have to choose between:

• unsupported browser/session hacks
• manual UI cleanup
• or using work items as a docs substitute

We intentionally chose work items because they support stable API-key GET/PATCH/DELETE, but that is clearly a workaround, not the intended docs experience.

If helpful, I can share the exact request/response behavior we observed on the API-key v1 routes.