Skip to main content
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: 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.”

​
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

A channel offered in a profile still needs App policy to allow it and the user to grant it; all three layers must agree. See App policy → How it composes for the full diagram. The key distinction between the two layers:
  • Use a consent profile to shape what the user sees and can grant.
  • Use App policy → Restricted Channels to forbid a channel entirely, even if a profile would otherwise 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.