Review Batch
Apply one approve or reject decision to many review records with POST /v1/review/batch: per-item outcomes, partial-failure reporting, overwrite semantics.
POST /v1/review/batch applies one review decision (approve or reject) to many review items in a single API call. This is the fastest way to clear backlogs when you have high-confidence items that can be bulk-approved, or when rejecting a batch of items from a failed extraction run. The single action applies to every id — mixed verdicts take two calls with the corresponding id lists.
Validation is all-or-nothing, execution is per-item. The request is rejected as a whole with a 400 when ids is empty or contains anything that is not a well-formed UUID — no record is touched in that case. Once the shape is valid, each id is processed independently: records that exist are updated, and ids that match nothing produce an error entry without aborting the rest. processed and failed summarize the split, and results carries the per-id outcome in your input order.
An id fails with not_found in three indistinguishable cases: the record does not exist, it belongs to another workspace, or its source document is hidden from your API key's minting user by source-visibility rules. Hidden records are never mutated. Ids that resolve are actioned regardless of their current status — a batch approve overwrites an earlier rejection, and re-batching already-approved ids is a harmless no-op that still counts toward processed.
The batch write is narrower than the single-item action: it sets status and reviewed_at on each record but carries no reason, so review_comment is untouched and reviewed_by stays null. When individual audit comments matter — typically for rejections — loop over [POST /v1/review/:id/action](review-action) with a per-record reason instead. Items are processed sequentially on the server, so very large batches extend request latency roughly linearly; batches of 50–100 ids keep round-trips comfortable.
results array for per-item outcomes rather than treating the HTTP 200 as all-approved./v1/review/batchBody parameters
curl
curl -s -X POST https://api.talonic.com/v1/review/batch \
-H "Authorization: Bearer tlnc_your_api_key" \
-H "Content-Type: application/json" \
-d '{
"ids": [
"a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"b2c3d4e5-f6a7-8901-bcde-f12345678901",
"c3d4e5f6-a7b8-9012-cdef-123456789012"
],
"action": "approve"
}'Response
Response fields
Response (partial failure)
{
"processed": 2,
"failed": 1,
"results": [
{ "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "status": "approved" },
{ "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901", "status": "approved" },
{ "id": "c3d4e5f6-a7b8-9012-cdef-123456789012", "status": "error", "error": "not_found" }
]
}Errors
Error responses
A common pattern is to first call GET /v1/review?status=pending to collect IDs, filter client-side by overall_confidence above a safe threshold, then batch-approve those IDs here. Retries are safe: re-sending the same batch re-applies the same terminal statuses, so a timed-out call can be repeated without corrupting state — only reviewed_at moves forward.