purchase_orders

open a purchase order

Opens one purchase order and returns it. The body names the destination location_id (required) and, optionally, order_type, supplier_id, source_location_id, recommended_quantity, order_date, expected_delivery_date and commitment_id.

It takes no line items. An order opened here is empty, and total_line_items on the response is 0; bulk_create_purchase_orders is the door that creates orders together with their lines, one order per supplier and location, and update_purchase_order is the one that adds lines to an order that already exists.

commitment_id records which Commitment the order is placed against, and an id this organisation does not have is refused 400. Send it only when it came from a Commitments read.

A transfer (order_type=TRANSFER, source_location_id required) opened here is empty like every other order this door opens, so it draws no quantity and no source shelf is read. The shortfall refusal belongs to bulk_create_purchase_orders, the door that sends line items, and is documented there. A purchase order is never checked against a shelf on either door, because a buy asks a supplier for units nobody holds yet.

Scope: purchase_orders:write, which includes purchase_orders:read.

post/api/v1/organizations/{organization_id}/purchase-orders

Request

  • Base URL: https://api.app.tightly.io
  • URL: https://api.app.tightly.io/api/v1/organizations/{organization_id}/purchase-orders
  • Auth: HTTP bearer

Path parameters

organization_idstring required

The organisation. On the key path it must be the key's own organisation. A key naming another one is refused organization_mismatch rather than quietly served its own rows.

Headers

Tightly-Versionstring
Example:2026-11

The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.

Idempotency-Keystring
Example:b8f1c0d2-6a4e-4f39-9c21-0d5f2e7a1b44

A string of your own, up to 255 characters, that makes this write safe to retry. Send the same key twice and the second request is answered with the first one's status and body instead of writing again, so a client that retried after a timeout ends holding the record's id rather than creating a second one. Reusing a key with a different body, or while the first request is still running, is refused 409. A write that failed releases its key. Keys answer for 24 hours and belong to the API key that used them. A key longer than 255 characters is ignored and the write goes ahead without the guarantee.

Request body

cancel_datestring date

The last day of the ship window, inclusive. After it the buyer may walk away from whatever the vendor has not shipped. Must not be before ship_window_start.

commitment_idstring nullable
expected_delivery_datestring date
location_idstring required
order_datestring date
order_typeunknown
recommended_quantityinteger nullable
ship_window_startstring date

The first day the vendor may ship this order. Optional, and normally absent: most orders are placed against an expected delivery date and no window.

source_location_idstring nullable
supplier_idstring nullable

Response

The purchase order as created

dataobject
messageobject

severity, service and desc.

Changes

No recorded changes to this operation across all 1 revision of this API.