> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slate.inc/llms.txt
> Use this file to discover all available pages before exploring further.

# Quality Control Checklists and Workflows in Slate API

> Define reusable checklists, attach them to workflow processes, and run structured approve/reject QC reviews with role-based item assignments.

Slate's Quality Control API gives you a structured, auditable review layer for any document or workflow output. Before a filing goes to court, before an affidavit is signed, or before a batch of accounts is placed, a QC review can enforce that every required item has been checked by the right person. The system is built around three objects that work together: a **Checklist** defines what gets reviewed, a **Process** connects a checklist to a specific workflow type, and a **QC Request** is the live review instance a reviewer acts on.

## 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 with `POST /v2/qc/checklists/{qclID}/groups`, supplying a `groupName` and an optional `groupType` (`alphanumeric` or `numeric`) that controls how the group's items are numbered (for example `A1` or `1-1`).

**Process** — Links a checklist to a particular workflow type (for example, "affidavit review" or "placement audit"). A process tells Slate which checklist to instantiate when a QC request is created for that workflow.

**QC Request** — The live review instance a reviewer acts on. A QC request can be created automatically when a document's file request completes against a process, or created directly as a one-off with `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

<Steps>
  <Step title="Create a QC request">
    Trigger a one-off QC request by calling `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.

    ```bash theme={null}
    curl --request POST \
      --url "https://api.slate.inc/qc/v2/qc/requests" \
      --header "Authorization: Bearer <your-token>" \
      --header "Content-Type: application/json" \
      --data '{
        "owner": "acme-collections",
        "crid": "CRID-00192",
        "checklistId": "qcl-review-1111-aaaa-bbbb-000000000010",
        "reviewee": "usr-0003-0003-0003-0003-000000000003",
        "notes": "Follow-up review requested by supervisor after initial rejection."
      }'
    ```

    The response includes an `id` and the full list of checklist items the reviewer must evaluate.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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`.

    ```bash theme={null}
    curl --request PATCH \
      --url "https://api.slate.inc/qc/v2/qc/requests/qcr-11111111-aaaa-bbbb-cccc-000000000001" \
      --header "Authorization: Bearer <your-token>" \
      --header "Content-Type: application/json" \
      --data '{
        "status": "approved",
        "reviewedBy": "usr-0004-0004-0004-0004-000000000004",
        "checklistItems": [
          {
            "id": "qcri-aaaa-0001-0001-0001-000000000001",
            "status": "approved"
          },
          {
            "id": "qcri-bbbb-0002-0002-0002-000000000002",
            "status": "approved"
          },
          {
            "id": "qcri-cccc-0003-0003-0003-000000000003",
            "status": "not_applicable",
            "reviewerNote": "No source document available for this batch."
          }
        ]
      }'
    ```
  </Step>

  <Step title="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.

    ```bash theme={null}
    curl --request POST \
      --url "https://api.slate.inc/qc/v2/qc/requests/qcr-11111111-aaaa-bbbb-cccc-000000000001/undo" \
      --header "Authorization: Bearer <your-token>"
    ```
  </Step>
</Steps>

## QC Request Statuses

| Status     | Meaning                                                                                   |
| ---------- | ----------------------------------------------------------------------------------------- |
| `pending`  | The request is open and awaiting reviewer action. All items are still being evaluated.    |
| `approved` | All items passed review. The associated document or workflow step is cleared to proceed.  |
| `rejected` | One or more items failed review. The associated work must be corrected before proceeding. |

## 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

<Note>
  **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.
</Note>

## Feedback and Reporting

Slate provides a dedicated feedback endpoint that aggregates QC requests and checklists for reporting across all reviews in your owner context. Use `GET /v2/qc/feedback` to build reporting dashboards, identify patterns in rejections, or audit reviewer activity over time.

```bash theme={null}
curl --request GET \
  --url "https://api.slate.inc/qc/v2/qc/feedback?owner=acme-collections" \
  --header "Authorization: Bearer <your-token>"
```

The endpoint requires an `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`).