How we verify what we publish
Last updated 2026-07-31
Most technical content about fitness APIs is written from memory and other people’s blog posts. Ours is not, and this page explains the actual process — including what it catches and where its limits are.
Primary sources, fetched at write time
Factual claims — API behavior, deprecation dates, permission names, data-type semantics — come from vendor documentation fetched during research for that specific page, not recalled from training data or copied from secondary coverage. Where a page states something load-bearing, it says who documents it: “Apple documents…”, “Google documents…”, “RFC 6585 says…”.
“We could not verify this” is a valid answer
When a primary source is unreachable or silent, we say so rather than filling the gap with a plausible guess. That is why you will find tables on this site with rows marked “could not verify”, pages stating that a rate limit is undocumented, and exactly zero invented statistics. A narrow page you can trust beats a complete-looking one you cannot.
Folklore gets checked, not repeated
Widely repeated developer claims are tested against the primary source before they appear here — and several well-known “facts” failed that test and are corrected on the relevant pages. Where a belief is common but unsourced, we label it as folklore rather than asserting either direction.
Adversarial review before publishing
Every content cluster is reviewed by adversarial passes whose explicit job is to find fabricated claims, unsourced numbers, internal contradictions, and broken code samples — including executing SQL and checking every API identifier against the sources. Reviews have rejected and corrected our own drafts many times; that is the point of them.
Automated gates on every build
Before any change ships, an automated gate checks every page for broken internal links, metadata problems, duplicate questions answered in two places, and malformed structured data. The gate has rejected our own work repeatedly. It is not allowed to be weakened to make a change pass. Every one of those refusals is published, with what it refuses to ship, at the gates.
Judgement is labelled as judgement
Engineering recommendations — which architecture to pick, what to test first, when to buy instead of build — are opinions, and the pages say “our recommendation” or “in our experience” when giving them. We do not dress opinion up as documentation, and we do not cite studies that do not exist.
Dates on volatile claims
Pricing, rate limits, library versions and platform policies change. Pages carry a last-reviewed date, volatile specifics are hedged with “as of” dates, and we tell you to verify against the provider’s current documentation before committing — because by the time you read a page, the vendor may have moved.
What a verification stamp does not tell you
As of September 1, 2026, a stamp moves only when someone reopens the primary source and confirms the page still matches it; no maintenance script touches dates, and a claim that cannot be reconfirmed is cut or hedged rather than left under an old date. Re-checks are scheduled by stamp age, oldest first, because choosing by what comes to mind leaves the quiet pages to rot. Pages show how long ago they were checked and flag anything past 90 days, a threshold that is our judgement about tolerable staleness, not a finding.
A stamp says a person read a source on a date. It does not say the fact is still true: a vendor can change a page the day after we read it, and nothing in this process would know until the next check. The build asserts that published citation anchors resolve, which proves a link is not dead, not that the page behind it still says what we said it said, and a generated dataset that parses fewer rows than it declares fails the build. Treat an old stamp on a commercial term with more suspicion than an old stamp on an API surface, because pricing and access are what vendors change without announcing.
Who pays for this, and independence
AIFitnessAPI is run by the team behind KinesteX, an AI motion-tracking SDK. That funds the site. It does not buy conclusions: comparisons include competitors, our build-vs-buy pages regularly recommend building or buying from others, and no vendor — including KinesteX — edits our copy. Where a topic touches camera-based motion tracking, you should know that context and weigh it; that is why it is stated here rather than discovered later.
Corrections
Found something wrong? Email nikita@kinestex.com. Verified corrections ship with the same priority as new content, and material ones are noted on the page they fix.