Skip to main content
Open Standard

One Standard for Fitness Data

Enable seamless data portability across fitness applications. Stop reverse-engineering every platform's data format.

For App DevelopersPlatform BuildersData Engineers
View SpecificationSee the Problem

The Fragmentation Problem

Every fitness platform speaks a different language

App Aexercise_id: "squat_01"
App BexerciseId: 42
App Ceid: "BS"
App DExercise_Ref: "001"

User Lock-in

Switch apps, lose everything. Years of PRs, workout history, and progress vanish. Data hostage in proprietary formats.

Developer Overhead

Building from scratch or adding integrations? Either way, you're defining exercise models alone. No shared vocabulary to build on.

Ecosystem Fragmentation

Apps cannot interoperate. The same exercise has different IDs, names, and structures everywhere.

User Lock-inDeveloper OverheadEcosystem Fragmentation

See the Difference

The same exercise, "Back Squat", represented across different platforms

FitApp Prosnake_case, flat structure
{
  "exercise_id": "ex_12847",
  "exercise_name": "back_squat",
  "muscle_groups": "quads,glutes,hamstrings",
  "equipment_list": "barbell,rack",
  "difficulty": 3,
  "is_compound": true,
  "created_date": "09/02/2025"
}
→FDS
FDS FormatStandardized structure
{
  "schemaVersion": "1.0.0",
  "exerciseId": "550e8400-e29b-41d4-a716-446655440000",
  "canonical": {
    "name": "Back Squat",
    "slug": "back-squat",
    "description": "A compound lower body exercise..."
  },
  "classification": {
    "exerciseType": "strength",
    "movement": "squat",
    "mechanics": "compound",
    "level": "intermediate"
  },
  "targets": {
    "primary": [
      {
        "id": "mus.quadriceps",
        "name": "Quadriceps"
      }
    ],
    "secondary": [
      {
        "id": "mus.hamstrings",
        "name": "Hamstrings"
      },
      {
        "id": "mus.erectorSpinae",
        "name": "Erector Spinae"
      }
    ]
  },
  "equipment": {
    "required": [
      {
        "id": "eq.barbell",
        "name": "Barbell"
      },
      {
        "id": "eq.rack",
        "name": "Power Rack"
      }
    ]
  },
  "metadata": {
    "createdAt": "2025-09-02T15:00:00Z",
    "updatedAt": "2025-09-02T15:00:00Z",
    "status": "active"
  }
}

Why FDS?

Real scenarios where a common standard makes the difference

User Data Portability

User wants to switch fitness apps

Without FDS

Years of workout history lost. Manual re-entry or data trapped forever.

With FDS

Export once, import anywhere. Complete history travels with the user.

Developer Efficiency

Building a new fitness app or adding integrations

Without FDS

Reverse-engineer each platform. Maintain N different parsers and mappers.

With FDS

Build to one standard. Instant compatibility with all FDS-compliant platforms.

Platform Growth

Acquiring users from competing platforms

Without FDS

High switching friction. Users reluctant to lose their data.

With FDS

Seamless migration path. Lower barrier to user adoption.

Data Aggregation

Combining data from multiple fitness sources

Without FDS

Write N different parsers. Constant maintenance as formats change.

With FDS

Single normalized format. Consistent data structure across all sources.

How FDS Works

One standard replaces countless point-to-point integrations

FitApp Pro
GymTracker
WorkoutDB
IronLog
FDSCommon Language
Without FDSN × (N-1) integrations4 apps = 12 integrations
With FDSN integrations4 apps = 4 integrations

Each platform writes one exporter and one importer. FDS handles the translation, so you integrate once and connect to everyone.

No forced architecture changes
Validated data exchange
Works with any tech stack
Coming Soon

Schema Transformer & Validation

Automated mapping from your existing schema to FDS format. Optional AI assistance fills gaps when source data fields are missing.

Built-in Extensibility

Add custom fields without breaking compatibility

Vendor Namespaces

Prefix custom fields with x:yourapp. to add platform-specific data that travels with the standard.

Safe Extensions

Other platforms ignore unknown namespaces. Your custom data never breaks their imports.

Round-trip Preservation

Extensions survive export → import cycles. Data you add comes back intact.

Quick Start

No SDK required. Start with the JSON Schema.

1

Get the Schema

Download the JSON Schema to validate your exercise data.

View Exercise Schema →
2

Model Your Data

Structure your exercise data using the FDS format. Start minimal, expand as needed.

3

Validate

Use any JSON Schema validator (ajv, jsonschema, etc.) to ensure compliance.

Validation Guide →
Minimal Valid Exercise
{
  "schemaVersion": "1.0.0",
  "exerciseId": "550e8400-e29b-41d4-a716-446655440000",
  "canonical": {
    "name": "Back Squat",
    "slug": "back-squat"
  },
  "classification": {
    "exerciseType": "strength",
    "movement": "squat",
    "mechanics": "compound",
    "force": "push",
    "level": "intermediate"
  },
  "targets": {
    "primary": [
      { "id": "mus.quadriceps", "name": "Quadriceps", "categoryId": "cat.legs" }
    ]
  },
  "metrics": {
    "primary": { "type": "reps", "unit": "count" }
  },
  "metadata": {
    "createdAt": "2025-09-02T15:00:00Z",
    "updatedAt": "2025-09-02T15:00:00Z",
    "status": "active"
  }
}

What's in the Standard

Everything you need to build interoperable fitness applications

Exercise Data Model

Comprehensive exercise definitions with classification, muscle targets, equipment, and media assets. RFC-001 defines the core structure.

Learn more →

Registry Entities

Standardized equipment, muscle, and body atlas models. Shared taxonomies for consistent data exchange across platforms.

Learn more →

Extensibility

Platform-specific extensions without breaking compatibility. Vendor namespaces and attribute system for custom data.

Learn more →

JSON Schema

Draft 2020-12 schemas with validation rules and examples. Programmatic validation for all entity types.

Learn more →

Internationalization

Multilingual support with BCP 47 language tags. Localized names, descriptions, and aliases for global accessibility.

Learn more →

Open Governance

Community-driven RFC process with transparent decision-making. Contribute improvements and propose new features.

Learn more →

Ready to integrate FDS?

Start building interoperable fitness applications with standardized data models.

View DocumentationGitHub Repository

Start with exercise data today. Workout templates, progress tracking, and more planned in future RFCs.

We're seeking early adopters to shape the standard. Implement FDS, share feedback, and help build the foundation for fitness data interoperability.

Become an Early Adopter →