---
title: "One variant's own timeline of changes, newest first"
method: GET
path: "/api/v1/variants/{variant_id}/events"
tags: ["variants"]
---

# One variant's own timeline of changes, newest first

`GET /api/v1/variants/{variant_id}/events`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/variants/{variant_id}/events`
- Auth: HTTP bearer

Every recorded change to one variant: `id`, `event_type`, `event_date`, `previous_value`, `new_value`, a typed `metadata` object, `location_id`, `created_at` and `created_by_user_id`. It carries no product or SKU fields, because they are the ones you name in the request.

`event_type` today is one of price_change, cost_change, stock_change, stockout, restock, status_change, supplier_change, lead_time_change, moq_change, velocity_shift, tag_change, managed_change, po_created, variant_created, variant_image_change, forecast_override (a planner edited the demand plan) and forecast_event_declared (a sales-velocity event was declared, changed or cancelled). The list is open, tolerate a type you do not know, and takes a comma-separated list.

`location_id` narrows stock events to one warehouse, matched against the per-location changes in `metadata`.

`start_date` and `end_date` bound the range as ISO dates; `end_date` defaults to today. Paging is `offset` and `limit`, limit at most 100 and 8 by default. Both counts come back: `total_count` is every event this variant has, `filtered_count` is how many the range and type filters matched, and the page is cut from `filtered_count`. The `offset` and `limit` actually used are echoed back.

For the same log across every variant, read the catalogue's events.

Scope: `products:read`.

## Path parameters

- `variant_id` string, required

## Query parameters

- `event_type` string
- `start_date` string, date
- `end_date` string, date
- `location_id` string
- `limit` integer
- `offset` integer

## Headers

- `Tightly-Version` string

## Response `200`

A page of this variant's changes, with both the total and the filtered count.

- object
  - `data` GetSKUEventsPayload
    - `events` SKUEventItem[], required
      - `created_at` string, nullable
      - `created_by_user_id` string, nullable
      - `event_date` string, required
      - `event_type` string, required
      - `id` string, required
      - `location_id` string, nullable
      - `metadata` object, required
      - `new_value` string, required
      - `previous_value` string, nullable
    - `filtered_count` integer, required
    - `limit` integer
    - `offset` integer
    - `total_count` integer, required
  - `message` object: severity, service and desc.

## Other responses

- `400`: A date could not be read, or offset or limit is outside its range.
- `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 variant 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)