actigraph/centrepoint3apidocumentation

This repository is not application code; it is the Markdown documentation for the CentrePoint V3 API. Architecturally, it describes a public integration surface between external client systems and ActiGraph’s CentrePoint study-admin platform.

1. Top-level system boundary

The API exposes CentrePoint study administration and de-identified subject data through two hosted endpoints: the API at api.actigraphcorp.com and OAuth authorization at auth.actigraphcorp.com. The documentation positions CentrePoint as the internal system of record and the API as its external integration layer.

2. Access and security layer

All interaction is authenticated through OAuth 2.0, and the API requires HTTPS. Requests and responses are JSON-based. This means any architecture diagram should show a distinct auth service in front of the API, with client applications obtaining tokens before calling resource endpoints.

3. Core study management domain

The main CRUD-style domain is study administration: studies, sites, subjects, activity monitors, assignments, study milestones, uploads, and visit files. These resources form the operational backbone of the API and are likely backed by the same core CentrePoint data model used by the web portal.

4. Subject-centric workflow

Several endpoints model the lifecycle of a subject in a study:

studies contain sites, sites contain subjects, and subjects receive monitor assignments and uploads. The assignment workflow is explicitly separated from assignment retrieval, suggesting a stateful process for starting and ending device-to-subject tracking.

5. Device and monitoring data

Activity monitors are first-class resources, along with the assignment workflow that links them to subjects. This is the bridge between study administration and captured device data, so a diagram should show device inventory and subject-device association as a distinct subsystem.

6. Analytics and derived data

A separate group of endpoints serves processed study data: algorithm settings, minute summaries, daily statistics, sleep periods, and event markers. These are derived/analytics outputs rather than raw records, so they likely come from an analysis pipeline or precomputed store rather than direct transactional tables.

7. Large-data and raw-data retrieval

The docs distinguish between “Data Access Files” for pre-made daily files of large raw accelerometer data and a legacy/raw data request flow for sub-second activity data. That implies a bulk-file generation subsystem or export service separate from the standard JSON resource endpoints.

8. Export and dataset subsystem

The “DataSet Export” sections introduce study programs, datasets, dataset export files, and dataset export subjects. This is a second export-oriented boundary, focused on packaging study data for downstream analysis rather than operational management.

9. Webhook/event delivery

Webhooks and webhook events provide a push-based integration path in addition to pull-based API access. The documentation covers both event listings and subscription/history tracking, which implies a notification dispatcher and request log/history service on the CentrePoint side.

10. Operational constraints and protocol behavior

The API enforces request limiting at 500 requests per minute per IP with 429 and Retry-After, and uses ISO 8601 date handling with timezone semantics depending on the presence of Z. Pagination is documented separately, indicating list endpoints are expected to be consumed incrementally.

11. File and upload handling

Uploads and visit files are separate from core JSON resources, which suggests mixed interaction modes: metadata via API and file transfer via dedicated endpoints. In a diagram, file-bearing flows should be shown apart from standard entity reads/writes.

12. Repository structure as documentation map

The sections/ directory is organized by capability area rather than by implementation layer, which makes the docs themselves a navigation index for the API surface. For architecture purposes, the sections map cleanly onto three major zones: operational study management, derived/analytics data, and data export/bulk transfer.

In short, the documentation describes a multi-surface integration platform centered on CentrePoint studies: authenticated JSON APIs for operational records, separate services for analytics and bulk data, and webhook-based outbound notifications.