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.
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.