API Authentication

This authentication layer protects your B2B API usage perimeter.

Goal

Only authenticated server-side requests should be able to fetch WorkoutKit data and session payloads.

In practical terms, this protects the B2B client against unauthorized third-party use of its API access.

Unauthenticated requests are rejected and are not counted against your quota.

Model

Your backend issues a signed JWT and the WorkoutKit API layer validates that token before serving protected operations. The SDK itself does not validate this JWT. Your private key remains in your infrastructure.

This JWT layer is optional for some public read operations, but it is recommended for all production integrations. It is required for GraphQL queries and mutations that need an authenticated end-user context, typically through a sub claim.

JWT contract

WorkoutKit validates signatures with RSA or ECDSA public keys.

Supported signing algorithms:

• RSA: RS256, RS384, RS512
• ECDSA: ES256, ES384, ES512

Claim support:

• Required for operations that need an authenticated end-user context: sub
• Recommended but optional: exp
• Supported when needed: nbf
• No other JWT claim is required by WorkoutKit at the API layer

In practice, most production integrations should issue short-lived JWTs from the backend and include sub whenever requests are tied to a specific end user.

Example payload

{
  "sub": "550e8400-e29b-41d4-a716-446655440000",
  "exp": 1760000000,
  "nbf": 1759996400
}

sub is the only claim required by WorkoutKit for user-context operations. exp is strongly recommended so expired tokens are rejected automatically. nbf is less common but supported.

Public key formats and rotation

WorkoutKit supports two public-key distribution formats on the API side:

• JWKS recommended
• PEM Certificate

If you use JWKS, include a kid in your JWT header so the server can select the correct active key. JWKS is also the recommended way to handle key rotation and multiple active keys at the same time.

Public-key configuration is managed through the API settings provided to the B2B client, not inside the mobile SDK itself.

Environments, quotas, and SLA

Each B2B client receives a sandbox environment and a production environment. Both are hosted on the same technical infrastructure as FizzUp.

API endpoints are client-specific and are provided by the WorkoutKit team once the environments are provisioned.

Quota levels and SLA commitments depend on your contractual offer. Operational monitoring follows the same reliability standards used for the FizzUp consumer application.

Rate-limit values are not shared as a single public default in this documentation set. Treat the limits communicated in your contract as the source of truth for capacity planning, retry policy, and alerting.

Implementation notes

• Issue JWTs server-side only.
• Keep the private signing key in your infrastructure only.
• Rotate signing keys according to your security policy.
• Do not hardcode tokens in app bundles.
• Keep authorization logic and key material out of frontend/mobile code.