Use the right access for the job

Your MovePacket sign-in, a project builder connection and an athlete-data API credential have different purposes. Knowing a project or activity ID does not grant access.

Account and private project sign-in#

Customers sign in through MovePacket's managed account flow at Open MovePacket. Use that same account to open a private project you own; you do not need a second project password. An explicitly linked platform operator can use the same WorkOS sign-in to open the original master workspace. Operator access requires a separately provisioned identity assignment and current permissions; using the same email is not enough. The original Cloudflare-protected operator entry remains available for recovery.

Browser sessions make authenticated requests without exposing server API credentials. A private project currently admits its owner, not invited athletes or a whole coaching team. See Access & sharing.

Project builder connections#

Use Connect your builder to approve a connection for one hosted project. The helper stores its credential in private local configuration, outside the project folder. The connection expires after 30 days; creating a replacement invalidates the earlier connection.

The grant supports that project's source, saved updates, publication, private app records and analytics operations. It cannot change the project's audience, read another project, retrieve provider secrets or access the shared athlete library. Publication still needs the owner's instruction and review. See Builder reference for exact commands.

Private app records are server-side API resources. The static hosted page is not a safe place to put their credential. A generated frontend needs an authorised server-side path for private data; hosting alone does not supply arbitrary application server execution.

Athlete-data API credentials#

Authorised data workspaces use separately provisioned bearer credentials. Owner/admin workspace credentials allow the supported workspace data operations. Athlete-read grants permit supported read endpoints for the specified athlete, with server-side filtering; they do not enable import writes or Event Intelligence creation.

This is not a general self-service API-key or athlete-invitation interface. Customer signup and Core setup do not automatically enable data access. Ask MovePacket to confirm the supported grant for your integration.

Include the appropriate credential on every authenticated server API request, including original-file downloads:

curl --fail-with-body "$MOVEPACKET_API_URL/v1/activities" \
  -H "Authorization: Bearer $MOVEPACKET_API_KEY"

Keep keys in private server configuration or a secret manager. Never place them in frontend bundles, browser storage, query strings, logs, screenshots or prompts. Keys are checked against their stored hash and current access state. Missing, expired or revoked credentials cannot be used for ongoing access.

Workspace and athlete boundaries#

Requests are scoped to the current credential, workspace and applicable athlete or app grant. Access also depends on current membership, workspace state and privacy restrictions. An activity belonging to another workspace is not revealed by knowing its ID. Identical files in separate workspaces remain separate records.

Original activity files and decoded data require authentication. Preserve those boundaries in your own caching and download routes. Authentication does not establish athlete consent or verify that your application is using the information appropriately.

Your application's end-user permissions are a separate responsibility. Athlete-read grants do not create an athlete login portal. See Records & responsibility and Privacy operations.

Local development#

The local preview can bypass workspace sign-in only on a loopback hostname with the explicit preview setting. Bearer API requests still need valid local credentials. A hosted credential does not automatically grant access to a local database.

Athlete-centred Data Connect#

The app/server credential can now reach /v1/software/{app_id}/data-connect when the owner separately grants athlete/domain permissions. It does not automatically inherit workspace athlete access. Discover those permissions before reading or supplying records. Legacy workspace and athlete-read APIs keep their existing credentials; they are not accepted as app credentials. See Data Connect.

Workspace builder connections can also carry explicitly approved athlete-create and ride-import permissions. Neither is enabled on existing connections by default. Selected athlete identity access is separate from existing training-history access. Import endpoints accept only the connection's own manifests and originals for a currently selected athlete, under live owner, account, paid-workspace, expiry, revision and privacy checks. The signed-in Data → Import rides interface uses customer session endpoints, never operator /browser/* credentials.