---
title: "How this variant's sales have moved when its price moved"
method: GET
path: "/api/v1/variants/{variant_id}/price-sensitivity"
tags: ["variants"]
---

# How this variant's sales have moved when its price moved

`GET /api/v1/variants/{variant_id}/price-sensitivity`

## Request

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

What past price changes did to this variant's sales velocity, as a tier with the evidence behind it.

`tier` is `HIGH`, `MODERATE`, `LOW`, `INCONSISTENT`, `STILL_LEARNING` or null. `confidence`, `n_events` (the qualifying price changes counted), `sign_agreement`, `shrunk_effect_up` and `shrunk_effect_down` (the effect of a rise and of a cut, as signed fractions) and `data_through` (the last event analysed) are the figures under it. `worth_considering` and `summary` are those figures written as sentences.

A variant with no classification yet answers every field null with `n_events: 0`. That is the honest answer, not an error, and not a tier of zero. An id no variant has answers the same shape rather than a refusal, so this read cannot tell you an id is wrong. Check it against a variant read.

`basis` and the fields beside it say why a tier is what it is: `periods_observed`, `price_variation` against `required_price_variation`, `expected_error`, and a `reference_elasticity` with its `reference_basis` and `reference_source` where the variant's own history is too thin. A `tier` of `STILL_LEARNING` with a `price_variation` well under `required_price_variation` means the price has not moved enough to measure, not that the reading is pending.

`engine` names the run behind the tier: `state` is `not_run`, `current`, `borrowed` or `insufficient`, the figure's state and never a run's, with `computed_at` (the run's, never your clock), `inputs_through`, `stale_after`, `basis` and `run_id`.

Scope: `products:read`.

## Path parameters

- `variant_id` string, required

## Headers

- `Tightly-Version` string

## Response `200`

The tier, the figures under it, and the sentences they make.

- object
  - `data` PriceSensitivityClassification
    - `basis` string, nullable
    - `confidence` string, nullable
    - `data_through` string, nullable
    - `engine` union
      - PriceEngineBlock
        - `basis` string, nullable
        - `computed_at` string, nullable
        - `confidence` string, nullable
        - `inputs_through` string, nullable
        - `name` string, required
        - `run_id` string, nullable
        - `stale_after` string, nullable
        - `state` string, required
      - object, nullable
    - `evidence` string, nullable
    - `expected_error` number, nullable
    - `n_events` integer, required
    - `periods_observed` integer, nullable
    - `price_variation` number, nullable
    - `reference_basis` string, nullable
    - `reference_elasticity` number, nullable
    - `reference_source` string, nullable
    - `required_price_variation` number, nullable
    - `shrunk_effect_down` number, nullable
    - `shrunk_effect_up` number, nullable
    - `sign_agreement` number, nullable
    - `summary` string, nullable
    - `tier` string, nullable
    - `worth_considering` string, nullable
  - `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.
- `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)