Read one of your test cases
const url = 'https://beta-api.plune.ai/v1/test-cases/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://beta-api.plune.ai/v1/test-cases/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0 \ --header 'Authorization: Bearer <token>'The case page (api.ts → getTestCase): the stored record with its state, tags and keys, plus allowedStates — the moves the lifecycle matrix lets THIS caller make from here (a token and a session get different lists, D22), so the screen offers exactly those and never copies the matrix. A deleted case answers 404 like a foreign one.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”Responses
Section titled “ Responses ”The test case
A stored test case — the metadata plus the body of its type.
object
Accepted: 1 or 2. Responses are always 2 — a v1 record is upgraded on read.
Carries its @tag tail — the one source of tags (ADR 0032). The dashboard shows the clean title and the tags as chips.
The case’s place in its lifecycle. in_review is a case a proposal produced and nobody has confirmed yet; detached is one whose source stopped being reported. Who may move it where depends on whether the caller is a session or a token.
Derived from state for clients on v1, never stored. in_review answers as draft and detached as active — v1 has no word for either.
Why the case last moved.
Only when reading ONE case: the states the caller may move it to from here, per the lifecycle table and who the caller is - a session is a person, a bearer token is automation. A screen renders exactly these as actions and never lists moves itself. The current state is not included.
When it last moved. Absent on a case that has not moved.
The suite this case is filed under, if any. Always a suite, never a folder (AC-03).
Five levels in rank order — low < normal < important < high < critical. Metadata: changing it does not bump the text version.
Order among the cases of its suite (or the unfiled ones) — dense, 0-based, renumbered on every write that places a case (AC-05).
Read from the title by the server, each once, in first-seen order. Derived: sent back, never taken on the way in as a field of its own — tags on a write rewrites the title.
Free text beside the steps. Part of what a result was produced against, so a change bumps the text version (AC-09). Absent when never set. 16 384 bytes of UTF-8 at most.
What must hold before the steps. Same rules as description.
The parameters table (D7). Content like the two texts: a change bumps the version.
object
The identifiers this case has elsewhere (D2) — attached on every read; absent when it has none.
An identifier another tool already uses for this test, so a report can find its case without anyone typing a Plune id. The order of kind is load-bearing: it is the ranking that decides which key wins when several match different cases.
object
The id of this case’s eval in plune.yaml. An ingested run attaches its results to the case carrying the same id (ADR 0010); absent for cases the CLI does not run.
Only when reading ONE case: the source text of the one test() call an automated case references — the call itself, header and body, exactly as written in the file. Absent on a case that has never had one; present-and-unchanged when the file most recently failed to parse (the last known snapshot, not empty). 16 384 bytes of UTF-8 at most, the same ceiling description/precondition already carry.
SHA-256 hex digest of codeSnapshot, recomputed by the server on every write that touches it (ADR-0005) — never accepted from a client. Present whenever codeSnapshot is, and on the list too even though the text itself is not: a re-importer hashes its own freshly parsed text the same way and compares against this to decide changed vs unchanged without a second request per case.
Who wrote it (B8-team T3): the userId of the caller of POST /v1/test-cases or of a duplicate. Set by the server, never taken from a body, never changed by a PATCH. Absent on a case from before names were kept and on one the review queue created. Resolve it through GET /v1/members.
Who is to run it (B8-team T4): the userId of a member of the project. Set by PATCH {assigneeId} or the bulk assign action, never on create; null on a PATCH takes it away; leaving the project takes it away too. Absent means unassigned. GET /v1/test-cases?assignee=me|none|<userId> filters on it.
Where the case came from, present only on one an approved proposal created (B-1). Read through that proposal rather than stored on the case, so it answers for every case ever created this way and can never disagree with the queue entry beside it. Absent on a case a person wrote — and absent, too, when the proposal named neither field: both mean nothing was reported.
object
object
The test-design technique the supplier named, as they named it.
Where a field’s text came from, once it was accepted from an AI draft (automated-case-description-draft, AC-17): per field, the model, the date of the draft, who asked, who accepted and when, and — if a person edited the text afterwards — who and when. A field has an entry only while its text is the one a draft produced: the next accepted draft replaces it and clearing the field drops it. The key is absent when no field was ever accepted from a draft. Written only by the case store’s single write path — never taken from a client body, on a PATCH or on Markdown import alike.
object
One field’s provenance (AC-17). The same facts the dashboard shows under the field; the hash the server compares the code against is never part of it.
object
The model that drafted this text, as recorded on the call at the time — not the project’s current model: a later change must not relabel old text.
When the draft that produced this text was requested — “the date of the draft”.
userId of the member who asked for the draft — resolve through GET /v1/members like TestCaseMeta.createdBy.
userId of the member who accepted it into the case.
Present when a person edited this field after accepting it (AC-17); absent otherwise.
When editedBy last edited it. Present exactly when editedBy is.
Whether the case’s code snapshot changed, beyond whitespace, since this text was drafted (AC-16, AC-04b) — read again every time the case is read, not frozen when the text was accepted.
One field’s provenance (AC-17). The same facts the dashboard shows under the field; the hash the server compares the code against is never part of it.
object
The model that drafted this text, as recorded on the call at the time — not the project’s current model: a later change must not relabel old text.
When the draft that produced this text was requested — “the date of the draft”.
userId of the member who asked for the draft — resolve through GET /v1/members like TestCaseMeta.createdBy.
userId of the member who accepted it into the case.
Present when a person edited this field after accepting it (AC-17); absent otherwise.
When editedBy last edited it. Present exactly when editedBy is.
Whether the case’s code snapshot changed, beyond whitespace, since this text was drafted (AC-16, AC-04b) — read again every time the case is read, not frozen when the text was accepted.
object
A stored test case — the metadata plus the body of its type.
object
Accepted: 1 or 2. Responses are always 2 — a v1 record is upgraded on read.
Carries its @tag tail — the one source of tags (ADR 0032). The dashboard shows the clean title and the tags as chips.
The case’s place in its lifecycle. in_review is a case a proposal produced and nobody has confirmed yet; detached is one whose source stopped being reported. Who may move it where depends on whether the caller is a session or a token.
Derived from state for clients on v1, never stored. in_review answers as draft and detached as active — v1 has no word for either.
Why the case last moved.
Only when reading ONE case: the states the caller may move it to from here, per the lifecycle table and who the caller is - a session is a person, a bearer token is automation. A screen renders exactly these as actions and never lists moves itself. The current state is not included.
When it last moved. Absent on a case that has not moved.
The suite this case is filed under, if any. Always a suite, never a folder (AC-03).
Five levels in rank order — low < normal < important < high < critical. Metadata: changing it does not bump the text version.
Order among the cases of its suite (or the unfiled ones) — dense, 0-based, renumbered on every write that places a case (AC-05).
Read from the title by the server, each once, in first-seen order. Derived: sent back, never taken on the way in as a field of its own — tags on a write rewrites the title.
Free text beside the steps. Part of what a result was produced against, so a change bumps the text version (AC-09). Absent when never set. 16 384 bytes of UTF-8 at most.
What must hold before the steps. Same rules as description.
The parameters table (D7). Content like the two texts: a change bumps the version.
object
The identifiers this case has elsewhere (D2) — attached on every read; absent when it has none.
An identifier another tool already uses for this test, so a report can find its case without anyone typing a Plune id. The order of kind is load-bearing: it is the ranking that decides which key wins when several match different cases.
object
The id of this case’s eval in plune.yaml. An ingested run attaches its results to the case carrying the same id (ADR 0010); absent for cases the CLI does not run.
Only when reading ONE case: the source text of the one test() call an automated case references — the call itself, header and body, exactly as written in the file. Absent on a case that has never had one; present-and-unchanged when the file most recently failed to parse (the last known snapshot, not empty). 16 384 bytes of UTF-8 at most, the same ceiling description/precondition already carry.
SHA-256 hex digest of codeSnapshot, recomputed by the server on every write that touches it (ADR-0005) — never accepted from a client. Present whenever codeSnapshot is, and on the list too even though the text itself is not: a re-importer hashes its own freshly parsed text the same way and compares against this to decide changed vs unchanged without a second request per case.
Who wrote it (B8-team T3): the userId of the caller of POST /v1/test-cases or of a duplicate. Set by the server, never taken from a body, never changed by a PATCH. Absent on a case from before names were kept and on one the review queue created. Resolve it through GET /v1/members.
Who is to run it (B8-team T4): the userId of a member of the project. Set by PATCH {assigneeId} or the bulk assign action, never on create; null on a PATCH takes it away; leaving the project takes it away too. Absent means unassigned. GET /v1/test-cases?assignee=me|none|<userId> filters on it.
Where the case came from, present only on one an approved proposal created (B-1). Read through that proposal rather than stored on the case, so it answers for every case ever created this way and can never disagree with the queue entry beside it. Absent on a case a person wrote — and absent, too, when the proposal named neither field: both mean nothing was reported.
object
object
The test-design technique the supplier named, as they named it.
Where a field’s text came from, once it was accepted from an AI draft (automated-case-description-draft, AC-17): per field, the model, the date of the draft, who asked, who accepted and when, and — if a person edited the text afterwards — who and when. A field has an entry only while its text is the one a draft produced: the next accepted draft replaces it and clearing the field drops it. The key is absent when no field was ever accepted from a draft. Written only by the case store’s single write path — never taken from a client body, on a PATCH or on Markdown import alike.
object
One field’s provenance (AC-17). The same facts the dashboard shows under the field; the hash the server compares the code against is never part of it.
object
The model that drafted this text, as recorded on the call at the time — not the project’s current model: a later change must not relabel old text.
When the draft that produced this text was requested — “the date of the draft”.
userId of the member who asked for the draft — resolve through GET /v1/members like TestCaseMeta.createdBy.
userId of the member who accepted it into the case.
Present when a person edited this field after accepting it (AC-17); absent otherwise.
When editedBy last edited it. Present exactly when editedBy is.
Whether the case’s code snapshot changed, beyond whitespace, since this text was drafted (AC-16, AC-04b) — read again every time the case is read, not frozen when the text was accepted.
One field’s provenance (AC-17). The same facts the dashboard shows under the field; the hash the server compares the code against is never part of it.
object
The model that drafted this text, as recorded on the call at the time — not the project’s current model: a later change must not relabel old text.
When the draft that produced this text was requested — “the date of the draft”.
userId of the member who asked for the draft — resolve through GET /v1/members like TestCaseMeta.createdBy.
userId of the member who accepted it into the case.
Present when a person edited this field after accepting it (AC-17); absent otherwise.
When editedBy last edited it. Present exactly when editedBy is.
Whether the case’s code snapshot changed, beyond whitespace, since this text was drafted (AC-16, AC-04b) — read again every time the case is read, not frozen when the text was accepted.
A stored test case — the metadata plus the body of its type.
object
Accepted: 1 or 2. Responses are always 2 — a v1 record is upgraded on read.
Carries its @tag tail — the one source of tags (ADR 0032). The dashboard shows the clean title and the tags as chips.
The case’s place in its lifecycle. in_review is a case a proposal produced and nobody has confirmed yet; detached is one whose source stopped being reported. Who may move it where depends on whether the caller is a session or a token.
Derived from state for clients on v1, never stored. in_review answers as draft and detached as active — v1 has no word for either.
Why the case last moved.
Only when reading ONE case: the states the caller may move it to from here, per the lifecycle table and who the caller is - a session is a person, a bearer token is automation. A screen renders exactly these as actions and never lists moves itself. The current state is not included.
When it last moved. Absent on a case that has not moved.
The suite this case is filed under, if any. Always a suite, never a folder (AC-03).
Five levels in rank order — low < normal < important < high < critical. Metadata: changing it does not bump the text version.
Order among the cases of its suite (or the unfiled ones) — dense, 0-based, renumbered on every write that places a case (AC-05).
Read from the title by the server, each once, in first-seen order. Derived: sent back, never taken on the way in as a field of its own — tags on a write rewrites the title.
Free text beside the steps. Part of what a result was produced against, so a change bumps the text version (AC-09). Absent when never set. 16 384 bytes of UTF-8 at most.
What must hold before the steps. Same rules as description.
The parameters table (D7). Content like the two texts: a change bumps the version.
object
The identifiers this case has elsewhere (D2) — attached on every read; absent when it has none.
An identifier another tool already uses for this test, so a report can find its case without anyone typing a Plune id. The order of kind is load-bearing: it is the ranking that decides which key wins when several match different cases.
object
The id of this case’s eval in plune.yaml. An ingested run attaches its results to the case carrying the same id (ADR 0010); absent for cases the CLI does not run.
Only when reading ONE case: the source text of the one test() call an automated case references — the call itself, header and body, exactly as written in the file. Absent on a case that has never had one; present-and-unchanged when the file most recently failed to parse (the last known snapshot, not empty). 16 384 bytes of UTF-8 at most, the same ceiling description/precondition already carry.
SHA-256 hex digest of codeSnapshot, recomputed by the server on every write that touches it (ADR-0005) — never accepted from a client. Present whenever codeSnapshot is, and on the list too even though the text itself is not: a re-importer hashes its own freshly parsed text the same way and compares against this to decide changed vs unchanged without a second request per case.
Who wrote it (B8-team T3): the userId of the caller of POST /v1/test-cases or of a duplicate. Set by the server, never taken from a body, never changed by a PATCH. Absent on a case from before names were kept and on one the review queue created. Resolve it through GET /v1/members.
Who is to run it (B8-team T4): the userId of a member of the project. Set by PATCH {assigneeId} or the bulk assign action, never on create; null on a PATCH takes it away; leaving the project takes it away too. Absent means unassigned. GET /v1/test-cases?assignee=me|none|<userId> filters on it.
Where the case came from, present only on one an approved proposal created (B-1). Read through that proposal rather than stored on the case, so it answers for every case ever created this way and can never disagree with the queue entry beside it. Absent on a case a person wrote — and absent, too, when the proposal named neither field: both mean nothing was reported.
object
object
The test-design technique the supplier named, as they named it.
Where a field’s text came from, once it was accepted from an AI draft (automated-case-description-draft, AC-17): per field, the model, the date of the draft, who asked, who accepted and when, and — if a person edited the text afterwards — who and when. A field has an entry only while its text is the one a draft produced: the next accepted draft replaces it and clearing the field drops it. The key is absent when no field was ever accepted from a draft. Written only by the case store’s single write path — never taken from a client body, on a PATCH or on Markdown import alike.
object
One field’s provenance (AC-17). The same facts the dashboard shows under the field; the hash the server compares the code against is never part of it.
object
The model that drafted this text, as recorded on the call at the time — not the project’s current model: a later change must not relabel old text.
When the draft that produced this text was requested — “the date of the draft”.
userId of the member who asked for the draft — resolve through GET /v1/members like TestCaseMeta.createdBy.
userId of the member who accepted it into the case.
Present when a person edited this field after accepting it (AC-17); absent otherwise.
When editedBy last edited it. Present exactly when editedBy is.
Whether the case’s code snapshot changed, beyond whitespace, since this text was drafted (AC-16, AC-04b) — read again every time the case is read, not frozen when the text was accepted.
One field’s provenance (AC-17). The same facts the dashboard shows under the field; the hash the server compares the code against is never part of it.
object
The model that drafted this text, as recorded on the call at the time — not the project’s current model: a later change must not relabel old text.
When the draft that produced this text was requested — “the date of the draft”.
userId of the member who asked for the draft — resolve through GET /v1/members like TestCaseMeta.createdBy.
userId of the member who accepted it into the case.
Present when a person edited this field after accepting it (AC-17); absent otherwise.
When editedBy last edited it. Present exactly when editedBy is.
Whether the case’s code snapshot changed, beyond whitespace, since this text was drafted (AC-16, AC-04b) — read again every time the case is read, not frozen when the text was accepted.
Stored with the case and returned unchanged. It links to nothing: golden sets were removed in ADR 0013, so this is a label the platform keeps, not a reference it resolves.
One assertion: a type plus whatever that type needs (ADR 0012). The remaining fields depend on type (e.g. values for contains-all, criteria for llm-judge).
object
Example
{ "schemaVersion": 2, "id": "6f1c2b3a-0000-4000-8000-0000000000c1", "type": "automated", "specRef": "e2e/checkout.spec.ts#empty-cart", "projectId": "u-shop::default", "title": "Checkout — empty cart @smoke @checkout", "state": "draft", "suiteId": "6f1c2b3a-0000-4000-8000-0000000000a1", "description": "An empty cart must not reach the payment step.", "priority": "high", "position": 0, "createdBy": "u-shop", "createdAt": "2026-09-16T09:12:04.151Z", "updatedAt": "2026-09-16T09:12:04.151Z", "externalKeys": [ { "kind": "path-title", "value": "e2e/checkout.spec.ts > Checkout — empty cart" } ], "status": "draft", "tags": [ "smoke", "checkout" ], "allowedStates": [ "in_review", "active" ]}No / invalid token or session
Not found or not yours
object
Example generated
{ "error": "example"}