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

# Service lifecycle

> How an individual service (case data) moves through its states, and how the lifecycle differs by service type, category, and subcategory.

export const ExpandableTable = ({children, title}) => {
  const [expanded, setExpanded] = useState(false);
  useEffect(() => {
    if (!expanded) return;
    const onKey = e => {
      if (e.key === "Escape") setExpanded(false);
    };
    document.addEventListener("keydown", onKey);
    const prevOverflow = document.body.style.overflow;
    document.body.style.overflow = "hidden";
    return () => {
      document.removeEventListener("keydown", onKey);
      document.body.style.overflow = prevOverflow;
    };
  }, [expanded]);
  const ExpandIcon = <svg width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round" aria-hidden="true">
      <path d="M15 3h6v6" />
      <path d="M9 21H3v-6" />
      <path d="M21 3l-7 7" />
      <path d="M3 21l7-7" />
    </svg>;
  const CloseIcon = <svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round" aria-hidden="true">
      <path d="M18 6L6 18" />
      <path d="M6 6l12 12" />
    </svg>;
  return <>
      <div className="expandable-table group relative my-6">
        <button type="button" aria-label="Expand table" title="Expand table" onClick={() => setExpanded(true)} className="expandable-table-trigger absolute top-2 right-2 z-10 opacity-0 group-hover:opacity-100 focus:opacity-100 transition-opacity flex items-center justify-center w-8 h-8 rounded-md bg-white/90 dark:bg-zinc-900/90 border border-zinc-200 dark:border-zinc-700 shadow-sm hover:bg-white dark:hover:bg-zinc-800 cursor-pointer text-zinc-700 dark:text-zinc-200">
          {ExpandIcon}
        </button>
        <div className="expandable-table-inner overflow-x-auto">{children}</div>
      </div>

      {expanded && <div className="expandable-table-overlay fixed inset-0 z-[9999] flex items-center justify-center bg-black/60 backdrop-blur-sm p-4" onClick={() => setExpanded(false)} role="dialog" aria-modal="true" aria-label={title || "Expanded table"}>
          <div className="expandable-table-modal relative bg-white dark:bg-zinc-900 rounded-lg shadow-2xl w-full max-w-[95vw] max-h-[90vh] overflow-auto p-6" onClick={e => e.stopPropagation()}>
            <button type="button" aria-label="Close expanded table" title="Close" onClick={() => setExpanded(false)} className="absolute top-3 right-3 z-10 flex items-center justify-center w-8 h-8 rounded-md bg-zinc-100 hover:bg-zinc-200 dark:bg-zinc-800 dark:hover:bg-zinc-700 cursor-pointer text-zinc-700 dark:text-zinc-200">
              {CloseIcon}
            </button>
            {title && <div className="expandable-table-modal-title text-sm font-semibold text-zinc-700 dark:text-zinc-200 mb-4 pr-10">
                {title}
              </div>}
            <div className="expandable-table-modal-inner">{children}</div>
          </div>
        </div>}
    </>;
};

<Warning>This page is a <Badge color="yellow" size="md">Draft</Badge> and subject to change.</Warning>

Each [service](/background-check-api/reference/service) ordered on a case is represented in the API as **case data** — a single record per service with its own status. A case's overall status is a roll-up of the statuses of all of its case data records.

While [the case lifecycle](/background-check-api/overview/case-lifecycle) describes how a case moves through onboarding, processing, and adjudication at a high level, each underlying service runs its **own** lifecycle in parallel. The states a service can be in, the substates it surfaces while pending, and the terminal status it lands in all depend on the service's [type, category, and subcategory](/background-check-api/reference/service-type).

This page describes the service-level lifecycle for each service category, and clarifies the nuances that customers should account for when integrating with the platform.

## Service-level status model

A case data record has two status fields that, together, describe its current state:

* **Status** (`statusId`) — the primary state of the service. The full enumeration is documented in [Case data statuses](/background-check-api/reference/case-data-status). A service starts in `pending` and progresses to a terminal status when it completes.
* **Pending status** (`pendingStatusId`) — an optional sub-state. It is most commonly set while `status = pending` to communicate *what stage of processing* the service is in (for example, drug screening scheduled, sent to lab, awaiting medical review). It may also remain set on a terminal status to communicate *why* the service ended in that state (for example, `consider` + `pending-status-no-show`).

Whenever either field changes, the platform emits a [`casedata.statuschange` webhook](/background-check-api/reference/webhooks/events/case-data-status-change). Integrations that need fine-grained progress reporting should subscribe to this event and inspect both fields together rather than only `statusId`.

### Statuses

<ExpandableTable title="Status definitions and applicability">
  | Status                                                   | Terminal | Meaning                                                                           | Notes                                                                                                                                                     |
  | -------------------------------------------------------- | -------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | <pre class="not-prose font-semibold">`pending`</pre>     | No       | In progress — service processing has started but not yet completed.               | All services start here; progress is typically reflected in `pendingStatusId`, see the [Pending substates](#pending-substates) section below for details. |
  | <pre class="not-prose font-semibold">`clear`</pre>       | Yes      | Done and good — no findings or discrepancies.                                     | Used for record-search services that return no actionable hits.                                                                                           |
  | <pre class="not-prose font-semibold">`consider`</pre>    | Yes      | Done and needs review — findings exist that the customer must adjudicate.         | The most common non-clean terminal across all screening services.                                                                                         |
  | <pre class="not-prose font-semibold">`acknowledge`</pre> | Yes      | Done positive — affirmative confirmation.                                         | Used by services that verify a credential or fitness (Verification, Professional License, OHS Titer/Vaccination/Physical).                                |
  | <pre class="not-prose font-semibold">`not_found`</pre>   | Yes      | Unable to verify — the source could not be reached, or no matching record exists. | Used by Verification, Professional License, MVR, and some Identity Verification services.                                                                 |
  | <pre class="not-prose font-semibold">`complete`</pre>    | Yes      | Done without prejudice — no pass/fail interpretation.                             | Used by Payment, Shipment, and Document Processing services.                                                                                              |
  | <pre class="not-prose font-semibold">`canceled`</pre>    | Yes      | Service was not performed.                                                        | Possible on any service.                                                                                                                                  |
  | <pre class="not-prose font-semibold">`error`</pre>       | No       | Processing encountered an unexpected error.                                       | Transitional in practice; can return to `pending` once error is resolved by the system or KarmaCheck customer support intervention.                       |
</ExpandableTable>

<Info>**Note:** even when a service reaches a terminal status, it may later be reopened and transition back to `pending` in certain situations (for example, contested results, corrected source data, or manual reprocessing).</Info>

### Status applicability matrix

The following matrix summarizes which terminal statuses are reachable by each category. Use this to validate that your integration handles the right set of outcomes per service.

<ExpandableTable title="Terminal status applicability by service category">
  | Status                                                   | IDV | Criminal | MVR | Verification | Pro License | OHS Physical | OHS TB | OHS Titer | OHS Vacc | OHS Drug | Document Processing | Payment | Shipment | Legal |
  | -------------------------------------------------------- | --- | -------- | --- | ------------ | ----------- | ------------ | ------ | --------- | -------- | -------- | ------------------- | ------- | -------- | ----- |
  | <pre class="not-prose font-semibold">`pending`</pre>     | ✓   | ✓        | ✓   | ✓            | ✓           | ✓            | ✓      | ✓         | ✓        | ✓        | ✓                   | ✓       | ✓        | ✓     |
  | <pre class="not-prose font-semibold">`clear`</pre>       | ✓   | ✓        | ✓   |              |             | ✓            | ✓      |           |          | ✓        |                     |         |          |       |
  | <pre class="not-prose font-semibold">`complete`</pre>    |     |          |     |              |             |              |        |           |          |          | ✓                   | ✓       | ✓        |       |
  | <pre class="not-prose font-semibold">`acknowledge`</pre> |     |          |     | ✓            | ✓           | ✓            | ✓      | ✓         | ✓        |          |                     |         |          | ✓     |
  | <pre class="not-prose font-semibold">`consider`</pre>    | ✓   | ✓        | ✓   | ✓            | ✓           | ✓            | ✓      | ✓         | ✓        | ✓        | ✓                   |         |          |       |
  | <pre class="not-prose font-semibold">`not_found`</pre>   | ✓   |          | ✓   | ✓            | ✓           |              |        |           |          |          |                     |         |          |       |
  | <pre class="not-prose font-semibold">`canceled`</pre>    | ✓   | ✓        | ✓   | ✓            | ✓           | ✓            | ✓      | ✓         | ✓        | ✓        | ✓                   | ✓       | ✓        |       |
  | <pre class="not-prose font-semibold">`error`</pre>       | ✓   | ✓        | ✓   | ✓            | ✓           | ✓            | ✓      | ✓         | ✓        | ✓        | ✓                   | ✓       | ✓        | ✓     |
</ExpandableTable>

<Info> **Note:** The status names and service type/category names shown in the tables above are the human-friendly names; the canonical status IDs and service type/category IDs used in the API are documented in detail on the [Case data statuses](/background-check-api/reference/case-data-status) page and [Service type/categories](/background-check-api/reference/service-type) page.  Be sure to use the IDs when processing API responses and interacting with the API.</Info>

### Pending Status applicablity matrix

While `statusId` remains `pending`, the `pendingStatusId` field communicates *where* in the workflow a service is — for example, `pending-status-scheduled` when an OHS appointment has been booked, or `drugtest-sent` when a specimen has been shipped to the lab. Long-running services (especially OHS Drug Screening, TB testing, and Vaccination) progress almost entirely through changes to `pendingStatusId` while `statusId` stays `pending`, so consumers that only watch `statusId` will miss most of the lifecycle.

<ExpandableTable title="Pending substates applicability by service category">
  | Pending substate <small>(pendingStatusId)</small>            | Verification | Pro License | OHS Physical | OHS TB | OHS Titer | OHS Vacc | OHS Drug |
  | ------------------------------------------------------------ | ------------ | ----------- | ------------ | ------ | --------- | -------- | -------- |
  | <pre class="not-prose">`pending-status-not-performed`</pre>  | ✓            | ✓           | ✓            | ✓      | ✓         | ✓        | ✓        |
  | <pre class="not-prose">`pending-status-requested`</pre>      |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-scheduled`</pre>      |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-rescheduled`</pre>    |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-canceled`</pre>       |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-pending`</pre>        |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-partial`</pre>        |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-medical-review`</pre> |              |             | ✓            | ✓      | ✓         | ✓        |          |
  | <pre class="not-prose">`pending-status-suspended`</pre>      |              |             |              | ✓      |           |          |          |
  | <pre class="not-prose">`pending-status-no-show`</pre>        |              |             | ✓            | ✓      | ✓         | ✓        | ✓        |
  | <pre class="not-prose">`pending-status-refusal`</pre>        |              |             | ✓            |        |           | ✓        | ✓        |
  | <pre class="not-prose">`drugtest-*`</pre>                    |              |             |              |        |           |          | ✓        |
</ExpandableTable>

<Info>
  **Notes:**

  * See [Pending status](/background-check-api/reference/case-data-status#pending-status) for the complete enumeration of pending statuses.
  * If a service type/category/subcategory does not appear in the Pending Status applicablity matrix above, it means that it does not have any pending substates.
  * The service type/category names shown in the Pending Status applicability matrix above are human-friendly names; the canonical service type/category IDs used in the API are documented in detail on the [Service type/categories](/background-check-api/reference/service-type) page.  Be sure to use the IDs when processing API responses and interacting with the API.
</Info>

## Integration guidance

* **Subscribe to `casedata.statuschange`.** Long-running services (especially OHS Drug, TB skin test, Vaccination) communicate progress almost entirely through `pendingStatusId` while `statusId` remains `pending`. Polling `statusId` alone will miss most of the lifecycle.
* **Treat `(statusId, pendingStatusId)` as a tuple.** A terminal `consider` carries different meaning when paired with `drugtest-expired` versus `pending-status-no-show` versus a real positive lab result. The pending substate is preserved on terminal records for exactly this reason.
* **Use the right "passed" terminal per category.** Criminal/MVR/IDV pass with `clear`. Verification, Professional License, and most OHS services pass with `acknowledge`. Payment passes with `complete`. A single `statusId === 'clear'` check is not portable across all services.
* **Account for non-monotonic transitions.** A service can move backwards (for example, `pending-status-scheduled` → `pending-status-canceled` → `pending-status-requested`) and a terminal status can be re-opened to `pending` if a result is contested or new information arrives. Build for idempotent processing of `casedata.statuschange` events.
* **`not_found` is not a failure.** It means the source could not produce a record. Treat it as a distinct outcome from `consider` in your adjudication flow — many customers route `not_found` to manual review rather than auto-decline.
* If you are going to generate a [Custom Report](/background-check-api/reference/reporting/generate-custom-report) for a service (or set of services), do so only once the service(s) has reached a terminal status.

## Lifecycles by service category

The following sections describe the lifecycle for each category. Substates listed in parentheses are pending substates that can accompany `pending` (or, where noted, a terminal status).

### Identity Verification (`service-cat-idv`)

Includes SSN trace, SSN validation, CBSV, IDV document/liveness, Death Master, and social media services. Most identity services are "instant" and return a terminal status quickly with no pending substate.

```
pending → clear
        ↘ consider
        ↘ not_found
        ↘ canceled
```

| Reachable status | Typical meaning                                                                               |
| ---------------- | --------------------------------------------------------------------------------------------- |
| `pending`        | Identity check submitted to the vendor.                                                       |
| `clear`          | Identity confirmed; no discrepancies. **Terminal.**                                           |
| `consider`       | Discrepancy detected (failed liveness, SSN mismatch, etc.). **Terminal.**                     |
| `not_found`      | No matching record could be located (rare; specific to SSN/DMF-style services). **Terminal.** |
| `canceled`       | Service was not performed. **Terminal.**                                                      |

### Criminal Check (`service-cat-criminal`)

Includes county, state, federal, and national criminal searches, civil searches, sex offender registries, FACIS, and global watchlists.  These services typically run against multiple jurisdictions and can take several days to complete but do not use pending substates.

```
pending → clear
        ↘ consider
        ↘ canceled
```

| Reachable status | Typical meaning                                                                              |
| ---------------- | -------------------------------------------------------------------------------------------- |
| `pending`        | Search is in progress, including any per-jurisdiction sub-searches.                          |
| `clear`          | No actionable records were found in any searched jurisdiction. **Terminal.**                 |
| `consider`       | One or more jurisdictions returned records that require customer adjudication. **Terminal.** |
| `canceled`       | Search was not performed. **Terminal.**                                                      |

<Info>**Note on multi-jurisdiction searches.** County, state, and federal criminal searches may run against multiple jurisdictions. Each jurisdiction has its own sub-status (`clear`, `consider`, `pending`, `canceled`) inside the case data details payload, but the top-level `statusId` is the authoritative roll-up that customers should adjudicate against. Records that are still being reviewed internally before being released to the customer will keep the top-level `statusId` at `pending` until review completes.</Info>

<Info>Criminal searches **do not** use `not_found` — a search that returns no records is `clear`, not `not_found`.</Info>

### Motor Vehicle Record Check (`service-cat-mvr`)

```
pending → clear
        ↘ consider
        ↘ not_found
        ↘ canceled
```

| Reachable status | Typical meaning                                                        |
| ---------------- | ---------------------------------------------------------------------- |
| `pending`        | DMV query in progress.                                                 |
| `clear`          | Driving record returned; no actionable violations. **Terminal.**       |
| `consider`       | Violations or restrictions on the record require review. **Terminal.** |
| `not_found`      | License number could not be matched in the DMV system. **Terminal.**   |
| `canceled`       | Service was not performed. **Terminal.**                               |

### Verification (`service-cat-verification`)

Includes employment and education verification services. These services typically involve outreach to a third party and can have a longer pending lifecycle but do not have pending substates.

```
pending → acknowledge
        ↘ consider
        ↘ not_found
        ↘ canceled
```

| Reachable status | Typical meaning                                                                                                 |
| ---------------- | --------------------------------------------------------------------------------------------------------------- |
| `pending`        | Verification request submitted; awaiting response from the verifier or institution.                             |
| `acknowledge`    | Verification confirmed positively — credential matches what the candidate provided. **Terminal.**               |
| `consider`       | Verifier responded but information differs from what the candidate provided. **Terminal.**                      |
| `not_found`      | The institution or employer could not be reached, or the candidate's record could not be located. **Terminal.** |
| `canceled`       | Verification was not performed. **Terminal.**                                                                   |

<Info>For verification services, `acknowledge` — **not** `clear` — is the canonical "passed" terminal. Customers building credential validity checks should treat `acknowledge` and `consider` (with reviewer-approved discrepancies) as the valid terminals.</Info>

### Professional License (`service-cat-pro-lic`)

Professional License and Certification verification services do not use pending substates.

```
pending → acknowledge
        ↘ consider
        ↘ not_found
        ↘ canceled
```

| Reachable status | Typical meaning                                                                               |
| ---------------- | --------------------------------------------------------------------------------------------- |
| `pending`        | License lookup in progress.                                                                   |
| `acknowledge`    | License located, in good standing, and matches candidate-provided data. **Terminal.**         |
| `consider`       | License is expired, suspended, has disciplinary action, or shows a discrepancy. **Terminal.** |
| `not_found`      | License could not be located with the issuing authority. **Terminal.**                        |
| `canceled`       | Service was not performed. **Terminal.**                                                      |

<Info>As with Verification, `acknowledge` is the canonical "passed" terminal for Professional License services.</Info>

### Occupational Health Screening (`service-cat-ohs`)

OHS services share the same case data status model, but each subcategory has its own full lifecycle shape and is documented with a standalone diagram below.

<Info>
  Common OHS patterns across subcategories:

  * Services start in `pending` and usually progress through one or more pending substates before reaching a terminal status.
  * Most OHS subcategories use the `pending-status-*` scheduling family, while Drug Screening uses the `drugtest-*` pending substate family.
  * Terminal outcomes vary by subcategory (for example, `acknowledge`, `clear`, `consider`, `not_found`, `canceled`).
  * A terminal `consider` may carry `pending-status-no-show` or `pending-status-refusal`, and a terminal `canceled` may carry `pending-status-not-performed`.
</Info>

The subsections below describe what is unique about each OHS subcategory.

#### Physical (`service-subcat-physical`)

Includes DOT physicals, fit-for-duty exams, and respirator clearance.

```text theme={null}
pending → pending (substates) → acknowledge | clear
                   |            ↘ consider
                   |            ↘ canceled
                   |
                   ↓
        ↕ pending-status-requested       (scheduling invite sent to candidate)
        ↕ pending-status-scheduled       (clinic appointment booked)
        ↕ pending-status-rescheduled     (appointment moved to a new time)
        ↕ pending-status-canceled        (appointment canceled; may reschedule)
        ↕ pending-status-pending         (clinic processing results)
        ↕ pending-status-partial         (some results returned, others outstanding)
        ↕ pending-status-medical-review  (where applicable)
        ↕ pending-status-no-show         (candidate did not attend appointment)
        ↕ pending-status-refusal         (candidate refused the exam)
        ↕ pending-status-not-performed   (service was not run)
```

<Info>`acknowledge` is used when a physical is affirmatively pass/fit (e.g., DOT physical fit-for-duty). `clear` may be used for portion-style sub-exams that have a simple pass/fail. `consider` indicates findings the customer needs to review (including no-show or refusal, surfaced via the pending substate).</Info>

#### Tuberculosis (`service-subcat-tb`)

TB tests have two distinct lifecycle shapes depending on the test type:

```text theme={null}
pending → pending (substates) → acknowledge | clear
                   |            ↘ consider
                   |            ↘ canceled
                   |
                   ↓
        ↕ pending-status-requested       (scheduling invite sent to candidate)
        ↕ pending-status-scheduled       (clinic appointment booked)
        ↕ pending-status-rescheduled     (appointment moved to a new time)
        ↕ pending-status-canceled        (appointment canceled; may reschedule)
        ↕ pending-status-pending         (clinic processing results)
        ↕ pending-status-partial         (some results returned, others outstanding)
        ↕ pending-status-medical-review  (blood/chest X-ray where applicable)
        ↕ pending-status-suspended       (PPD only: waiting for TB read)
        ↕ pending-status-no-show         (candidate did not attend appointment)
        ↕ pending-status-not-performed   (service was not run)
```

* **TB skin test (PPD)** is a two-visit test. After placement, the case data transitions to `pending / pending-status-suspended` ("Waiting for TB Read") while the candidate returns 48–72 hours later for the read. Final terminal is `acknowledge` (negative read), `consider` (positive/equivocal), or `canceled`.
* **TB blood (QuantiFERON, T-Spot)** and **TB chest X-ray** follow the standard OHS scheduling preamble and produce `acknowledge` / `consider` / `clear` / `canceled` without `pending-status-suspended`.

#### Titer (`service-subcat-titer`)

```text theme={null}
pending → pending (substates) → acknowledge
                   |            ↘ consider
                   |            ↘ not_found
                   |            ↘ canceled
                   |
                   ↓
        ↕ pending-status-requested       (scheduling invite sent to candidate)
        ↕ pending-status-scheduled       (clinic appointment booked)
        ↕ pending-status-rescheduled     (appointment moved to a new time)
        ↕ pending-status-canceled        (appointment canceled; may reschedule)
        ↕ pending-status-pending         (clinic processing results)
        ↕ pending-status-partial         (some titer results returned, others outstanding)
        ↕ pending-status-medical-review  (where applicable)
        ↕ pending-status-no-show         (candidate did not attend appointment)
        ↕ pending-status-not-performed   (service was not run)
```

<Info>`acknowledge` indicates an immune titer. `consider` indicates a non-immune or equivocal result and typically triggers a follow-up vaccination order. `not_found` is rare and indicates the specimen could not be processed.</Info>

#### Vaccination (`service-subcat-vacc`)

Vaccination services may require multiple doses spread over weeks or months. Between doses, the case data may surface a `partial`-style state:

```text theme={null}
pending → pending (substates) → acknowledge
                   |            ↘ consider
                   |            ↘ canceled
                   |
                   ↓
        ↕ pending-status-requested       (scheduling invite sent to candidate)
        ↕ pending-status-scheduled       (clinic appointment booked)
        ↕ pending-status-rescheduled     (appointment moved to a new time)
        ↕ pending-status-canceled        (appointment canceled; may reschedule)
        ↕ pending-status-pending         (clinic processing results)
        ↕ pending-status-partial         (intermediate doses recorded; series incomplete)
        ↕ pending-status-medical-review  (where applicable)
        ↕ pending-status-no-show         (candidate did not attend appointment)
        ↕ pending-status-refusal         (candidate refused the vaccination)
        ↕ pending-status-not-performed   (service was not run)
```

<Info>Integrations that surface vaccination progress to customers should treat `pending / pending-status-partial` as a long-lived intermediate state and only consider the service finalized when it transitions out of `pending`.</Info>

#### Drug Screening (`service-subcat-drug`)

Drug screenings use the **drug-specific** pending substates rather than the generic OHS ones:

```text theme={null}
pending → pending (substates) → clear
                   |            ↘ consider
                   |            ↘ canceled
                   |
                   ↓
        ↕ drugtest-appointment-requested  (scheduling invite sent to candidate)
        ↕ drugtest-appointment-scheduled  (collection appointment booked)
        ↕ drugtest-appointment-change     (collection appointment rescheduled)
        ↕ drugtest-appointment-canceled   (collection appointment canceled; may reschedule)
        ↕ drugtest-pending                (Pending Custody & Control Form after collection)
        ↕ drugtest-sent                   (specimen sent to lab)
        ↕ drugtest-received               (specimen received at lab)
        ↕ drugtest-review                 (Medical Review Officer review)
        ↕ pending-status-no-show          (candidate did not attend collection appointment)
        ↕ pending-status-refusal          (candidate refused to provide specimen)
        ↕ pending-status-not-performed    (service was not run)
```

<Info>A terminal `consider` may carry `drugtest-expired`, `pending-status-no-show`, or `pending-status-refusal` to explain the outcome. Drug screenings do not use `acknowledge` or `not_found`.</Info>

### Document Processing (`service-cat-document-processing`)

Document Processing services do not use pending substates.

```
pending → complete
        ↘ consider
        ↘ canceled
```

| Reachable status | Typical meaning                                                                       |
| ---------------- | ------------------------------------------------------------------------------------- |
| `pending`        | Document extraction/processing is in progress.                                        |
| `complete`       | Processing finished successfully with no additional review required. **Terminal.**    |
| `consider`       | Processing completed but extracted output requires review or follow-up. **Terminal.** |
| `canceled`       | Service was not performed. **Terminal.**                                              |

### Payment (`service-cat-payment`)

Payment services do not use pending substates and have no pass/fail interpretation.

```
pending → complete
        ↘ canceled
```

| Reachable status | Typical meaning                                        |
| ---------------- | ------------------------------------------------------ |
| `pending`        | Payment authorization in progress.                     |
| `complete`       | Payment captured successfully. **Terminal.**           |
| `canceled`       | Payment was not attempted or was voided. **Terminal.** |

### Shipment (`service-type-shipment`)

Shipment services do not use pending substates and have no pass/fail interpretation.

```
pending → complete
        ↘ canceled
```

| Reachable status | Typical meaning                                         |
| ---------------- | ------------------------------------------------------- |
| `pending`        | Shipment workflow is in progress.                       |
| `complete`       | Shipment workflow completed successfully. **Terminal.** |
| `canceled`       | Shipment was not performed or was voided. **Terminal.** |

### Legal (`service-type-legal`)

Legal services are consent/authorization workflows and do not use pending substates and have no pass/fail interpretation.

```
pending → acknowledge
```

| Reachable status | Typical meaning                                                            |
| ---------------- | -------------------------------------------------------------------------- |
| `pending`        | Candidate legal authorization/disclosure flow is in progress.              |
| `acknowledge`    | Candidate completed the legal authorization/disclosure flow. **Terminal.** |

## Related references

* [Case lifecycle](/background-check-api/overview/case-lifecycle)
* [Case-level result and statuses](/background-check-api/reference/case-status)
* [Case data statuses](/background-check-api/reference/case-data-status)
* [Service type and categories](/background-check-api/reference/service-type)
* [Invitation status](/background-check-api/reference/invitation-status)
* [`casedata.statuschange` webhook](/background-check-api/reference/webhooks/events/case-data-status-change)