Work with activities.

An activity connects the original FIT file, its processing status, and its decoded data. Keep the activity ID in your application as the reference for later reads.

Upload an original#

POST /v1/activities accepts application/vnd.ant.fit or application/octet-stream. Send raw binary bytes, up to 4 MiB. ZIP archives, JSON wrappers, and multipart forms are not supported.

The service checks the FIT signature, exact file length, and checksum before accepting an upload. Decoding happens asynchronously. A valid FIT file can still fail processing if it is not an activity or has no session message.

A SHA-256 match within the same workspace reuses the existing activity. This is content-based deduplication; no idempotency-key header is required. Concurrent identical uploads converge on one activity ID, so use that ID rather than the duplicate flag as the authoritative reference.

List and filter#

curl --fail-with-body \
  "$MOVEPACKET_API_URL/v1/activities?status=ready&limit=20&offset=0" \
  -H "Authorization: Bearer $MOVEPACKET_API_KEY"

Results are ordered by creation time descending, then ID descending. total counts matches; stats contains workspace-wide counts and original storage bytes, independent of the filters. New uploads can shift offset-based pages. Deduplicate by activity ID when collecting multiple pages.

Read an activity#

GET /v1/activities/{id} returns the current status, checksum, original byte size, creation time, error code, and retrieval links. Links are paths on the same API origin.

Download the original#

GET /v1/activities/{id}/original returns the exact uploaded bytes with a FIT content type and attachment filename. The original is available even when decoding fails. Verify the response against the activity's sha256 when integrity matters.

Retrieve decoded JSON#

GET /v1/activities/{id}/data returns the decoded data model only when the status is ready. Before that it returns 409; for a failed activity it returns 409 with the processing error code. Check status before requesting decoded data.

Inspect the source record#

Open a ready activity from Data. Source and parser details shows its record ID, parser, decoded schema and recording checksum, and Original file and Full decoded data download the preserved original and the decoded JSON. None of these add coaching interpretations. See records and responsibility.

Athlete library and ride views#

Data → Workspace data tools → All activities is the workspace-wide activity library. It lists individual FIT uploads and bulk-imported recordings together, 50 per page: activities needing review first, then the newest imports within each group. Open an athlete profile to see only that athlete's assigned files. Unassigned individual uploads remain visible in All activities. When the same FIT file is stored for one athlete through both paths, it appears as one row that lists each source; the originals are kept, not merged.

Open a ready ride for session date, active and elapsed time, distance, average power, and power/elevation/heart-rate charts where recorded. Each session retains its own summary. Legacy single-file uploads have their metrics loaded when you open the ride, rather than loading full files into every library row. Dates use explicitly labelled UTC until athlete timezone support is added. Blank values mean missing, not zero.

Charts are display-only samples of decoded records (about 1,000 points per channel). They preserve explicit missing-value gaps and gaps over 30 seconds; short sampling intervals are not resampled or interpolated into new measurements. Altitude uses SDK metres, preferring enhanced altitude. Download the original or full decoded data for complete evidence.

Private rider projects#

A rider dashboard is a saved, private view of one athlete's activity library; it uses no AI tokens. Creating rider dashboards, and connecting a project to an athlete this way, are not available in the customer workspace. To give a project access to an athlete's data, use App access on the athlete's page in Data; see Data Connect.

Live athlete data stays in the signed-in workspace. Generated previews and published project snapshots receive none of this connection's data. Native rider dashboards cannot be published. A custom application can read the connection server-side through the API using an existing authorised credential; no new credential is issued by connecting a project.

Protected reads

• GET /v1/library?athlete_id=ath_…&offset=0: combined activity rows, has_more, and unfinished import counts. The workspace-wide list can omit athlete_id. Athlete-scoped keys always see only their assigned athlete.
• GET /v1/project-data/{project-id}?offset=0: the same response limited to the project's connected athlete. Missing/disconnected/foreign projects return 404. An athlete-scoped key must match the connection.
• Each row's api_path leads to its protected metadata, /original, and /data endpoints. Authentication and workspace/athlete boundaries apply on every request.

Connecting a project does not confer access to its dataset on another user or an external builder. Keep credentials on an authorised application server and request only the athlete access the application needs.