# 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).