Public API: endpoint to create a project (POST /api/projects)

[antonyramirez-at-m42]

Is your feature request related to a problem? Please describe.

There is no API endpoint to create a project, so projects cannot be provisioned from automation. We run integration tests in 20+ service repositories and want one project per repository, which is the layout that keeps each service's tests and metrics separate. Today every one of those projects has to be created by hand in the UI before CI can report, and each new service we scaffold needs the same manual step before its pipeline works.

What is available today, on a self-hosted instance (43.0.1) and per the Public API reference:

• GET /api/projects — documented, list only
• GET /api/project/{id} — documented, read only
• 32 documented POST endpoints, all scoped inside an existing project (/api/{project_id}/…: suites, tests, labels, runs, plans, …)
• POST /api/projects returns 404 (no route), as do POST /api/companies/{slug}/projects and PUT /api/projects/{slug}
• the Importing API (/api/load, /api/test_data) and the Reporting API (/api/reporter) both require a project that already exists; reporting with an unknown project key returns 403 "Project API Token is invalid"

Interestingly DELETE /api/projects/{slug} does work, though it is not in the reference — so project-level management verbs partially exist already; only create is missing.

The only creation paths we can find are session-authenticated (POST /projects in the app, POST /admin/projects in the admin panel), which means they cannot be driven with an API token from CI.

Describe the solution you'd like

POST /api/projects, authenticated with a general API token, accepting at least:

• title
• the owning company (e.g. company / company_id), so the project lands in the right company rather than as a personal project
• optionally default_branch, labels/templates to copy from an existing project

and returning the created project including its api-key, so a pipeline can create the project and immediately report into it.

Ideally with create-or-get semantics — if a project with that slug already exists in the company, return it instead of erroring. That lets CI call the endpoint unconditionally and stay idempotent, which is what makes "add a repository, run the pipeline" work without a human step.

Describe alternatives you've considered

1. One shared project, one run group per repository. This works and we ran it, but it does not scale for reporting: with a few services reporting, the Tests view is a single flat list of several hundred tests with no indication of which service a suite came from, and the Runs graph consolidates every service into one series. Run groups separate the runs but not the tests or the metrics, which is what we need per service.
2. Creating the projects manually. Fine once, but it puts a manual step in front of every new service, and the step is easy to forget — the pipeline then silently reports nothing.
3. Scripting the session-based admin route. Technically possible, but it is unsupported, depends on form/CSRF internals that may change, and requires putting admin credentials into automation — a much broader credential than the API token we otherwise use.
4. A general token exchanged for the project token at report time. We do this already and it works well (one organization secret serves every repository), but it only resolves projects that exist — it cannot create the missing one.

Additional context

Our pipeline already resolves the project by slug from the repository name and exchanges a general token for that project's token at report time, so the only missing piece is creation. With POST /api/projects available we could provision on first run and drop the manual step entirely.

This would also help anyone doing monorepo-to-many-services or scaffolder-driven repository creation, where projects need to appear as repositories do. Happy to test against a self-hosted build if that helps.

[TetianaKhomenko]

@AenEnlil development notes:

1. this shall be available on Enterprise only
2. the endpoint shall be available to Owner only
3. RBAC compatible