Bind or edit an existing client
First find the client through the company-scoped client resources. Use this operation to bind a client that is already linked to your company:clients:write. externalId must be a nonblank string of at most
200 characters without control characters; surrounding whitespace is trimmed.
The first binding requires revision: 1. Revisions must be JSON integers from
1 through 9007199254740991.
To edit the ID, send the same client path with a strictly greater revision and a
new idempotency key for that logical update:
externalId and revision replays successfully. A stale revision,
a different ID with the same revision, or an ID already bound to another client
returns 409. The binding’s client cannot be changed by this operation.
Editing replaces the old ID, so update your local register and stop retrying
creation or lookup with the old ID. This operation does not change app access,
modify the global client profile or take over a manually managed relationship.
Read and look up your reference
These reads requireclients:read:
data.externalReference, or null if your source
has no binding. Client detail and list items expose the same optional object:
externalId filter applies before counting and pagination and combines
with the existing email, search and status filters. Other integrations’ IDs never
appear in your output or match this filter. Company relationship visibility
continues to apply; a reference does not grant access to an unavailable client.
Durably deduplicate creation
Pass an optional stringexternalReference to the existing create resource.
Creation chooses initial revision 1; the explicit client binding operation uses
the {externalId, revision} object instead.
POST /public/v1/workout/exercisesPOST /public/v1/workout/clients/{clientId}/exercisesPOST /public/v1/workout/plansPOST /public/v1/workout/plans/create-and-assign/{clientId}
application/json only. Multipart requests
and uploaded files are rejected; use the ordinary media workflow separately.
The external reference does not relax exercise classification or programme
validation. See the API reference for complete programme, day, set, superset,
rest, tempo and calendar definitions.
The resource and reference commit in one MongoDB transaction. A failed mapping
cannot leave an orphan client, exercise or plan. Client mails, webhooks and default
measurement assignment start only after commit. An opted-in OAuth client also
persists the new relationship’s required external app-access policy inside that
transaction; see External client access.
An identical create request with the same external reference returns the same
resource, including after the HTTP idempotency record expires. Changed creation
content or reuse through a different endpoint or client path returns 409.
Object-key order does not matter; array order and supplied field values do.
A replay does not recreate assignments, reset workout performance or send another
invitation. Use the normal read endpoint when you need the resource’s current
profile or plan state after later edits.
Successful referenced creates add this receipt alongside the existing resource ID
in data:
Idempotency-Key. Keep the same key when retrying
one HTTP operation; after its retention window, the durable reference remains the
resource-level recovery mechanism. Keep your own step register for client,
exercise, plan, assignment and access-entitlement synchronization. Resource
creation alone does not confirm that app or client-AI access is effective.