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

# Order lifecycle

> How order and service statuses progress, and how to tell when a result is final.

An order moves through a sequence of statuses from creation until every service (test) on it reaches a terminal state. This page explains how to interpret those statuses; the complete enumerations are rendered on the [Get an order](/api-reference/orders/get) reference page.

## Orders and services

An order contains one or more **services** — the individual tests in the ordered package (for example a urine panel and a physical). Each service progresses through its own status independently, and the order's overall `status` is derived from them. Both levels carry an `isFinal` boolean:

```json theme={null}
{
  "object": "order",
  "code": "x9yRIex8Ah",
  "status": "pending",
  "isFinal": false,
  "services": [
    {
      "name": "Urine Lab-based Toxicology",
      "status": "pending_atTheLab",
      "isFinal": false,
      "statusUpdatedAt": "2026-07-10T14:30:00Z",
      "statusHistory": [
        { "status": "ordered", "occurredAt": "2026-07-08T09:00:00Z" },
        { "status": "pending_collectionCompleted", "occurredAt": "2026-07-09T16:45:00Z" },
        { "status": "pending_atTheLab", "occurredAt": "2026-07-10T14:30:00Z" }
      ]
    }
  ]
}
```

<Tip>
  `isFinal` is the authoritative signal that a status is terminal. Branch on it rather than maintaining your own list of final statuses — new statuses are added over time.
</Tip>

## Order statuses

An order is **in progress** while its status is one of:

| Status | Meaning |
| - | - |
| `ordered` | The order has been created. |
| `scheduled` | A collection has been scheduled. |
| `pending` | Collection, lab work, or review is underway. |

Every other order status is **final** (`isFinal: true`). Final statuses fall into a few groups:

| Group | Statuses |
| - | - |
| Outcomes | `negative`, `nonNegative`, `positive`, `pass`, `fail`, `fitForDuty`, `notFitForDuty`, `complete`, `released` |
| Specimen issues | `adulterated`, `substituted`, `unobtainable`, `lostInTransit` |
| Never completed | `cancelled`, `testCancelled`, `testNotPerformed`, `expired`, `noShow`, `incomplete` |
| Errors | `integrationError` |

## Service statuses

Service statuses follow a `family_detail` naming convention: the segment before the underscore is the status family, and the optional segment after it is vendor- or workflow-specific detail. For example, `pending_atTheLab`, `pending_inMROReview`, and `pending_awaitingSignOff` are all refinements of `pending`, while `complete_verified` and `complete_noHits` are refinements of `complete`.

A service is **in progress** while its status family is `ordered`, `scheduled`, `pending`, or `processing`. All other families — `complete`, `incomplete`, `negative`, `positive`, `nonNegative`, `adulterated`, `cancelled`, `expired`, `noShow`, and the rest — are terminal.

When branching on service statuses:

* **Match on the family prefix** (the part before `_`) for routing logic, and treat the detail suffix as informational. New detail suffixes appear as vendor workflows evolve; a `switch` on exact values will eventually miss one.
* **Use `isFinal`** to decide whether more updates are coming for that service.
* The full list of current values is on the [Get an order](/api-reference/orders/get) page under `services[].status`.

## Tracking changes

Each service carries:

| Field | Description |
| - | - |
| `statusUpdatedAt` | When the service entered its current status (ISO 8601). |
| `statusHistory` | Every status the service has been through, each with the time it occurred (`occurredAt`). |

Because [webhook deliveries](/webhooks) can arrive out of order, compare `statusUpdatedAt` against the last value you processed and ignore anything older. `statusHistory` gives you the full audit trail if you need to reconstruct the sequence.

## When is an order done?

Wait for the **order-level** `isFinal: true` rather than tracking individual services: the order flips to final only once every service has reached a terminal status. If you need results per service as they land (for example, showing the physical while toxicology is still at the lab), react to each service's `isFinal` instead.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.