List request inputs (paginated)

List request inputs together with their current status and workflow progress. requestId scopes the listing to one request; requestInputIds (repeated: ?requestInputIds=a&requestInputIds=b) names the inputs to return, spanning several requests when no requestId is given; sceneId narrows to one scene.

Validation: give requestId, requestInputIds, or both; neither returns 400, as does more than 5000 requestInputIds. Only requests on flexible workflows are supported: a legacy-workflow request returns 400. A requestId that does not exist, or — when listing by requestInputIds alone — any entry that does not exist, returns 404. An entry removed from its request is accepted and left out of the results, so a removal part-way through does not break the walk.

Access: the caller must be a collaborator (owner, producer or reviewer) with a workspace role in the project on every request involved, otherwise 403. With requestInputIds spanning several requests this is all or nothing: one input in a request the caller cannot read fails the whole call with 403, rather than omitting that input.

Paging: results are cursor-paginated and returned in a stable order. Pass metadata.nextCursorId from a page as the next request's cursorId, together with the same requestId or requestInputIds; the last page has no nextCursorId. Inputs come back ordered by request and then by scene, whichever way they were asked for. A page can hold fewer than limit inputs, or none at all, and still carry a nextCursorId: an input that has not entered the workflow yet takes a place without reporting progress. Walk until nextCursorId is absent rather than until a page comes back empty. A limit above 5000, and a cursorId that is not one of the listed inputs, both return 400.

Per-input field availability:

• status is not_started until work begins on the input, completed while it has a valid (non-invalidated) delivery annotation, and in_progress otherwise. A re-correction invalidates the delivery annotation, so an input can go back from completed to in_progress.
• progressDetails is populated only when the caller has access to the input's current phase/action. A producer sees every phase; a reviewer sees only the phases and actions granted to them, so an input currently sitting in a phase they cannot see returns progressDetails as null.
• progressDetails.currentTask is null when no task is ongoing (for example the last task completed and the input is awaiting a decision).
• progressDetails.currentWorkflowStage splits into phase, action and a combined name (for example "Review 1: Correct"). phase.id identifies one phase of this request, while phase.phaseDefinition.id identifies the kind of phase (for example annotate, correct, sampled-review) and is the same for every request and project using that phase type, so it can be used to group inputs across requests. action is absent when the input is between actions — for example waiting for a decision after the phase's last task completed.
• progressDetails.availableForIntegrationReview is true only for an input sitting in an integration review phase and awaiting a verdict, that is, one an integration review can be posted for right now. It turns false once the verdict is in, while a rejected input is being corrected, and for every input outside such a phase.
• lastCompletedAnnotationId is the judgement produced by the input's most recently completed assignment. It is null until at least one task has completed and is not access-gated.
• createdAt, lastUpdatedAt and completedAt are never access-gated. createdAt is when the input was added to the request; lastUpdatedAt is its last workflow state change (entering a phase, a task being created, or completing a phase — not edits inside an ongoing task); completedAt holds the production time of the input's current valid delivery annotation and is null whenever status is not completed.