Review Assign
Route a review record to a reviewer with POST /v1/review/:id/assign: set assigned_to by user UUID, pass null to unassign, and build per-reviewer queues.
POST /v1/review/:id/assign sets the assignee on a review item, routing it to a specific team member's review workload. Assignments help distribute the queue and track who is responsible for each item: the assigned_to value appears on every list and detail response, and the platform's review queue lets reviewers filter to their own items. Pass null as the user_id to unassign an item and return it to the shared pool.
Assignment is routing metadata, not an access control: any key with write scope can action any visible record regardless of who it is assigned to, and an assignment never blocks or expires. The endpoint also does not verify that the UUID belongs to a member of your team — it stores whatever UUID you send — so drive assignments from a trusted roster of user ids rather than free-form input. User ids are visible to workspace admins in the platform's team settings.
The body contract is strict about presence: the user_id key must be present — a user UUID to assign, or an explicit JSON null to unassign. Omitting the key entirely fails validation with a 400, because an absent value is indistinguishable from a typo and silently unassigning on it would be destructive. Reassigning an already-assigned item simply overwrites assigned_to; there is no assignment history on the record, so log reassignments externally if you need that trail.
A typical distribution loop: page [GET /v1/review?status=pending](list-review-items), skip rows where assigned_to is already set, and spread the remainder round-robin or by schema_id across your reviewers. Per-reviewer queues are then a client-side filter on assigned_to. Because assignment does not change status, your pending-count metrics from [GET /v1/review/stats](review-stats) are unaffected by any amount of reassignment.
user_id key must be present in the request body: send a user UUID to assign, or an explicit null to unassign. Omitting the key entirely fails validation with a 400./v1/review/:id/assignPath parameters
Body parameters
curl — assign
curl -s -X POST https://api.talonic.com/v1/review/a1b2c3d4-e5f6-7890-abcd-ef1234567890/assign \
-H "Authorization: Bearer tlnc_your_api_key" \
-H "Content-Type: application/json" \
-d '{"user_id": "e5f6a7b8-c9d0-1234-efab-345678901234"}'curl — unassign
curl -s -X POST https://api.talonic.com/v1/review/a1b2c3d4-e5f6-7890-abcd-ef1234567890/assign \
-H "Authorization: Bearer tlnc_your_api_key" \
-H "Content-Type: application/json" \
-d '{"user_id": null}'Response
Response fields
Response
{
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"run_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"document_id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
"schema_id": "d4e5f6a7-b8c9-0123-defa-234567890123",
"status": "pending",
"overall_confidence": 0.72,
"assigned_to": "e5f6a7b8-c9d0-1234-efab-345678901234",
"reviewed_by": null,
"reviewed_at": null,
"created_at": "2026-08-12T09:00:00.000Z",
"links": {
"self": "/v1/review/a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"action": "/v1/review/a1b2c3d4-e5f6-7890-abcd-ef1234567890/action"
}
}Errors
Error responses
Assignments are typically made after listing pending items via GET /v1/review and distributing them across team members. The assigned_to field appears in list and detail responses, so downstream tools can filter by assignee to build per-reviewer queues, and unassigned items (assigned_to: null) form the shared pool anyone can pick from.