If you’re building a fitness, training, or health app, one of your day-one jobs is inventing a data model: how a workout, a set, a superset, a planned session, an interval, a heart-rate stream are shaped. That work is expensive to get right, invisible to your users, and worth nothing competitively — and a hand-rolled v1 schema usually turns into a painful migration two years in.
You can skip it. OpenBody is an open, vendor-neutral data model you can adopt natively — not just as an export format at the boundary, but as the shape of your domain.
A curated, CC0 exercise database
Every fitness app needs an exercise database. The OpenBody registry ships 800+ canonical movements with structured facets (equipment, movement pattern, anatomy, laterality), progression / regression / variation relationships, and crosswalks from the names real apps use — CC0, no attribution required, versioned, and growing. This alone is worth adopting; the format rides in with it.
A data model that's already solved the hard parts
Supersets and drop sets, planned-versus-performed, %1RM and threshold-relative targets, AMRAP/EMOM scoring, continuous efforts, per-side work, sport outcomes, provenance and correction lifecycles — modeled once, specified precisely, stress-tested across everything from powerlifting to freediving to kabaddi. You inherit answers, not open questions.
Free import from ten formats
The Apache-2.0 reference library maps Hevy, Strong, Strava, Apple Health, Garmin FIT (from decoded messages), GPX, TCX, Fitbit, Concept2, and theCrag exports into OpenBody — see the full supported-formats matrix — resolves exercise names to canonical ids, and exports back out (Strong-format CSV, which Hevy also imports). “Bring your history from any app” becomes a launch feature you didn’t have to build.
Portability as a trust signal
Platforms are tightening data access, and the EU Data Act is pushing the other way. “Your data is portable, in an open format” is a real differentiator against incumbents whose lock-in users increasingly resent — and it costs you nothing when the format is your native shape.
OpenBody-shaped domain model. Keep whatever storage suits your queries (Postgres,
SQLite, Core Data) but make your domain types mirror the OpenBody model — Session,
Block, WorkUnit, Target, ExerciseRef — and speak OpenBody JSON at every boundary:
import, export, sync, and API. You get the modeling and interop wins without committing
your storage layer.
OpenBody documents as storage. For local-first and smaller apps, storing OpenBody records directly (JSON documents in SQLite, files, or a sync store) is genuinely viable: records are self-contained, immutable-plus-supersession by design (a natural fit for sync), and your “database export” is already the interchange format. The conformance vectors double as your test fixtures.
Either way, the rules that protect you as a consumer are simple: read what you understand, preserve what you don’t (unknown fields and tokens round-trip; nothing is dropped), and use namespaced extensions for anything app-specific — your private fields never collide with the core or with other apps.
