Changelog

Every change to the public API, newest first. Changes within v1 only add; a removal or incompatible change is announced here at least 12 months ahead. See Versioning & deprecation.

21 October 2026: a packed order can go back to packing

• When a packer corrects a packing mistake, a packed order goes back to packing, to be packed again. GET /api/v1/orders/changes reports it as an order.status_changed to packing. Nothing else changes: packing was already one of the statuses. See What happens next in the warehouse.

18 October 2026: when the customer ordered

• POST /api/v1/orders takes an optional ordered_at: when the customer placed the order, as an ISO 8601 date-time with its offset, or a bare date (YYYY-MM-DD) when you only know the day. Picked keeps it, shows it on the order page and dates the packing slip by it. Without it nothing changes: the order imports as before.

18 October 2026: an order can go back to pending

• An order whose pick run stops before the end goes back from picking to pending, to be planned again. GET /api/v1/orders/changes reports it as an order.status_changed to pending, and the order keeps its picked_quantity. Nothing else changes: pending was already one of the statuses. See What happens next in the warehouse.

18 October 2026: the reference documents every error

• Every 4xx and 5xx in the API reference now names the error envelope you already receive: message and a stable code, plus the field errors on a 422. Nothing on the wire changed; a client generated from the specification can now read code.
• The specification lists its tags and a support contact, and describes every operation.

18 October 2026: links on every answer

• Every v1 resource and page carries HAL-style _links, a field only added. A resource with a GET of its own links itself: a receipt, a process run, a stock level, the node catalogue. A page links itself and the pages either side (_links.next, _links.prev) with your filters kept: GET /api/v1/locations, GET /api/v1/stock/changes, and GET /api/v1/stock with changed_since. GET /api/v1/stock/changes/feed links its next read while hasMore. GET /api/v1/warehouses and a skus read of GET /api/v1/stock link themselves.
• POST /api/v1/receipts and POST /api/v1/processes/{process}/runs answer a new receipt or run with a Location header where to read it back. A dry run, and an answer that returns one made before, carry none.

17 October 2026: follow order changes

• GET /api/v1/orders/changes?after={cursor} reads every change to your orders after a cursor, oldest first: an order taking a status (order.status_changed), and a shipment created, moved to another carrier, labelled, handed to the carrier, delivered, failed or returned (shipment.created, shipment.carrier_changed, shipment.label_created, shipment.dispatched, shipment.delivered, shipment.failed, shipment.returned). Each embeds the order as it is now, and the page links _links.next while more are waiting. It needs orders:read. See Follow order changes.

17 October 2026: read an order back

• GET /api/v1/orders/{id} reads an order back: its status; per line picked_quantity, shipped_quantity and closed_short_quantity (the first two null, meaning not counted, while the warehouse counts nothing for the order); and its shipments with carrier, tracking number, the carrier's tracking link, and each parcels entry when it went out as several. It needs the new orders:read ability. The customer's name and address are never part of it. See Follow the order to shipped.
• POST /api/v1/orders answers a new order with a Location header and _links.order, where to read it back. Answers start carrying HAL-style _links: a field only added, so nothing you read today moves.

15 October 2026: use an answer in later steps

• A step that waits for a signal or a callback can take fields of its payload or data into outputs that later steps show and use. POST /api/v1/process-runs/callbacks/{token} answers 422 when data lacks such a field or has one of another type, and the work keeps waiting. A signal sent to POST /api/v1/process-events/{eventKey} that lacks one doesn't wake that step. See Use the answer in later steps.
• A signal that arrives after a step's Give up after has passed wakes nothing: the step takes timed_out, whenever Picked gets round to it. Before, a signal in the minute after the timeout could still win.

15 October 2026: an answer from your system

• POST /api/v1/process-runs/callbacks/{token} answers an external action step: the step calls your endpoint with a single-use callback_url, and calling it back wakes that one piece of work with your outcome and data. It needs no API token. See Let your system decide a step.

15 October 2026: a correction to how order lines find their product

• POST /api/v1/orders matches a line's product_external_ref only against products you manage in Picked. A product a connected ERP or shop imported carries that system's id as its reference, and an order line could name the wrong product by sharing it. Such a product is now matched by the line's SKU or barcode, and a line that matches nothing gets a placeholder, listed in provisioned_products. Such a placeholder's external_ref is empty when the line's ref was its SKU or another product's reference: match it to your line by sku. This takes effect at once, an exception to the 12 months' notice above: the old match could ship the wrong product, and no integration relied on it yet. See Push orders.

14 October 2026: start a process run

• POST /api/v1/processes/{process}/runs starts a run of a process, named by its public id, with its starting variables: it lands in the claim pool on the floor, as a scheduled run does. GET /api/v1/process-runs/{id} reads it back. Both need the new process-runs:write ability. See Start a process run from an outside system.
• The Idempotency-Key header: on POST /processes/{process}/runs, a retry with the same key within 24 hours returns the first response and opens nothing. See Idempotency.
• Picked-Dry-Run: true works on starting a run too.

13 October 2026: warehouse and location ids, and English answers

• GET /api/v1/warehouses lists your warehouses with the warehouse_id that orders and receipts take, and GET /api/v1/locations your locations with the location_id that stock changes filter by. Any API token may call both, whatever its abilities. See Getting started.
• Every /api/v1 answer is in English, error message and validation errors included, whatever language the server runs in.

13 October 2026: stock levels changed since a moment

• GET /api/v1/stock takes changed_since: the levels of every product whose stock, order commitments or locations changed since then, a page at a time. Order commitments never showed in /stock/changes, so this is how a webshop learns that an order took stock. The answer has the shape of a skus read, with pagination added. See Keep your webshop's stock in sync.

13 October 2026: a cursor on stock changes

• GET /api/v1/stock/changes/feed?after=<cursor>: the stock changes after a cursor, oldest first, with the nextCursor to send next and hasMore. A change that lands while you read is neither skipped nor read twice. GET /api/v1/stock/changes still answers pages, unchanged. See Paging through stock changes.

13 October 2026: the v1 baseline

This entry records the v1 API as it stands when these guides were published. Every later change is listed above it.

Endpoints

Behaviour

• One error body for every failure, with a stable code.
• Rate limits of 200 requests per minute for the stock endpoints and 60 for the rest, per workspace, with X-RateLimit-Limit and X-RateLimit-Remaining on every response to an authenticated call.
• Idempotent order imports by external_id, and delivery announcements by reference.
• Dry runs with the Picked-Dry-Run header on POST /api/v1/orders and POST /api/v1/receipts.