---
title: "A page of variants, one row per SKU"
method: GET
path: "/api/v1/variants/table"
tags: ["variants"]
---

# A page of variants, one row per SKU

`GET /api/v1/variants/table`

## Request

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

A page of variants with the fields a catalogue sync needs per SKU: `variant_id` and its `product_id`, product and variant title, `sku`, vendor, category, description, image, `product_status`, `gtin`, `unit_cost`, `sell_price`, `currency`, `sales_channels`, `selected_options`, the physical fields (`weight`, `length`, `width`, `height`, `uom`, `weight_unit`), `hs_code`, `country_of_origin`, and `last_updated_at` and `last_updated_by`.

Unlike the products table these are plain numbers, not `{min, max}` pairs: a variant has one cost and one price.

Paging is `offset` and `limit`, limit at most 10,000 and 8 by default. `variants_count` and `size` count this page, `filtered_max_size` the filtered set and `max_size` the catalogue. Page on `filtered_max_size`.

Narrow with `filter_args`: product_id, vendor, category, department, product_status, sales_channel_id, country_of_origin and collection_id take `eq` and `in`; unit_cost and sell_price take `gte` and `lte`. `search` matches title, SKU and vendor. Sort with `sort_args`: comma-separated columns, `-` for descending, bare or `+` for ascending. `variant_id`, `sku` and `variant_title` are sortable here as well as the product fields.

`export=true` answers a download URL in `data.url` instead of rows.

Scope: `products:read`.

## Query parameters

- `offset` integer
- `limit` integer
- `search` string
- `filter_args` string
- `sort_args` string
- `export` boolean

## Headers

- `Tightly-Version` string

## Response `200`

A page of variants, with the page's counts and the filtered set's size.
`department` is the source NetSuite item Department label, independent of Brand/Category mapping and distinct from native purchasing subsidiary and the merchandise hierarchy Department. It is read-only; null means no source label. Filter with `eq` or `in` using exact labels. A variant matches its own source Department only.

- object
  - `data` GetPimVariantsTablePayload
    - `filtered_max_size` integer, required
    - `max_size` integer, required
    - `offset` integer, required
    - `rows` PimVariantTableRow[], required
      - `brand_id` string, nullable
      - `brand_name` string, nullable
      - `carton_height` number, nullable
      - `carton_length` number, nullable
      - `carton_quantity` integer, nullable
      - `carton_weight` number, nullable
      - `carton_width` number, nullable
      - `category` string, nullable
      - `country_of_origin` string, nullable
      - `currency` string, nullable
      - `custom_fields` object, nullable
      - `department` string, nullable
      - `description` string, nullable
      - `ean` string, nullable
      - `gtin` string, nullable
      - `height` number, nullable
      - `hs_code` string, nullable
      - `image_url` string, nullable
      - `last_updated_at` string, nullable
      - `last_updated_by` string, nullable
      - `length` number, nullable
      - `physical_basis` string, nullable
      - `product_id` string, required
      - `product_status` string, nullable
      - `product_title` string, nullable
      - `sales_channels` PimSalesChannel[], required
        - `id` string, required
        - `name` string, required
      - `selected_options` object, nullable
      - `sell_price` number, nullable
      - `sku` string, nullable
      - `unit_cbm` number, nullable
      - `unit_cost` number, nullable
      - `unit_kg` number, nullable
      - `uom` string, nullable
      - `upc` string, nullable
      - `variant_id` string, required
      - `variant_title` string, nullable
      - `vendor` string, nullable
      - `weight` number, nullable
      - `weight_unit` string, nullable
      - `width` number, nullable
    - `size` integer, required
    - `variants_count` integer, required
  - `message` object: severity, service and desc.

## Other responses

- `400`: offset or limit is outside its range, or filter_args is not valid JSON.
- `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)
