End-to-end flow

This page walks through the four steps a workout goes through at runtime — from authentication to SDK launch and completion. It ties together the two authentication contracts and the queries described elsewhere in this section. It is platform-agnostic; for platform specifics, see the iOS, Android, React Native, Flutter, or Web SDK guides.

At a glance

Step	Actor	Output
1. Issue the request JWT	Your backend	A signed JWT for API Authentication
2. Fetch the launch payload	Client	A workout session payload + a TrainingKitToken for SDK Authentication
3. Launch the workout	TrainingKit SDK	A running workout
4. Handle completion	Host app	Stored results, analytics, navigation

1. Backend issues the request JWT

Your backend receives the authenticated end-user context, mints a short-lived JWT signed with your private key, and returns it to the client through your secure channel. The client sends this JWT on its GraphQL requests, where the API layer validates it.

This is API Authentication. It is enabled and configured (public keys, JWKS/PEM) by the B2B client in the Admin Console. For the exact JWT contract — supported algorithms and claim requirements — see API Authentication.

2. Client fetches the launch payload

The client calls GetSessions to display the available workouts, then GetSessionContent with the selected workout id to retrieve the full session payload.

Two things travel with this request/response:

• The request carries the X-TrainingKit-Device header (the SDK device identifier).
• The response returns the session content and a TrainingKitToken (in the trainingKitToken field, the extensions.trainingkit.token, or the X-TrainingKit-Token header).

This is SDK Authentication — it binds the payload to a device/token handshake and is mandatory to launch a workout. See SDK Authentication. Keep the session payload and its TrainingKitToken in memory for an immediate launch.

Use the endpoint configured for your environment — sandbox and production endpoints are provisioned per B2B client by the TrainingKit team.

3. Launch the workout in the SDK

Hand the session payload, the TrainingKitToken, and any optional configuration to the TrainingKit SDK to start the workout. The inputs are the same on every platform; only the entry point differs (a workout controller, a fragment, or a bridge call) — see the per-platform SDK guides.

Time this step for just before launch: fetch the final session payload once the user has chosen their workout and is about to start. The TrainingKitToken is valid for one day, which is ample for a standard launch flow, and it must not be prefetched far in advance or reused across users (see SDK Authentication).

4. Handle completion

When the workout ends, the SDK notifies the host app through its completion listeners. Register these listeners before launching the workout so the host app can capture the first signal emitted by the native or web experience.

The lifecycle is the same across SDKs:

Signal	Meaning	Typical host-app action
Save	The workout finished and produced session state.	Persist the result to your backend, update progress, then continue navigation.
Quit	The user exited without completing and saving the workout.	Close the workout flow, restore host navigation, and optionally record abandonment.
Event	TrainingKit emitted a tracking event during the workout.	Forward the event name and properties to your analytics pipeline.

The platform entry points differ, but they map to this same contract: iOS controller overrides, Android host interface callbacks, React Native addWorkoutListener, Flutter workoutEvents(), and Web onWorkoutSave / onWorkoutQuit / onWorkoutEvent.

---

Contractual settings. Quota levels, rate limits, and SLA commitments depend on your contractual offer. Treat the values communicated during onboarding as the source of truth for production rollout.