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.

A consent profile is the blueprint your SDK reaches for when an end user goes through the consent flow. It’s the per-app slice of what’s offered to the user — the channels, tiers, and high-level capabilities your app may request consent for. Edit profiles from the dashboard: Projects → your project → Apps → your app → Consent Profiles.

​
Profiles vs. App Policy

These two layers do related-but-distinct jobs:
LayerWhere you set itWhat it expresses
App policyDashboard → App → App PolicyHard deny-list and coarse allow_* gates the runtime enforces on every upload
Consent profile (this page)Dashboard → App → Consent ProfilesThe set of options the SDK shows the user during the consent flow
App policy is a backstop. Consent profile is the menu. The user sees the consent profile; the runtime enforces app policy. A user can only grant something that’s both offered by the consent profile and allowed by app policy — see the three-layer model. Open or create a profile in the dashboard. You’ll see two sections:

​
General settings

The high-level capabilities your app may offer. End users still pick from these — the profile just says “this app is allowed to ask.”
ToggleMeaning
Allow cloud processingThe profile may include cloud upload as an option. Required for research participation.
Vendor sync allowedThe profile may include third-party wearable sync (WHOOP, Garmin, etc.).
Allow researchThe profile may include research / lab-export participation. Requires cloud processing.
Allow SyniThe profile may include Syni AI coach access. Subject to your platform plan and your app policy.
Set as default profileNew users see this profile first when your app requests consent. Exactly one default per app.

​
Channels

The granular data types the SDK consent UI offers, grouped by source:
  • Biosignals — vitals, cardio advanced, neuromuscular, wearable motion, sleep
  • Phone context — device motion, device context, system state
  • Behavior — digital activity, notification patterns, app context
  • Interpretation — focus estimation, emotion estimation
This is the same taxonomy the SDK consumes — see Consent System → Granular channels for what each one unlocks. A check next to a channel here means “the consent UI may offer this channel”; an unchecked channel is simply not surfaced. The end user then grants whichever subset they’re comfortable with at runtime.

​
Multiple profiles, one default

You can ship more than one profile per app — for example a Standard and a Research variant — and pick which one is the default. The SDK fetches the default at consent time; your app can request a specific non-default profile by id if your flow needs it. Only one profile may be flagged default. Toggling default on one automatically clears it from the others.

​
Versioning: edits publish a new snapshot

Profiles are immutable once published. Editing the channels or any of the General Settings doesn’t overwrite the old data — it creates a new version row and marks it current. Each consent token your SDK mints references the version the user agreed to, so old tokens stay valid against the snapshot they were issued from. When you edit a profile in the dashboard you’ll be asked for:
  • A version name (required for any payload-changing edit) — e.g. “v2 — added sleep channel”.
  • A description (optional) — release notes for the change.
Metadata-only edits (renaming the profile, changing its description, toggling Set as default, deactivating it) don’t create a new version.

​
How profiles compose with the other layers

The user-facing toggle has effect only if all three of these say yes:
  1. Platform capability — Synheart’s master switch for the feature class.
  2. App policy — your per-app allow / restrict configuration.
  3. Consent profile (this page) — the channel actually offered, and the user actually grants it.
A channel you uncheck here is never offered to the user, so they can’t grant it — equivalent to restricting it at the app-policy layer. The difference is intent:
  • Use consent profile to shape what the user sees.
  • Use app policy → Restricted Channels to forbid the channel even if some other profile would offer it.

​
Default profile workflow

When a developer first wires up a new app, the dashboard auto-creates a default profile with sane defaults (Cloud on, Research off, Syni off, Vendor sync off; biosignals + behavior channels checked, interpretation off). That profile is what users see at first launch. You can then:
  • Edit the default to expand or narrow what your app offers.
  • Add additional profiles if you have a Pro tier, research arm, or other variants — and point your app at them by profile id when needed.
  • App policy — the per-app enforcement layer that backstops what profiles offer.
  • Consent System — full SDK reference for the channel taxonomy, tiers, and runtime enforcement.
  • Implementing consent — how to wire the consent flow into your app.