Skip to main content
Blend orders move through nine statuses. Read status on any order, or call GET /api/v1/orders/statuses for the live list rather than hardcoding it.

​
What you can do in each status

​
Reading the history

This is the endpoint to reach for when an order isn’t where you expect. It shows every transition, which usually explains the current state faster than reasoning about it.
Orders can move backwards. When a prescription is matched to a line on a picked or verified order, the contents have changed, so the order returns to received for re-picking. This is correct behavior, not a fault. Don’t write state machines that assume forward-only transitions.
exception and paused both preserve the status the order came from, so unpausing or resolving an exception returns it to its place rather than to the start.

​
Statuses these are not

A few things look like statuses but aren’t:
  • cancellation_requested and priority_requested are flags. Requesting cancellation or priority does not change the order’s status — see cancelling an order.
  • replacement_request_status is its own enum (pending, fulfilled, declined, cancelled) describing a request, not the order.
  • Shipment status is separate again (shipped, cancelled, delivered) and lives on the shipment inside the order. An order can have more than one shipment.
  • Prescription status is an entirely different lifecycle from order status.

​
Filtering by status

Comma-separate to match several. This is far cheaper than paging the full list and filtering client-side.
Rather than polling for status changes, subscribe to webhooks for order.shipped and order.delivered — see getting notified when an order ships.

Get order statuses

The live enum

Get an order's status history

Every transition

Get orders

status= accepts a comma list

Stuck orders

What exception really means