Core Objects
Checklist — A reusable template that defines the items a reviewer must evaluate. Checklists come in two types:quality— Items are evaluated as simple pass/fail. Used for binary compliance checks.review— Items can be organized into named groups, support N/A responses (allowNA), allow per-item reviewer notes, and can be assigned to specific roles. Used for multi-party review workflows where different reviewers are responsible for different items. Add a group to a review checklist withPOST /v2/qc/checklists/{qclID}/groups, supplying agroupNameand an optionalgroupType(alphanumericornumeric) that controls how the group’s items are numbered (for exampleA1or1-1).
POST /v2/qc/requests (which copies items from a review-type checklist and has no associated document). A QC request is the record a reviewer opens, evaluates item by item, and then approves or rejects. QC requests have a lifecycle with a clear terminal state.
QC Request Lifecycle
1
Create a QC request
Trigger a one-off QC request by calling The response includes an
POST /v2/qc/requests with the owner, crid, and checklistId. The checklistId must reference an active review-type checklist. Slate copies the checklist items and creates a QC request in pending status, with no associated document.id and the full list of checklist items the reviewer must evaluate.2
Reviewer evaluates checklist items
The reviewer opens the QC request and steps through each item. For
quality checklists, each item is marked pass or fail. For review checklists, each item is approved, rejected, or marked N/A, and the reviewer may attach notes. Items assigned to a specific role can only be completed by a reviewer holding that role.3
Approve or reject the QC request
Once all items have been evaluated, the reviewer submits a final decision. A passing review moves the QC request to
approved. A failing review, one or more items failed or were rejected, moves the request to rejected.4
Reset to pending with /undo if needed
If a QC request was approved or rejected in error, call the
/undo endpoint to reset it back to pending. This allows the reviewer to re-evaluate without creating a new request.QC Request Statuses
Roles
review type checklists can define named roles, for example, affiant, notary, or reviewee. Individual checklist items are assigned to a role, and only reviewers with that role assigned in Slate can mark those items. This ensures the right person reviews the right items, and provides a clear audit trail of who approved what.
v1 vs v2 QC
Use v2 for new integrations. In v1, a QC request references a single document with one
template. In v2, a request’s document carries a templates array, and requests may instead reference a review (with a human-readable shortId such as QC-7K3F9A), expose an actors array of participants, and support one-off review requests with no document at all. v2 is the right choice for any workflow that involves multiple document types or standalone reviews in a single QC pass. Existing v1 integrations continue to work, but v2 provides a more flexible foundation going forward.Feedback and Reporting
Slate provides a dedicated feedback endpoint that aggregates QC requests and checklists for reporting across all reviews in your owner context. UseGET /v2/qc/feedback to build reporting dashboards, identify patterns in rejections, or audit reviewer activity over time.
owner and supports the standard Slate pagination and ordering parameters (limit, cursor, orderBy, orderDirection), plus a filter object (for example status, processName, reviewedBy, reviewedFrom, reviewedTo, matterReference, roleId). Results are returned under the qcRequests array alongside a pagination object (nextCursor, previousCursor, totalCount).