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

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:

   • #8816 Public API support for creating and managing Views
   • #8631 Add project member management to REST API v1
   • #7319 Add API endpoints for creating and editing Pages
   • #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

Start in the monorepo backend under apps/api and compare the existing internal workspace-integrations and github-repository-sync viewsets with current REST API v1 conventions. Review the proposed workspace integration and repository-mapping routes, serializers, and standard workspace API-key authorization. Done means the listed GET, POST, and DELETE endpoints expose these mappings with admin-scoped writes.