# MovePacket documentation
Private beta contract. Check https://movepacket.com/site-status.json for hosted API availability.
Source: https://movepacket.com/docs
# Build around your athletes’ data.
The hardest part of custom coaching software is getting reliable access to the athletes you coach. MovePacket is building the connections and dependable records underneath that software.
Start today with an authorised original FIT file. The private beta preserves it, tracks processing and returns decoded data through an authenticated API. Automatic athlete connections are the next priority.
01 Original FIT→02 MovePacket→03 Your app
## Infrastructure for your expertise
MovePacket serves independent endurance coaches and small coaching businesses first. The underlying product stays sport-agnostic: ingest, store, structure, permission, transform and deliver. Your application supplies the coaching or performance judgment.
Connectivity comes before the breadth of tools built on top. Athlete identity and authorisation, supported historical imports, new-activity delivery and visible connection health are the next priorities. [See the current routes and roadmap](/docs/connections).
## A small API with a clear job
MovePacket accepts a FIT activity, validates the file, and queues it for decoding. Your app receives an activity ID immediately and can check back until the data is ready. Every activity has a preserved original, a SHA-256 checksum, and a processing status.
The beta exposes decoded Garmin FIT messages. It does not yet normalize data across providers or add coaching interpretation. See the [data model](/docs/data-model) for the exact response shape.
## Choose your starting point
| You want to… | Start here |
| --- | --- |
| Try a file without writing code | [Private workspace](/upload) |
| Understand how to get athlete data | [Athlete connections](/docs/connections) |
| Inspect provenance and verify an original | [Records & responsibility](/docs/records) |
| Connect your application | [Quickstart](/docs/quickstart) |
| Keep keys and activity data private | [Authentication](/docs/authentication) |
| Handle processing, retries, and duplicates | [Processing and reliability](/docs/processing) |
| Give an AI coding assistant the contract | [Build with AI](/docs/ai-tools) |
## What the beta supports
| Capability | Status |
| --- | --- |
| FIT upload, validation, and decoding | Implemented; requires an enabled beta environment |
| Original file and decoded JSON retrieval | Implemented; authenticated access |
| Activity search, status filters, and pagination | Implemented |
| Browser workspace | Implemented; invited access |
| Original integrity verification and record metadata export | Implemented in the workspace Record tab |
| Athlete invitations and athlete-level app grants | Planned |
| Automatic device connections and historical sync | Planned |
| Outbound webhooks and delivery history | Planned; use status polling today |
| MovePacket MCP server and packaged SDKs | Planned |
| Public signup and self-service API keys | Planned |
These guides describe the current beta contract. Follow the availability notice above before sending files to a hosted environment.
---
Source: https://movepacket.com/docs/quickstart
# Your first activity.
Go from an original FIT file to decoded JSON and a verified copy of the source. This example runs on your computer or server with Node.js 22 or later. No packages are required.
## Before you begin
You need access to an enabled MovePacket beta environment, an API key for that environment, and a FIT activity file no larger than 4 MiB. Keep the key in your secret manager or server environment as `MOVEPACKET_API_KEY`. Never put it in browser code or a URL.
For a test without personal data, [download the synthetic sample ride](/sample.fit). It contains generated cycling data, not a real athlete's ride.
## Run the complete example
[Download movepacket-quickstart.mjs](/examples/movepacket-quickstart.mjs) and save it beside your FIT file. Set the API origin supplied with your beta access. For the local development preview, use `http://127.0.0.1:8787`.
```sh
export MOVEPACKET_API_URL="https://movepacket.com"
# Supply MOVEPACKET_API_KEY through your secret manager or environment.
node movepacket-quickstart.mjs ride.fit ./ride-data
```
Choose an output directory that does not already exist. The example uploads the file, polls for completion, downloads the decoded data and original, and compares the original's SHA-256 against both your input and the API checksum. It saves `activity.json` and `original.fit` only after verification.
If processing takes more than two minutes, the example returns the activity ID so you can check it again. A local timeout does not cancel processing. Transient request failures are retried up to three attempts. Re-uploading identical bytes within the same workspace reuses the activity.
## Upload the file
You can also follow the flow one request at a time. Send the raw file body, not a multipart form or JSON wrapper.
```sh
curl --fail-with-body "$MOVEPACKET_API_URL/v1/activities" \
-H "Authorization: Bearer $MOVEPACKET_API_KEY" \
-H "Content-Type: application/vnd.ant.fit" \
--data-binary @ride.fit
```
An accepted upload normally returns HTTP `202`. Save its `id`. Responses include links to the status, original, and decoded data. The IDs and checksum below are illustrative.
```json
{
"id": "act_00000000-0000-4000-8000-000000000001",
"status": "queued",
"sha256": "0000000000000000000000000000000000000000000000000000000000000000",
"byte_size": 25000,
"error_code": null,
"created_at": "2026-09-16T12:00:00.000Z",
"duplicate": false,
"links": {
"self": "/v1/activities/act_00000000-0000-4000-8000-000000000001",
"original": "/v1/activities/act_00000000-0000-4000-8000-000000000001/original",
"data": "/v1/activities/act_00000000-0000-4000-8000-000000000001/data"
}
}
```
## Wait for ready
Use the returned ID as `ACTIVITY_ID`. Poll this endpoint every few seconds until `status` is `ready` or `failed`.
```sh
curl --fail-with-body "$MOVEPACKET_API_URL/v1/activities/$ACTIVITY_ID" \
-H "Authorization: Bearer $MOVEPACKET_API_KEY"
```
A successful status request returns HTTP `200` even while processing continues. The `status` field determines whether the decoded data is ready. A failed activity includes an `error_code`; its original remains retrievable.
## Retrieve the result
```sh
curl --fail-with-body "$MOVEPACKET_API_URL/v1/activities/$ACTIVITY_ID/data" \
-H "Authorization: Bearer $MOVEPACKET_API_KEY" \
--output activity.json
curl --fail-with-body "$MOVEPACKET_API_URL/v1/activities/$ACTIVITY_ID/original" \
-H "Authorization: Bearer $MOVEPACKET_API_KEY" \
--output original.fit
```
The complete Node.js example verifies file integrity automatically. For your own integration, compare the downloaded original's SHA-256 with the upload response and your source file. Continue with [processing and reliability](/docs/processing) and the [data model](/docs/data-model).
---
Source: https://movepacket.com/docs/authentication
# Keep access private.
Your server uses a bearer API key. The MovePacket workspace uses browser sign-in. Both grant access to a workspace's activities; an activity ID alone grants no access.
Workspace authentication does not establish athlete consent or athlete-level permission. Athlete invitations, coach–athlete relationships and scoped app grants are planned. See [athlete connections](/docs/connections) and [shared responsibility](/docs/records#shared-responsibility).
## Server requests
Include an `Authorization` header on every `/v1/` request, including downloads.
```sh
curl --fail-with-body "$MOVEPACKET_API_URL/v1/activities" \
-H "Authorization: Bearer $MOVEPACKET_API_KEY"
```
Store the key in a secret manager or server environment. Do not put it in frontend bundles, browser storage, query strings, logs, or screenshots. MovePacket stores a hash of the key for verification. A missing, unknown, or revoked key returns `401`.
Beta keys are provisioned individually. Self-service creation, scopes, rotation controls, and team invitations are not available in the dashboard yet. A key currently authorizes all implemented activity operations in its workspace.
## Browser sign-in
Invited users sign into the MovePacket workspace using an email code. The workspace makes same-origin authenticated requests without asking for an API key. This browser session is separate from the server API.
For your own frontend, route API calls through your backend and enforce your application's user permissions there. The beta does not provide public cross-origin browser uploads or a temporary upload URL API.
## Workspace boundaries
Lists and activity lookups are scoped to the key's workspace. An activity belonging to another workspace returns `404`, the same as an unknown ID. Uploading identical bytes in different workspaces creates separate activities.
Original files and decoded JSON require authentication. There are no public file URLs. Preserve these boundaries when caching data or proxying downloads through your own application.
## Local development
The local preview can bypass workspace sign-in only on a loopback hostname with the explicit preview setting. Bearer API requests still require a valid key in the local database. A hosted beta key is not automatically a local key.
---
Source: https://movepacket.com/docs/connections
# Start with your athletes’ data.
MovePacket is being built for independent coaches and small coaching businesses that want reliable access to the data of the athletes they actually coach. The goal is athlete-authorised connections, supported history and dependable delivery of new activities.
**The private beta starts with original FIT uploads.** It does not yet connect provider accounts, invite athletes, import a coaching roster or synchronise activity history.
## Bring an activity today
1. Obtain an original FIT activity file through an export you are authorised to use. Available exports depend on the device or platform.
2. Upload it in your invited [workspace](/upload) or through the [API quickstart](/docs/quickstart).
3. Follow its processing status, then retrieve the decoded data and unchanged original.
4. Open the activity’s **Record** tab to inspect intake and decoder details, verify the original’s checksum, or export the current record metadata.
Only supported FIT activity files are accepted, up to 4 MiB each. A source brand being listed on the website does not mean its account is connected or that every export it produces is supported. See [activity limits](/docs/activities).
Upload only files you have permission to process. The current beta isolates workspaces but does not assign activities to verified athlete identities or enforce per-athlete access. Keep athlete mapping and end-user permissions in your own application until those capabilities are available.
## Existing coaching platforms
You can test MovePacket with an authorised original FIT export while retaining your existing coaching workflow. There is no TrainingPeaks account connection, coaching-roster import or historical sync in this release.
Do not share athlete passwords or use a coaching relationship as a substitute for permission to access another service. Any future platform adapter will require an authorised integration route. MovePacket is being designed to support multiple intake routes rather than depend on one coaching platform.
## The connection experience we are building toward
| Step | Required outcome | Current status |
| --- | --- | --- |
| Link an athlete | Verify the athlete identity and the coaching relationship | Planned |
| Authorise a source | Athlete sees and grants the access being requested | Planned |
| Bring history | Import what the source supports; report coverage and gaps | Planned |
| Receive new activities | Track delivery, retry failures and surface reconnect needs | Planned |
| Preserve the record | Keep originals, identifiers, provenance and processing details | Original FIT, checksum, receipt time, status and decoder metadata available; richer provenance planned |
| Control access | Scope app permissions, revoke access and support retention/deletion | Workspace authentication available; athlete/app grants and self-service controls planned |
Garmin, Wahoo, Karoo and COROS are initial candidate sources. Supported routes, historical coverage and launch order depend on authorised provider access and pilot needs. No launch date or universal compatibility is promised.
## What a healthy connection should show
A future connection should make the athlete and source clear, show when data last arrived, distinguish imported history from ongoing sync, and report missing periods or required action. A connected badge alone is not enough.
The beta’s activity status describes processing of an uploaded file. It is not a device-sync or source-freshness indicator.
---
Source: https://movepacket.com/docs/records
# A record you can trace back to.
MovePacket is being built as a dependable system of record for athlete data. The first foundation is an original file that stays unchanged, a stable activity ID, and inspectable processing details.
A system of record preserves evidence and its history. It does not certify that every sensor measurement is accurate or that an application’s interpretation is correct.
## What the beta records
| Evidence | Available today |
| --- | --- |
| Original | Exact uploaded FIT bytes, authenticated download |
| Integrity | SHA-256 checksum and original byte size |
| Receipt | Activity creation time after storage accepts the original |
| Processing | Current status and an error code when processing fails |
| Derived data | Decoded JSON, wrapper schema version, decoder package/version and FIT profile when ready |
| Access boundary | Workspace-scoped API and browser access |
| Portability | Original FIT, decoded JSON and record metadata export |
Identical bytes uploaded within one workspace reuse the activity ID. This does not identify two different files as the same real-world session. Cross-source duplicate reconciliation is planned.
## Inspect and verify a record
Open an activity in your workspace and choose **Record**. This view is available even if decoding has failed or is still processing.
**Verify original** reads the preserved FIT and compares its SHA-256 checksum and byte size with the activity metadata. A match confirms that the retrieved bytes match the stored record. It does not verify device calibration, athlete identity, consent or coaching conclusions.
**Export record details** downloads a JSON snapshot containing the activity ID, intake route, receipt time, original checksum/size, current processing state, available parser metadata and retrieval links. It contains no API keys. It is current metadata, not an access audit or full transformation history.
Download the original and decoded JSON separately when moving the activity into another system. The [quickstart](/docs/quickstart) also demonstrates checksum verification from your server.
## Where the record stops today
The beta does not record a provider account connection, verified athlete identity, athlete consent, delegated app grants, access history or a complete sequence of reprocessing versions. Missing links are shown as unavailable rather than inferred from device fields.
Per-athlete and app permissions, revocation, richer source provenance, transformation history, restore tooling and self-service deletion remain planned. There is no claim that the current beta is a complete compliance solution or a complete business records system.
## Shared responsibility
MovePacket operates the storage, file processing and workspace access in this service. It preserves source files and provides authenticated retrieval and integrity verification.
Your coaching business establishes permission to use athlete data and determines how it should be used. Your application must enforce its own end-user permissions, protect downloaded copies and server keys, and control its coaching recommendations and decisions. The current workspace key is not an athlete-specific grant.
The intended product direction is to make these responsibilities easier to meet with built-in access controls, traceability and portable records. Operational responsibilities need to be supported by the service terms and applicable data-processing arrangements; this guide does not assign legal controller or processor status.
## Evidence before interpretation
Keep original evidence separate from derived results. When your software computes aggregates or prepares context for AI, retain the activity references, source window, units, missing-data information and method version needed to explain the result.
Coaching judgments, readiness scores, training recommendations and race strategy belong in the application built on MovePacket. See the [data model](/docs/data-model) for the beta’s exact fields and units.
---
Source: https://movepacket.com/docs/activities
# 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
```sh
curl --fail-with-body \
"$MOVEPACKET_API_URL/v1/activities?status=ready&limit=20&offset=0" \
-H "Authorization: Bearer $MOVEPACKET_API_KEY"
```
| Parameter | Behavior |
| --- | --- |
| `status` | `received`, `queued`, `ready`, `failed`, or `processing` (received and queued together) |
| `q` | Case-sensitive activity ID substring, up to 128 characters after trimming |
| `limit` | Integer from 1 to 100; default 20 |
| `offset` | Integer from 0 to 100000; default 0 |
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](/docs/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
The workspace’s **Record** tab combines the current activity metadata with available parser details. Verify the original’s checksum and export a record snapshot without adding coaching interpretations. It remains available while processing is pending or has failed. See [records and responsibility](/docs/records).
---
Source: https://movepacket.com/docs/processing
# Let processing happen.
Uploading and decoding are separate steps. Your app can keep working while MovePacket processes the file, then retrieve the result when it is ready.
## The activity lifecycle
| Status | Meaning | Your next step |
| --- | --- | --- |
| `received` | The original and activity record have been stored | Save the ID; keep polling |
| `queued` | Processing has been dispatched or is awaiting recovery | Keep polling |
| `ready` | Decoded JSON is available | Retrieve data; stop polling |
| `failed` | Processing ended with an error | Read `error_code`; stop polling |
`processing` is a list filter and dashboard grouping, not a stored activity status. It includes `received` and `queued`. Fast processing can mean you never observe the earlier states.
## Poll with a limit
Start with a status request every two seconds. Stop on `ready` or `failed`, and set a maximum wait for your application. If that wait expires, keep the activity ID and resume checking later. Do not turn a client timeout into a new upload automatically.
The [runnable quickstart](/examples/movepacket-quickstart.mjs) demonstrates bounded polling, request timeouts, and safe handling of terminal failures. There is no processing-time guarantee in the private beta.
## Retry safely
For connection failures or HTTP `429`, `502`, `503`, and `504`, use a limited number of retries with increasing delays and jitter in production. Respect `Retry-After` when supplied. Do not blindly retry authentication, validation, or file-size errors.
If an upload response is lost, retry the same bytes with the same workspace key. Content deduplication returns the existing activity ID. Re-uploading a terminal failed activity does not restart decoding; correct the source file or inspect its failure first.
MovePacket's queue handler tolerates duplicate delivery. A periodic recovery pass checks stranded work, and repeated processing failures eventually become a visible `failed` status. Your integration should treat the activity endpoint as the current source of truth.
## Webhooks are planned
Outbound webhooks, signing secrets, delivery retries, and delivery history are not available yet. There is no webhook registration endpoint. Use polling against the implemented status endpoint today.
The intended webhook behavior is to let your server react when an activity is ready or has failed. Event names and payloads will be documented when that contract is implemented and tested. Avoid building against speculative event examples.
---
Source: https://movepacket.com/docs/data-model
# The original, plus structure.
The original FIT file is the source record. Decoded JSON makes its contents easier to use without changing the original. The beta retains the Garmin FIT SDK's field names and units.
## Activity metadata
The activity response describes storage and processing: `id`, `status`, `sha256`, `byte_size`, `created_at`, `error_code`, and retrieval `links`. `duplicate` is added to upload responses only.
Activity metadata does not currently include a filename, sport, athlete profile, or summarized ride metrics. Retrieve decoded JSON to read the recorded activity details.
## Decoded response
| Field | Meaning |
| --- | --- |
| `schema_version` | Current wrapper version: `0.1` |
| `parser.name` | Decoder package: `@garmin/fitsdk` |
| `parser.version` | Current decoder version: `21.214.0` |
| `parser.fit_profile` | FIT profile version reported by the decoder |
| `summary` | Array of decoded session messages |
| `message_count` | Number of decoded messages |
| `messages` | Groups of FIT messages, such as `recordMesgs`, `lapMesgs`, and `deviceInfoMesgs` when present |
`summary` is an array because a file can contain multiple sessions. Do not assume every activity has just one session. Fields and message groups depend on the source device and recording settings.
## Read only what is present
```js
// Run on your server after retrieving the decoded JSON.
const sessions = data.summary;
const records = data.messages.recordMesgs ?? [];
const power = records
.filter(record => Number.isFinite(record.power))
.map(record => ({time: record.timestamp, watts: record.power}));
```
Missing measurements are not zero. Keep their absence visible in your own charts and calculations. Do not assume the same sampling interval or sensor coverage across files.
Common decoded session fields include `totalTimerTime` in seconds, `totalDistance` in meters, `avgPower` in watts, and `avgHeartRate` in beats per minute. Keep an explicit unit conversion at your presentation boundary. JavaScript Date values serialize as ISO timestamps; large integer values serialize as decimal strings.
## Limits and versioning
The beta accepts one FIT file up to 4 MiB and caps decoding at 50,000 messages and 16 MiB of serialized message content before the final wrapper is assembled. A file exceeding decoded limits reaches `failed` with `decoded_limit_exceeded`; its accepted original remains available.
This is an early FIT response contract, not yet a normalized schema across device providers. Keep `schema_version` and parser metadata with data you store, tolerate unknown fields, and preserve the original for future reprocessing.
---
Source: https://movepacket.com/docs/errors
# Know what to do next.
API failures return a JSON object with an `error` code. A successful activity read can also describe a processing failure through `status: "failed"` and `error_code`.
## Request errors
| HTTP | Code | Action |
| --- | --- | --- |
| `400` | `empty_body` | Send a FIT file as the request body |
| `400` | `invalid_list_query` | Check status, search length, limit, and offset |
| `401` | `unauthorized` | Check the bearer key and target environment |
| `404` | `activity_not_found` | Check the ID and workspace; another workspace's activity is also hidden as 404 |
| `404` | `not_found` | Check the method and API path |
| `409` | `activity_not_ready` | Poll status before requesting decoded JSON |
| `413` | `file_too_large` | Use a file of 4 MiB or less |
| `415` | `send_raw_fit_bytes` | Use a supported binary content type |
| `422` | `invalid_fit`, `invalid_fit_length`, `invalid_fit_crc` | Export the original single FIT file again; check for truncation or corruption |
| `503` | `stored_object_unavailable`, `service_unavailable` | Retry with a bounded delay; keep the activity ID |
| `503` | `beta_not_open` | The public site is available, but the hosted beta API has not opened |
Browser-only routes can also return `browser_signin_required` or `origin_not_allowed`. They are internal to the signed-in workspace; server integrations should use `/v1/`.
## Processing failures
| Code | Meaning |
| --- | --- |
| `not_an_activity` | The file has no activity file identifier or no session messages |
| `fit_decode_failed` | The decoder could not read the file successfully |
| `decoded_limit_exceeded` | The decoded message count or size exceeded beta limits |
| `processing_unavailable` | Repeated dispatch attempts did not produce a completed result |
Validation codes can also appear during processing if the stored original cannot pass revalidation. For a failed activity, the `/data` endpoint returns HTTP `409` with its processing error code.
## Preserve a useful reference
Keep the activity ID, HTTP status, and error code when diagnosing a problem. Do not log API keys or complete activity files. If an upload response is lost, the same file can be uploaded again safely within the same workspace.
---
Source: https://movepacket.com/docs/api-reference
# The API, in detail.
The implemented beta endpoints, generated from the same [OpenAPI contract](/openapi.json) you can import into your development tools. All requests require a workspace bearer key.
## Upload a FIT activity
`POST /v1/activities`
Send raw FIT bytes, not multipart or JSON. Maximum 4 MiB. The same bytes in the same workspace reuse one activity. HTTP 202 means processing is pending; 200 means the returned activity is already ready or failed. Concurrent uploads converge on one ID; duplicate is advisory.
**Body:** raw FIT bytes, maximum 4 MiB. Content-Type: `application/vnd.ant.fit` or `application/octet-stream`.
| HTTP | Response |
| --- | --- |
| `200` | Existing terminal activity |
| `202` | Activity accepted for asynchronous processing |
| `400` | Invalid request |
| `401` | Missing, invalid, or revoked key |
| `413` | File exceeds 4 MiB |
| `415` | Unsupported media type |
| `422` | FIT validation failed |
| `503` | Service or stored object unavailable; hosted beta may not be open |
## List activities
`GET /v1/activities`
Workspace-scoped, newest first (created_at then id, both descending). Offset pages can shift when new activities are added. stats always describes the entire workspace, independent of filters.
| Parameter | Location | Details |
| --- | --- | --- |
| `q` | query | Case-sensitive activity ID substring; trimmed |
| `status` | query | processing combines received and queued Values: received, queued, processing, ready, failed. |
| `limit` | query | Range: 1–100. Default: 20. |
| `offset` | query | Range: 0–100000. Default: 0. |
| HTTP | Response |
| --- | --- |
| `200` | Matching activities and workspace counts |
| `400` | Invalid request |
| `401` | Missing, invalid, or revoked key |
| `503` | Service or stored object unavailable; hosted beta may not be open |
## Read activity status
`GET /v1/activities/{id}`
| Parameter | Location | Details |
| --- | --- | --- |
| `id` | path · required | Activity ID returned by upload |
| HTTP | Response |
| --- | --- |
| `200` | Activity metadata; check status for processing state |
| `401` | Missing, invalid, or revoked key |
| `404` | Unknown resource or inaccessible workspace |
| `503` | Service or stored object unavailable; hosted beta may not be open |
## Retrieve decoded JSON
`GET /v1/activities/{id}/data`
Available only for ready activities. FIT SDK field names and units are retained; source-dependent message fields are intentionally open.
| Parameter | Location | Details |
| --- | --- | --- |
| `id` | path · required | Activity ID returned by upload |
| HTTP | Response |
| --- | --- |
| `200` | Decoded FIT messages |
| `401` | Missing, invalid, or revoked key |
| `404` | Unknown resource or inaccessible workspace |
| `409` | Data not ready or decoding failed |
| `503` | Service or stored object unavailable; hosted beta may not be open |
## Download untouched original
`GET /v1/activities/{id}/original`
Available even when decoding failed. Compare its SHA-256 with the activity metadata and your source.
| Parameter | Location | Details |
| --- | --- | --- |
| `id` | path · required | Activity ID returned by upload |
| HTTP | Response |
| --- | --- |
| `200` | Exact uploaded FIT bytes |
| `401` | Missing, invalid, or revoked key |
| `404` | Unknown resource or inaccessible workspace |
| `503` | Service or stored object unavailable; hosted beta may not be open |
## Response schemas
See the [data model](/docs/data-model) for field meanings and the [OpenAPI JSON](/openapi.json) for complete machine-readable response schemas. The downloadable contract includes only implemented server endpoints.
---
Source: https://movepacket.com/docs/ai-tools
# Give your tools the context.
MovePacket's documentation is available as readable pages, Markdown, and an OpenAPI contract. Point your coding assistant at these resources before asking it to build an integration.
## Machine-readable resources
| Resource | Use |
| --- | --- |
| [llms.txt](/llms.txt) | Guide index for AI tools |
| [llms-full.txt](/llms-full.txt) | All current guides in one text document |
| [openapi.json](/openapi.json) | OpenAPI 3.0.3 contract for implemented server endpoints |
| [Runnable Node.js example](/examples/movepacket-quickstart.mjs) | Upload, polling, downloads, and checksum verification |
Every guide also has a Markdown version, linked in the page tools. Documentation is public. Reading it does not grant access to activity data or API credentials.
## Start an integration
Copy this brief into your coding tool:
```text
Read https://movepacket.com/llms.txt and the linked OpenAPI contract.
Build a server-side MovePacket integration using environment secrets.
Upload raw FIT bytes, retain the activity ID, and poll with a bounded wait.
Handle ready and failed states explicitly. Download decoded JSON only
when ready, and verify the original file's SHA-256 before accepting it.
Use only documented endpoints. Do not put API keys in browser code,
URLs, logs, or chat. Check hosted beta availability before live uploads.
```
## API and MCP
The REST API is the current application interface. A MovePacket MCP server is planned but is not available yet. These documentation resources help AI tools write integrations today; they are not an authenticated MCP connection.
There is no packaged MovePacket SDK yet. The downloadable Node.js example uses standard HTTP calls and can be adapted inside your server application.
## Prepare evidence before asking AI to interpret it
Your application should select relevant activity windows and calculate aggregates before sending long time-series data to a language model. Keep original activity IDs, units, missing-data indicators and calculation versions with the result so it can be traced back. Do not replace unavailable measurements with zero.
MovePacket’s current API returns decoded FIT data; it does not yet provide intent-based retrieval, compressed athlete context or athlete memory. Evidence preparation is a future infrastructure concern. Coaching judgments and recommendations remain your application’s responsibility.
Start with [athlete connections](/docs/connections) and [source records](/docs/records). An AI coding assistant cannot create provider access or athlete permission on your behalf.