[feature]: Expose workspace-integrations and GitHub repo-project mapping on REST API v1

[jeremylongshore]

Is there an existing issue for this?

• I have searched the existing issues

Summary

The REST API (/api/v1/) currently does not expose any endpoints for managing integrations at the workspace or project level. In particular, once a workspace admin installs the GitHub App and authorizes the Plane GitHub integration, there is no public API way to:

• list connected workspace integrations
• map a GitHub repository to a specific Plane project
• list or remove those repo↔project mappings

All of this exists in the internal API that the web client calls (e.g. workspace-integrations, github-repository-sync), but none of it is accessible with a workspace API token. That forces every project-level repo mapping to be done by hand in the web UI.

Proposed endpoints, following existing v1 conventions:

• GET /api/v1/workspaces/{slug}/workspace-integrations/
• GET /api/v1/workspaces/{slug}/workspace-integrations/{id}/
• GET /api/v1/workspaces/{slug}/projects/{project_id}/github-repository-sync/
• POST /api/v1/workspaces/{slug}/projects/{project_id}/github-repository-sync/
• DELETE /api/v1/workspaces/{slug}/projects/{project_id}/github-repository-sync/{id}/

Auth via the standard workspace API key (admin-scoped for write).

Why should this be worked on?

1. Infrastructure-as-code. Teams that manage Plane alongside other tooling (Terraform / Pulumi / shell scripts) cannot fully bootstrap a workspace today — projects, issues, modules, labels, and cycles are all scriptable, but the moment you want GitHub sync wired up for every project, someone has to click through the UI.

2. Consistency with existing gaps being filled. There is a clear pattern of the public v1 API trailing the internal API, and the community has filed feature requests as each gap blocks them:

   • Public API support for creating and managing Views #8816 Public API support for creating and managing Views
   • [feature]: Add project member management (POST/PATCH/DELETE) to REST API v1 #8631 Add project member management to REST API v1
   • [feature]: Add API Endpoints for Creating and Editing Pages #7319 Add API endpoints for creating and editing Pages
   • [feature]: Expose an openapi definition of the API #8636 Expose an OpenAPI definition of the API

   Integration management is the same shape of gap.

3. Self-hosted automation. On self-hosted Community edition this is the only GitHub-sync mechanism available, and it is currently strictly click-ops.

4. Low surface area. The internal viewsets already exist; this is primarily wiring them to the v1 URL namespace with API-key auth and a serializer review — not net-new business logic.

Happy to implement

If a maintainer tags this as accepted, I'm willing to open the PR (monorepo backend, apps/api).

---

Jeremy made me do it
-claude