sales_velocity

get variant bundle contributions

How much of one variant's demand comes from each bundle that contains it, over a window: one entry per bundle with the bundle's product and variant titles and its contribution, plus total_count and total_demand.

variant_id is in the path; sales_channel_id, start_date and end_date are all required. It uses the same effective-demand figures as get_sales_velocity_table. At most 20 bundles come back, largest contribution first, and where there are more the last entry is an Others row summing the rest.

data_source says which store served the read, ch for the analytics mirror and pg for PostgreSQL, exactly as on get_sales_velocity_table. The figures are the same either way; the field is there because a fallback to PostgreSQL is otherwise invisible.

Scope: sales:read.

get/api/v1/sales/velocity/variants/{variant_id}/bundle-contributions

Request

  • Base URL: https://api.app.tightly.io
  • URL: https://api.app.tightly.io/api/v1/sales/velocity/variants/{variant_id}/bundle-contributions
  • Auth: HTTP bearer

Path parameters

variant_idstring required

The component variant whose bundle contributions are requested.

Query parameters

sales_channel_idstring required

Sales channel to scope the demand data to.

start_datestring date required
Example:2026-04-24

Start of the date range (inclusive).

end_datestring date required
Example:2026-10-24

End of the date range (inclusive).

Headers

Tightly-Versionstring
Example:2026-11

The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.

Response

Bundle demand contributions for the variant

dataobject
messageobject

severity, service and desc.

Changes

No recorded changes to this operation across all 1 revision of this API.