Projects

A project is the box everything lives in: cases, suites, runs, plans, settings, the Steps Database, the bin. Every record belongs to exactly one, and every request acts in exactly one. What you may see is decided by membership — you read a case because you are a member of its project — the model Testomat.io’s projects use, without the company layer above them: there is no organisation, only projects and the people in them.

Every account has a default project, provisioned the first time the account is seen. Until you make or are invited to another, it is where everything goes, and nothing about the API changes for you — every request without a project named lands there.

Naming the project

X-Plune-Project: <id>

Every scoped route reads this header. Absent, the request acts in your default project. The ids come from one place:

GET /v1/projects   → 200

{
  "projects": [
    { "id": "u-shop::default", "name": "Checkout", "role": "owner", "createdAt": "…" },
    { "id": "9c4e7d10-…", "name": "Mobile app", "role": "member", "createdAt": "…" }
  ]
}

Oldest first, with your role in each. /v1/projects is the one surface that stands outside a project — it takes no header, because it is how a client learns which ids it may put there.

A project you are not in answers 404

X-Plune-Project with the id of a project you are not a member of answers 404 with the same body an invented id gets — project '<id>' not found. Existence is never confirmed to somebody outside it, the same rule every record follows.

Making one

POST  /v1/projects        { "name": "Mobile app" }   → 201  you are its owner
PATCH /v1/projects/{id}   { "name": "Checkout" }     → 200  an owner of THAT project

A new project is empty: settings, tags and the Steps Database are per project and start blank. The name is 1 to 100 characters; a member who tries to rename is told project owner only (403), a stranger gets the 404 above. Your default project is born named default — rename it on Settings → General once, and the switcher, the invitation mail and the token list say the name from then on.

The switcher

The dashboard shows the project it stands in at the left of the top bar, on every screen: the name and a chevron. Open it to see every project you are in, the current one checked, and New project… — a name, and the browser moves into the new project as its owner.

The choice is remembered by the browser. When nothing is remembered yet — a first visit, a new browser — the dashboard stands in the first project it lists: for somebody invited before they ever signed in, that is the team’s project, not their own empty default. Switching starts over on the runs list.

Removed from a project?

A browser that remembers a project the account is no longer in meets the 404 above on its first request, forgets the choice and starts over in the first project it still lists. Nothing to clear by hand.

Tokens and projects

A CLI token is bound to the project it was minted in. Mint it on Settings → General while standing in the project CI should write to, and every request that carries it lands there — whatever X-Plune-Project a client sends, the header is ignored under a bearer token. The token list says which project each one writes to; a token from before projects existed writes to your default project.

Two products, two projects, two tokens: the CI of each writes to its own, and neither can be pointed at the other by a header.

A reader cannot mint a token

Minting is a write, and a reader is refused every write in a project (see Members). So CLI read access for a read-only member is not a thing yet: a reader looks at reports in the dashboard, and an owner or member holds the tokens.

Where the records say it

Every record carries a projectId, and the audit feed is per project — GET /v1/audit lists what changed in the project the request stands in. Membership changes are recorded there too, as updates of the project entity: who was added, invited, promoted, removed, and by whom.