Retrieve experiment usage
How many DISTINCT visitors were first exposed to any experiment in the store within a window. It is the number that says whether the programme is reaching enough traffic for its verdicts to mean anything. NOT A BILLING FIGURE. Store visits are decoupled from pricing on every plan, so this caps nothing and charges nothing. No visitor id crosses the wire, here or anywhere on this family: the rows behind the count are keyed by a shopper’s device identity and only the count is published. The window is half-open and both ends are echoed, since the end is the server clock and two calls a minute apart would otherwise differ with nothing explaining why.
Authorizations
A secret API key. Publishable keys cannot reach this API. A key may carry an expiry, and an expired key is refused exactly like an unknown one, with a 401 that names no reason; check the key's expires_at in the dashboard rather than inferring it from a response. When a merchant rolls a key's secret they choose a grace window of up to 3 days, and for its duration BOTH the new secret and the one it replaced authenticate, so an integration moves over on its own deploy schedule instead of at the instant the button is pressed. Move before the window closes: after it, the old secret is refused. Nothing else about this contract moves with a roll. The key keeps its id and its scopes, so the only thing an integration updates is the credential itself.
Query Parameters
Start of the window, RFC3339. Defaults to a trailing thirty days, and a lookback longer than two years is clamped to two. A value that is not RFC3339 is a 400 rather than a fallback to the default, so a client with a malformed timestamp never reads a thirty-day figure as its own window. The response echoes both ends of the window actually used; the end is the server clock and cannot be set.
Response
Success