KinesteX

Migrating from the Legacy API

The legacy Content API (https://admin.kinestex.com/api/v1/) and the SDK convenience methods built on it still work. New integrations should use the endpoints on this page.


What moves


LegacyUpdated
https://admin.kinestex.com/api/v1/https://data.kinestex.com/api/
x-api-key + x-company-name headersx-api-key alone (the key identifies the company)
/workouts, /plans, /exercises/workouts/client, /plans/client, /exercises/client
lastDocId cursor paginglimit + offset with a full pagination block
Client-side filteringsearch, body_parts, categories, difficulty_level, level, translation_languages
Firestore document IDsNumeric IDs (legacy 20-character Firestore IDs still resolve)

Response shape differences to expect


  • Lists are keyed exercises, workouts, and data (plans), each alongside pagination.
  • Workout and plan list titles live under translation.title, not at the root.
  • total_time on workouts is in seconds; total_minutes is the minutes value and appears on the detail endpoints.
  • Exercise id is a number in list responses and a string in single-item responses. Plan id behaves the same way.
  • created_by is reduced to { "id": ... } and internal fields (firestore_id, created_by_id, ai_model_id, full AI-model configuration) are stripped from every /client response.

A safe migration order


1. Point your list screens at the new endpoints and drive paging from pagination.

2. Replace client-side filtering with the query parameters, and delete the "fetch everything" code path.

3. Switch detail screens to /{id}, passing the numeric ID you now get from the list.

4. Move localization to the Language header plus ?lang=, and drop any hard-coded language handling.


If you are still on the SDK convenience methods (fetchWorkouts(), fetchPlans(), fetchExercises()), keep using them: they are supported, and the legacy page documents them in full. Reach out to KinesteX when you want the SDK helpers pointed at these endpoints.