Stock levels, items, locations, movements, counts and containers need stock.read; creating or changing items and locations, and booking a correction, need stock.write. Receipts need inbound.read and inbound.write. Purchase orders need purchasing.read and purchasing.write. Pick lists need fulfilment.read and team tasks need tasks.read.

A restricted key never gets the new parts by itself. Tick Purchasing, Fulfilment or Tasks under API access when the key needs them. Receipt lines only show unitPrice and currency when the key may also read purchase orders.

An API key that is not restricted has full access, so it can use the Stock API right away.

To limit a key, open Settings > Business > Merchant Channels, open the sales channel, tab Settings, block API access, and tick Read stock levels, items, locations, movements, counts and containers and Adjust stock and create or change items and locations as needed. See "Restrict an API Key (API Access)".

Your account needs QrX warehouse stock switched on. Without it the API answers 403 ACCESS_DENIED.

reserved is everything open orders hold. available is sellable minus reserved.

lastSequence is the number of the last stock movement of that item in that warehouse. It is the same number as sequence in the stock/adjusted webhook.

sku must match exactly; upper and lower case and outer spaces are ignored.

With locationId you only get items that have stock at that location, and locationQuantity holds the units there.

Give stockItemId or sku. Exactly one item must match.

Give locationId. An account without bins may give warehouseId instead, or nothing for the default warehouse.

delta is the change in units: positive adds, negative removes. It cannot be 0.

reasonCode is required: correction, found, damaged, expired, defective, lost, theft, sample or other.

For an item with lots, give lotCode and, when the item needs one, expiryDate.

Receipts: GET /api/v1/receipts (filter state, warehouseId, q), GET /api/v1/receipts/{id}, POST /api/v1/receipts (with announce: true the receipt is announced), PATCH /api/v1/receipts/{id}, POST .../{id}/lines, POST .../{id}/complete and POST .../{id}/cancel.

Purchase orders: GET /api/v1/purchase-orders, GET /api/v1/purchase-orders/{id}, POST /api/v1/purchase-orders (a draft), PATCH .../{id}, POST .../{id}/lines, POST .../{id}/send, POST .../{id}/close and POST .../{id}/cancel. Send works exactly like in PortalX: with email: true QrX e-mails the PDF to the supplier (or to to), at most 5 times per order and 30 times per account per hour (429 RATE_LIMIT_EXCEEDED).

Stock items and locations: POST and PATCH /api/v1/stock/items and /api/v1/stock/locations. Locations need Full WMS with bins. The rows of GET items and GET locations now have version.

Reads: GET /api/v1/stock/movements, GET /api/v1/picklists, GET /api/v1/counts (with /{id} and /{id}/lines), GET /api/v1/containers and GET /api/v1/tasks (with /{id}). Team tasks are read only.

A change of an existing record needs the version you read last. When someone changed the record in the meantime, you get 409: read it again and retry.

Warehouses (scope stock.read, Full WMS): GET /api/v1/warehouses with code, name, default, time zone, address, contact, receiving instructions, loading docks and GLN; GET /api/v1/warehouses/{id}, .../{id}/hours (receiving and dispatch hours per weekday) and .../{id}/closures (with from and cursor).

Transfers (scope stock.read, Full WMS with multiple warehouses and transfers): GET /api/v1/transfers (filter state, warehouseId, direction) and GET /api/v1/transfers/{id} with the lines and the shipping details. Read only.

Purchase orders: create and PATCH accept the header fields reference, supplierReference, buyerUserId, internalNote, incoterm, incotermPlace, paymentTermsDays, shippingCost, shippingVatRate, pricesIncludeVat, deliveryAddress and partialDeliveryAllowed, and lines accept discountPct, vatRate, note, confirmedQty and confirmedOn. Orders return the totals (net, VAT per rate, gross) calculated by QrX. The list filters on reference, expectedFrom and expectedTo. Terms are fixed once the order is sent.

Receipts: create and PATCH accept supplierId to link a receipt to a supplier; rows return it.

Stock items and locations: location writes accept zone or zoneId and the size and capacity fields; item writes accept storage, dangerousGoods, imageUrl and abcClassOverride. POST /api/v1/stock/adjust accepts your own reason codes.

Send your own unique text per correction. When you retry the same request with the same key, you get the first answer again with replayed: true and nothing is booked twice.

The same key with a different body is refused with 409 DUPLICATE_IDEMPOTENCY_KEY.

A key cannot start with a QrX system prefix such as mcp- and cannot end in a colon followed by digits (422).

Every POST and PATCH of the warehouse resources needs the header Idempotency-Key (1 to 140 characters). The same key with the same body on the same route gives the first answer again, with the header Idempotent-Replayed: true. A replayed create of a receipt or purchase order answers the record as it is now.

Answers are kept for 30 days. A call that failed (4xx or 5xx) is not kept, so you may send the same key again.

While the first call with a key is still running you get 409 CONCURRENCY_CONFLICT with Retry-After. A call that stopped halfway frees its key after 15 minutes.

Sending a purchase order with email: true e-mails the supplier at most once per key. If a call fails after the order was sent but before the e-mail, no e-mail follows for that key: check the order's e-mail history in PortalX and send again with a new key.

Every list returns items and nextCursor. Send nextCursor back as cursor for the next page. Null means the end. There is no total count.

Treat a cursor as an opaque value.

With updatedSince you only get rows changed at or after that time. The server looks at up to 1,000 rows per call, so a page can hold fewer rows than limit, even none, while nextCursor is set. Keep calling until nextCursor is null.

Each row has partnerCustomerId (the partner warehouse) and your own id in ownerCustomerId.

Use partnerCustomerId in the query to keep one partner, and warehouseId for one of its warehouses.

Locations are never returned: locationId, GET locations and POST adjust answer 422 in this scope.

You need at least one partner with active access; your own account does not need warehouse stock switched on.

401 UNAUTHORIZED: no valid access token.

403 STOCK_SCOPE_MISSING: the key is restricted and lacks stock.read or stock.write.

403 ACCESS_DENIED: warehouse stock is not on for the account, or, with scope=partner, no partner has active access.

404 STOCK_NOT_FOUND: the item, warehouse or location is not yours.

400 IDEMPOTENCY_KEY_REQUIRED: a POST without the header.

422 VALIDATION_FAILED: bad input, for example delta 0, an unknown reason code, a bad cursor, or more than 50 items with the same SKU or EAN (filter by stockItemId).

409 DUPLICATE_IDEMPOTENCY_KEY: the same key with a different body.

409 STOCK_CONFLICT: not enough stock, stock that is allocated to a pick list, a SKU that matches several items, or an inactive item.

409 CONCURRENCY_CONFLICT: send the same request again with the same key.

429: too many requests; wait for Retry-After.

403 INBOUND_SCOPE_MISSING, PURCHASING_SCOPE_MISSING, FULFILMENT_SCOPE_MISSING or TASKS_SCOPE_MISSING: the key is restricted and lacks that part.

404 INBOUND_NOT_FOUND, PURCHASE_ORDER_NOT_FOUND or NOT_FOUND: the record is not yours.

409 INBOUND_CONFLICT or PURCHASING_CONFLICT: the version or the state does not allow the change.

429 RATE_LIMIT_EXCEEDED: too many supplier e-mails for a purchase order.

400 ZONE_UNKNOWN: the zone is not a live zone of that warehouse. 400 DG_CLASS_UNKNOWN: the dangerous goods class is not a visible class of your account. A reason that needs photos cannot be used through the API.