Skip to content
Plune Plune Docs

Decide one verdict over an explicit list of queue items

POST
/v1/review-items/decisions
 
curl --request POST \
  --url https://beta-api.plune.ai/v1/review-items/decisions \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{ "itemIds": [ "4f1a7f6e-0000-4000-8000-000000000001" ], "state": "approved" }'

Applies one verdict to every item in a list. Each item is applied on its own: an approved proposal creates its test case, a disputed result only changes state, and each application is audited separately. Items that cannot change are left untouched and named in the report with a reason, so repeating the decision over just those is the normal way to finish a batch rather than an error path. Partial application is a SUCCESS — the batch is not a transaction, and one stale item does not undo nineteen sound decisions. A test case is still born only from an approval; the batch is a cheaper way to say the same thing, never a second way in.

Authorizations

Section titled “Authorizations ”

Request Body required

Section titled “Request Body required ”
Media type application/json

One verdict for an explicit list. The list is never implicit: there is no “decide everything pending”, because a decision nobody enumerated is a decision nobody made.

object
itemIds
required

A repeated id is applied once and named in the report.

Array<string>
>= 1 items <= 200 items
state
required

One verdict for the whole list; there is no per-item verdict. pending is not a verdict — it is where an item starts.

string
Allowed values: approved rejected
rejectionCategory
string
Allowed values: duplicate incorrect out-of-scope low-value not-testable other
note

Required together with the category when state is rejected — the same rule a single-item rejection obeys, checked in the same place. The reason belongs to the DECISION, so every rejected item carries the same one.

string
>= 10 characters <= 2000 characters
Examples

Approve a list of proposals

{
  "itemIds": [
    "4f1a7f6e-0000-4000-8000-000000000001"
  ],
  "state": "approved"
}

Responses

Section titled “ Responses ”

200

Section titled “200 ”

The decision was read and applied. Read the report, not only the status: applied may be smaller than the list that was sent.

Media type application/json
object
applied
required

How many items changed state.

integer
casesCreated
required

How many test cases were born from those approvals. NOT the same number as applied: a disputed result changes state without creating a case.

integer
skipped
required
Array<object>
object
id
required
string format: uuid
reason
required

Stable codes rather than prose, because a caller loops over them to repeat the decision over just these items. not_found answers both an item of another project and an id that was never issued — indistinguishable on purpose, so a list cannot become a way to learn what another project holds.

string
Allowed values: not_found already_in_state invalid_transition
duplicates
required

Ids the list named more than once. Each was applied once, and counted once.

Array<string>
Example 
{
  "skipped": [
    {
      "reason": "not_found"
    }
  ]
}

400

Section titled “400 ”

Nothing was applied. Either the list is missing or exceeds the ceiling on items per request, or the request carries no single verdict for the whole list, or it rejects without naming a category and an explanation — the last being the same rule a single-item rejection enforces, checked in the same place.

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

401

Section titled “401 ”

No / invalid token or session

429

Section titled “429 ”

Rate-limited: either the per-route throttle or a tenant quota. Retry-After carries the seconds until the window rolls over.

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

Headers

Section titled “Headers ”
Retry-After
integer

Seconds until the window rolls over