If you're migrating an existing Tracksuit API integration, this page is your translation table. It maps every API v1 endpoint to its API v2 equivalent and explains the request changes you'll need to make.
If you're building a fresh integration instead, start from the Tracksuit API endpoint reference and the Quick-start guide.
👉 Your existing v1 key already works on v2. You don't need to generate a new token to migrate — the same Authorization: Bearer YOUR_API_KEY header works against both. See How to authenticate the Tracksuit API.
👉You can try every v2 endpoint live — paste in your key, set parameters and run real requests — in our interactive API documentation, which also generates code snippets and lets you download the OpenAPI spec.
The one concept that changes everything
v1 was organized around the account brand: a brand you have access to, identified by an integer accountBrandId.
v2 is organized around the category view: the same idea (one brand and its competitors tracked within a specific category and geography), but identified by a string id, and it sits at the front of almost every path.
So where v1 passed accountBrandId as a query parameter or a path segment in different places, v2 is consistent: discover your views with GET /category-views, then hang every other call off that id . GET /category-views/{id}/funnel, /statements, and so on.
Base URL also changes. v1 lives at https://prod.beta.api.gotracksuit.com/v1; v2 lives at https://prod.beta.api.gotracksuit.com/v2.
Endpoint mapping
v1 endpoint | v2 endpoint | What's happening |
|
| Renamed. Returns category views (string |
|
| The funnel metrics pull. Same metrics, restructured request. |
|
| No bulk endpoint. To reproduce "all demographics at once", call funnel once per demographic filter combination (values from metadata). |
|
| Available demographics and metrics now come from the metadata endpoint. |
| (no direct equivalent yet) | Category penetration is not a v2 endpoint. |
| Docs are now hosted, not served by the API itself. |
New in v2. No v1 equivalent
These are brand-new capabilities. There's nothing to migrate; reach for them when you're ready to do more than v1 allowed.
v2 endpoint | What it gives you |
| Conversion rates between funnel stages, e.g. how many of those aware of you go on to consider you. |
| Brand imagery statement performance, the associations people link to your brand. |
| Which channels your category's audience consumes content on. |
| The demographic make-up behind a chosen metric. |
What changes in every request
These apply across the board. Read them once, then the per-endpoint notes are short.
v1 | v2 | Why / what to do |
|
| Get it from |
|
| Still first-of-month dates that map to survey waves. Inclusive range. |
|
| Stringified JSON of |
(always 3-month rolling) |
| v1 always returned a 3-month rolling average (the same methodology as the dashboard), with no way to change it. |
(whole result in one response) |
| v2 is cursor-paginated. Loop until |
| reliability indicator ( | Renamed and re-bucketed. v2 also adds a |
| (not exposed) | The raw sample size (n=) is not returned in v2. Use the reliability indicator to judge a data point instead. See Why your API numbers may differ from the dashboard. |
New optional parameters on the metric endpoints: brand_ids (restrict to specific brands from metadata) and metrics (restrict to specific funnel stages, e.g. ["PROMPTED_AWARENESS","CONSIDERATION"]). Both default to "everything" if omitted, so existing v1-style pulls keep working.
Per-endpoint migration notes
1. account-brands → category-views.
Same job: list what your key can see. However, each item is a category view with a string id, plus name, category and geography. Cache those IDs; every other call needs one. Remember to page through the results.
2. funnel and bulk/funnel → category-views/{id}/funnel.
Move accountBrandId into the path, rename the date parameters, and translate demographicFilter → filters. v2 defaults to a 3mo rolling average which is the same smoothing v1 always applied so leaving smoothing off reproduces v1's series; set it only if you want a different window.
There's no "all demographics in one call" any more: omitting filters returns the total only, and a filters list is combined into a single slice. To reproduce what bulk/funnel gave you, call this endpoint once per demographic filter combination — pull the dimensions and values from the metadata endpoint first. (Pagination only chunks a single result set; it doesn't iterate demographics for you.)
3. funnel/filters → category-views/{id} (metadata).
The list of available demographics now comes from the metadata endpoint, which also returns the metrics, brands and channels for that view. Call it once up front to discover what you can filter and request.
4. category-metrics/{accountBrandId} → none (yet).
v1's category penetration has no direct v2 endpoint today. Confirm with the API team before relying on it.
5. api-docs → hosted docs.
The interactive reference is no longer served from the API. Use the interactive API documentation.
A worked example
A v1 funnel pull for account brand 10296, total population, first half of 2025:
GET <https://prod.beta.api.gotracksuit.com/v1/funnel?accountBrandId=10296&demographicFilter=["TOTAL"]&waveStartDate=2025-01-01&waveEndDate=2025-06-01>
The same pull in v2 (assuming the category view's id is 10296):
GET <https://prod.beta.api.gotracksuit.com/v2/category-views/10296/funnel?start_period=2025-01-01&end_period=2025-06-01>
No demographicFilter (omitted = total) and dates renamed. smoothing is left off because v2's default 3mo already matches the rolling average v1 returned. Then follow next_token until it's null.