---
title: "What the scoped products are missing for planning, and how many each gap costs"
method: GET
path: "/api/v1/products/completeness"
tags: ["products"]
---

# What the scoped products are missing for planning, and how many each gap costs

`GET /api/v1/products/completeness`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/products/completeness`
- Auth: HTTP bearer

A statement about a whole scope rather than a page of it: how many products it holds, how many are planning-complete, and one row per planning attribute saying how many products are missing it.

The six attributes are `category`, `price_band`, `size_curve`, `selling_window`, `cost` and `lifecycle`. Each row carries the `label` a face prints, the `reason` the gap matters, `missing_products` (planning should ask for this), `review_products` (declared and detected disagree, worth a look) and `affected_pairs`, the variant-by-sales-channel pairs those products cover.

`affected_pairs` and `pairs` are null, not 0, for an organisation with no channel pairs at all. Absence and zero are different answers and are served differently.

It takes the same `filter_args` and `search` as the products table, so a completeness figure can be read for exactly the set a table page came from. It is not paginated: `offset` and `limit` are accepted and ignored, because completeness describes the scope and not a page of it.

Scope: `products:read`.

## Query parameters

- `search` string
- `filter_args` string

## Headers

- `Tightly-Version` string

## Response `200`

The scope's product count, its complete count, and one row per planning attribute.

- object
  - `data` GetProductsCompletenessPayload
    - `complete_products` integer, required
    - `fields` PlanningFieldCompleteness[], required
      - `affected_pairs` integer, nullable
      - `field` string, required
      - `label` string, required
      - `missing_products` integer, required
      - `reason` string, required
      - `review_products` integer, required
    - `pairs` integer, nullable
    - `products` integer, required
  - `message` object: severity, service and desc.

## Other responses

- `400`: filter_args is not valid JSON, or names a key the products table does not accept.
- `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.
- `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)