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

{
  "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" }
      ]
    }
  ]
}

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.

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