---
title: "get sales velocity table"
method: GET
path: "/api/v1/sales/velocity/table"
tags: ["sales_velocity"]
---

# get sales velocity table

`GET /api/v1/sales/velocity/table`

## Request

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

A page of sales velocity per variant or product, the rate demand forecasting and days of cover are computed from: total demand and total sales for the window, the forecast model chosen for the row, whether it is seasonal, price, channel, supplier, bundle count and a confidence tier, with `confidence_tier_counts` for the filtered book.

`type=variants` is the default and `type=products` aggregates. Page with `limit` and `offset`, narrow with `filter_args` on location_id, sales_velocity_30_days, modified_status, variant_id, product_id, supplier_id, event_id, shopify_tags, sales_channel_id and season_id, and order with `sort_args` over variant_title, product_title, sales_velocity_30_days, sales_velocity_30_days_incl_bundles, current, next and next_2. `start_date` and `end_date` set the window and must be sent together. `export=true` answers a download URL.

`data_source` says which store served the read, `ch` for the analytics mirror and `pg` for PostgreSQL, and `demand_as_of` is when the demand figures were last computed. An `export=true` response carries `data_source` too: the export dispatches to the same two stores and falls back the same way.

`row_grain` says what grain the rows in the response are, `variants` or `products`. It is a property of the envelope, not an echo of the `type` you sent, so a client can check the answer against its own request rather than inferring the grain from which counter it can find.

Scope: `sales:read`.

## Query parameters

- `include_stock_availability` boolean
- `limit` integer
- `offset` integer
- `filter_args` string
- `sort_args` string
- `search` string
- `export` boolean
- `start_date` string, date
- `end_date` string, date
- `type` 'variants' | 'products'
- `demand_sales_columns` string

## Headers

- `Tightly-Version` string

## Response `200`

The sales velocity table, or an export url

- object
  - `data` object: A page of velocity rows with `offset`, `size`, `filtered_max_size`, `data_source` (`ch` or `pg`) and `row_grain` (`variants` or `products`), or, with `export=true`, a single download `url` and the same `data_source`.
  - `message` object: severity, service and desc.

## Other responses

- `400`: Bad Request - Invalid request parameters or validation errors
- `401`: No usable key: malformed, unknown, revoked, expired or stopped. One refusal covers all five, telling a caller which is which maps the surface for them. A request with no Authorization header at all is refused 400 before any key is looked for.
- `403`: The key may not reach this operation. `scope_missing` when the key does not hold Sales; `organization_mismatch` when the path names an organisation that is not the key's; `ip_not_allowed` when the caller's address is outside the key's allowlist.
- `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.
- `500`: Internal Server Error - Database connection or processing errors
- `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)