Skip to main content
Slate’s quality control (QC) system gives you a structured, auditable way to review documents and matter components before they move to the next stage of a legal workflow. You define reusable checklists and processes once, then instantiate individual review requests per matter — either manually or automatically when a file request completes.
Checklist item statuses follow four values: approved, rejected, pending, and not_applicable. Use not_applicable for items that are structurally part of a checklist but irrelevant to a specific review — it keeps your completion rates accurate without forcing artificial approvals.
1

Create a checklist

A checklist is a reusable template of review items. Call POST /v2/qc/checklists to define the checklist and its items.Checklists come in two types, set with checklistType (defaults to quality):
  • quality — items are evaluated as simple pass/fail.
  • review — items can be organized into named groups, support N/A responses (allowNA), allow per-item reviewer notes, and can be assigned to roles. Only review-type checklists can back the one-off requests in Step 3.
Required fields:Optional fields include description, checklistType, roles, and groupType (alphanumeric or numeric, applicable only to review checklists).
cURL
Example Response
Store the id (checklistId) — you will reference it when creating processes and requests.
On a review-type checklist you can organize items into named groups. Call POST /v2/qc/checklists/{qclID}/groups with a groupName and optional groupType (alphanumeric or numeric); the response returns the group’s id, groupName, and groupType. Assign items to a group by setting each item’s groupId on a subsequent PATCH /v2/qc/checklists/{qclID}. The first group created establishes the checklist’s groupType if it was not set at creation. On a request, each item then carries a precomputed group label such as A1 or 1-1.
2

Create a QC process

A process links a checklist to a workflow stage and gives reviewers a named entry point for their queue. Call POST /v2/qc/processes to create the process.Required fields:Optional fields include description and checklistId. You can create a process without a checklist and link one later via PATCH /v2/qc/processes/{id}.
cURL
Example Response
3

Create a QC request

A QC request is the individual review instance for a specific matter or document. Create one manually with POST /v2/qc/requests for ad-hoc reviews.Required fields:Optional fields include reviewee (user ID of the person being reviewed) and notes (context for the reviewer).
cURL
Example Response
For document-triggered QC reviews, Slate automatically creates QC requests when a file request completes — you do not need to call this endpoint manually. Use the processId association on your file request configuration to wire up the automatic trigger.
The checklistId for a manual request must reference an active review-type checklist. Passing a quality-type checklist ID returns a 400 error.
4

Retrieve the request and review items

Load the full QC request — including all checklist items and their current statuses — by calling GET /v2/qc/requests/{qcrID}. Present this data to your reviewer.
cURL
Example Response
Your reviewer works through each item in the checklistItems array and records a decision for each one before submitting the overall review decision.
5

Submit the review decision

Once the reviewer has evaluated every checklist item, submit the overall decision with PATCH /v2/qc/requests/{qcrID}. Include the top-level status, the updated checklistItems array with per-item statuses, and optionally reviewedBy (user ID of the reviewer) and notes (rework notes for the request).
Example Response
Setting an item’s status to not_applicable when the underlying checklist item has allowNA: false will return a 400 error. Always check allowNA on the item before offering that option in your UI.
6

Undo a review decision

If a review was submitted in error or new information requires a re-evaluation, reset the request back to pending by calling POST /v2/qc/requests/{qcrID}/undo. This clears the current decision and all per-item statuses, returning the request to its original reviewable state.
cURL
Example Response
After the undo, return to Step 4 to reload the request and begin a fresh review.
The undo operation clears all reviewer notes and item-level decisions permanently. There is no built-in way to recover the previous review state once the undo is applied. If you need to preserve the original decision for audit purposes, record it before calling this endpoint.

​
List and report on QC activity

To build reviewer queues and dashboards, use the list endpoints. Each requires an owner and returns its results under a named array alongside a pagination object:
  • GET /v2/qc/checklists returns qcChecklists.
  • GET /v2/qc/requests returns qcRequests (filter by status, checklistType, review.shortId, actor, reviewedBy, and more).
  • GET /v2/qc/processes returns qcProcesses.
  • GET /v2/qc/feedback returns qcRequests with extended reporting metadata (“List all QC requests and checklists for reporting”), filterable by reviewedFrom/reviewedTo, processName, roleId, and status.
Every list endpoint supports the standard pagination and ordering parameters (limit, cursor, orderBy, orderDirection). The pagination object carries nextCursor, previousCursor, and totalCount — pass a non-empty nextCursor back as the cursor query parameter to fetch the next page.
All paths in this guide are relative to the QC base URL, https://api.slate.inc/qc (UAT: https://api.uat.slate.inc/qc). A full request URL therefore looks like https://api.slate.inc/qc/v2/qc/requests.