The latest version of the Tracksuit API is now available. If you have an existing API integration created before July 27, 2026, we recommend planning your migration before November 1, 2026 .
The good news is that for most customers, migrating takes around 1â2 development days and doesn't require a new API key. The new API is included in your existing subscription at no additional cost and introduces new data, more flexible filtering, and a simpler, more consistent API structure. It's also where all future API capabilities and improvements will be released.
This guide explains why you should migrate, the migration timeline and how to make the switch. For a detailed breakdown of every request and endpoint change, see the companion article: API v1 to v2 endpoint mapping.
Why should I migrate?
Migrating to Tracksuit's latest API gives you access to more of your brand health data, more flexibility in how you analyse it, ensures you'll benefit from future improvements as they're released.
More brand health data, including Statements, Media Consumption, Category Profile, and Conversion.
More flexible analysis with cross-demographic filtering and custom rolling averages (1â12 months).
Benefit from future improvements, with future API capabilities continuing to roll out on the new API.
Ongoing support including maintenance, bug fixes and technical support.
The migration timeline
We recommend migrating before November 1, 2026, when API v1 enters no-maintenance.
Date | What it means for you |
July 27 - October 31 2026 |
|
From November 1, 2026 |
|
What happens if I don't migrate?
Your existing API integration won't stop working on 1 November 2026, but it will move to no-maintenance.
In practice, "no-maintenance" means:
No technical support will be provided for API v1.
No bug fixes or maintenance will be made if issues occur.
No new features or datasets will be added to API v1.
How to migrate
For most integrations this is a 1â2 day job. The data and concepts are the same: you're re-pointing and re-shaping requests, not rebuilding.
You don't need a new key. The same Authorization: Bearer YOUR_API_KEY header works against both versions. See How to authenticate the Tracksuit API.
Swap the base URL. v1 lives at
https://prod.beta.api.gotracksuit.com/v1; v2 lives athttps://prod.beta.api.gotracksuit.com/v2.Re-map your endpoints. Work through the API v1 to v2 endpoint mapping. Every v1 endpoint, what it becomes, and the request changes. The big shift: v1's integer
accountBrandIdbecomes a string category viewiddiscovered fromGET /category-views, and it moves into the path.Update each request. Rename
waveStartDate/waveEndDateâstart_period/end_period, translatedemographicFilterâfilters(omit it for the total population), and leavesmoothingoff to match v1's default 3-month rolling average.Add pagination handling. v2 is cursor-paginated. Loop on
next_tokenuntil it comes backnull. Build this in even if today's pulls fit on one page. See How to handle pagination.Adjust to the response changes. Sample size (
n=) and rawpopulationcounts aren't exposed in v2. Use the reliability indicator (Reliable / Directional / Insufficient) instead, and review the full list in What's changing in v2: breaking changes.Validate, then cut over. Pull the same period from v1 and v2 and compare. Small differences from weighting and rounding are expected. See Why your API numbers may differ from the dashboard. Once you're happy, switch production to v2 and retire the v1 calls.
đ Test before you write code. The interactive API documentation lets you paste in your key, run real v2 requests, copy code snippets, and download the OpenAPI spec.
Migration checklist
Audit every place your integration calls v1
Point requests at the
/v2base URL (same key)Re-map endpoints and parameters via the endpoint mapping
Replace
accountBrandIdwith the category viewidfromGET /category-viewsImplement the
next_tokenpagination loop (See How to handle pagination)Switch sample-quality logic to the reliability indicator
Validate v1 vs v2 for a known period
Cut production over to v2 and remove v1 calls
Done, well before 1 November 2026
