Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.synheart.ai/llms.txt

Use this file to discover all available pages before exploring further.

Projects are the unit of work in the platform. They group the apps you’ve registered, the devices that feed them, and the sessions those devices produce. Every project lives inside a tenant inside an organization—a logical grouping for one product or initiative within that tenant. 
Project
  ├── Apps         — one or more registered Apps (each has its own platform `app_id`)
  ├── Wearables    — devices linked to this project's apps
  └── Sessions     — usage events with biosignals + emotions

​
Create a project

From the developer portal, open Projects and choose New project. You’ll set:
  • Name and optional description.
  • Region — the AWS region that will store this project’s data (e.g. us-east-1, eu-west-1). Pick the region closest to your users.
  • Tenant — which tenant workspace inside your org owns the project.
  • Status — active, archived, or setup_incomplete for a project you’re still wiring up.
A project starts empty. Add apps next.

​
Add apps to a project

Each registered App in a project has a platform app_id assigned by the dashboard. Register one from inside the project — see Register an app. One project can hold multiple apps; a given app_id belongs to exactly one project at a time.

​
Wearables

The project’s Wearables tab is where you’ll see the integrations connected to your apps. A wearable record carries a name, device type (Apple Watch, Garmin, Fitbit, …), an external device id, and a connection status. Each project allows one wearable per device type today, so adding a second Apple Watch to the same project is rejected. The data that powers a wearable comes from your app integrating one of the Synheart Wear adapters — the platform doesn’t pair devices itself. Until your app sends data, the wearable will show as not yet connected.

​
Sessions

A session is one usage event captured on-device and ingested into the platform. Sessions surface under the project’s Sessions tab once the apps in the project ingest them via an allowlisted API key. See API keys → Ingestion access for how that allowlist works, and Synheart Session for how sessions are produced on-device.

​
Project settings

Each project exposes a settings page for renaming, archiving, and managing access. Archive projects you’re no longer working in rather than deleting them — archived projects stay readable but step out of the active list.

​
Patterns that work well

  • One project per environment — keep dev, staging, and prod data isolated.
  • Project per study or cohort — for research, give each cohort its own project so you can scope keys and access cleanly.

​
Next

API keys

Generate scoped keys for the apps in your project.

Synheart Session

See how sessions are produced on-device before they reach the platform.