---
title: "What is still on order for a product, grouped by the variant it is coming for"
method: GET
path: "/api/v1/product/{product_id}/incoming-pos"
tags: ["product"]
---

# What is still on order for a product, grouped by the variant it is coming for

`GET /api/v1/product/{product_id}/incoming-pos`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/product/{product_id}/incoming-pos`
- Auth: HTTP bearer

Open orders carrying any variant of one product, grouped under the variant rather than under the order: one entry per variant that has something inbound, each with `po_count`, `to_count` (transfer orders), `proposal_count` and the orders themselves.

Each order in `purchase_orders` carries its id and name, `order_type` (`PURCHASE`, `TRANSFER` or `MANUFACTURING`), `is_proposal`, `status`, `expected_delivery_date`, supplier and location, the `line_items` and `deliveries` for that variant alone, `ordered_quantity` and `delivered_quantity` for that variant alone, `has_delivery_delay` (true once the expected date is in the past) and `supplier_signals`. `total_ordered` and `total_delivered` on the group are those two summed across its orders and are being retired; sum the orders yourself rather than depending on them.

Fully delivered and cancelled orders are not here. A product with nothing inbound answers `purchase_orders_grouped_by_variant: []`, which is the empty case and not an error.

This is the product's own view. For the same question against a single variant, read the variant's incoming purchase orders; for the orders themselves, with their whole line set, read the purchase orders resource.

Scope: `products:read`.

## Path parameters

- `product_id` string, required

## Headers

- `Tightly-Version` string

## Response `200`

One group per variant with something inbound, each carrying its open orders.

- object
  - `data` GetProductPurchaseOrdersPayload
    - `purchase_orders_grouped_by_variant` PurchaseOrdersGroupedByVariant[]
      - `po_count` integer, required
      - `proposal_count` integer, required
      - `purchase_orders` object[], required
      - `to_count` integer, required
      - `total_delivered` integer, required
      - `total_ordered` integer, required
      - `variant_id` string, required
      - `variant_name` string, required
  - `message` object: severity, service and desc.

## Other responses

- `401`: No usable key: malformed, unknown, revoked, expired or stopped. One refusal covers all five, because telling a caller which is which maps the surface for them.
- `403`: The key may not reach this operation. `scope_missing` when the key does not hold Products; `ip_not_allowed` when the caller's address is outside the key's allowlist. `plan_excludes` when the organisation's plan does not include the public API itself, which is sold with Essentials and is asked of every key minted under that gate. A key minted before the gate existed is never refused by it, whatever the plan holds. Products is ungated, so that is the only plan reason served here.
- `404`: No product in this organisation carries that id.
- `429`: The key has spent its allowance for this minute. 600 reads and 120 writes a minute, counted per key, refused calls included. `Retry-After` says how long to wait.
- `503`: The database is briefly out of reach, which is what a failover or a full connection pool looks like from outside. Wait the seconds `Retry-After` names and send the request again. A read is safe to repeat. A write is not, because the connection was lost in the middle of it, so read the object back before sending it a second time. Branch on the status rather than on `code`, which is `POSTGRES_UNAVAILABLE` from one of the two seams that raise this and `SERVICE_UNAVAILABLE` from the other.

---

[API](https://skmtc.dev/tightly/apis/tightly-api.md) · [All operations](https://skmtc.dev/tightly/apis/tightly-api/llms.txt) · [OpenAPI document](https://skmtc.dev/tightly/apis/tightly-api/revisions/199f7eb35afb?raw)