Skip to content
Plune Plune Docs

Find a case by an identifier another tool uses

GET
/v1/test-cases/resolve
 
curl --request GET \
  --url 'https://beta-api.plune.ai/v1/test-cases/resolve?value=example&kind=playwright-id' \
  --header 'Authorization: Bearer <token>'

Without kind, the value is matched across every namespace and the highest-ranking one wins; the answer says which it matched. Nothing is created when there is no match — whether a case should exist is for the client to decide (ADR 0010).

Authorizations

Section titled “Authorizations ”

Parameters

Section titled “ Parameters ”

Query Parameters

Section titled “Query Parameters ”
value
required
string
kind
string
Allowed values: playwright-id path-title allure-history cairn-stable eval-id qase testrail

Responses

Section titled “ Responses ”

200

Section titled “200 ”

The case, and the kind the value matched on

Media type application/json
object
testCase
required
One of:

A stored test case — the metadata plus the body of its type.

object
schemaVersion
required

Accepted: 1 or 2. Responses are always 2 — a v1 record is upgraded on read.

integer
Allowed values: 1 2
id
required
string format: uuid
projectId
required
string
title
required

Carries its @tag tail — the one source of tags (ADR 0032). The dashboard shows the clean title and the tags as chips.

string
state
required

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.

string
Allowed values: draft in_review active detached deprecated
status
required

Derived from state for clients on v1, never stored. in_review answers as draft and detached as active — v1 has no word for either.

string
Allowed values: draft active archived
stateReason

Why the case last moved.

string
allowedStates

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.

Array<string>
Allowed values: draft in_review active detached deprecated
stateChangedAt

When it last moved. Absent on a case that has not moved.

string format: date-time
suiteId

The suite this case is filed under, if any. Always a suite, never a folder (AC-03).

string
priority
required

Five levels in rank order — low < normal < important < high < critical. Metadata: changing it does not bump the text version.

string
Allowed values: low normal important high critical
position
required

Order among the cases of its suite (or the unfiled ones) — dense, 0-based, renumbered on every write that places a case (AC-05).

integer
tags
required

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.

Array<string>
description

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.

string
precondition

What must hold before the steps. Same rules as description.

string
externalKeys

The identifiers this case has elsewhere (D2) — attached on every read; absent when it has none.

Array<object>
<= 32 items

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
kind
required
string
Allowed values: playwright-id path-title allure-history cairn-stable eval-id qase testrail
value
required
string
<= 1024 characters
evalId

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.

string
provenance

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
source
object
kind
required
string
Allowed values: url openapi-operation requirement
value
required
string
>= 1 characters <= 100 characters
technique

The test-design technique the supplier named, as they named it.

string
<= 32 characters
createdAt
required
string format: date-time
updatedAt
required
string format: date-time
type
required
string
Allowed values: manual
steps
required
Array<object>
object
action
required
string
expected
required
string
matchedKind
required
string
Example 
{
  "testCase": {
    "schemaVersion": 1,
    "title": "Checkout — empty cart @smoke @checkout",
    "state": "draft",
    "status": "draft",
    "allowedStates": [
      "draft"
    ],
    "priority": "low",
    "tags": [
      "smoke",
      "checkout"
    ],
    "externalKeys": [
      {
        "kind": "playwright-id"
      }
    ],
    "provenance": {
      "source": {
        "kind": "url"
      }
    },
    "type": "manual"
  }
}

400

Section titled “400 ”

No value, or a kind that does not exist

Media type application/json
object
error
required
string
Example generated
{
  "error": "example"
}

404

Section titled “404 ”

No case in your project carries that key

Media type application/json
object
error
required
string
Example generated
{
  "error": "example"
}