Skip to main content
App policy is the per-app slice of the three-layer consent model. It sits between the Synheart platform (master switches) and your end users (per-channel consent), and lets you express what this specific app is allowed to offer. Edit it from the dashboard: Projects → your project → Apps → your app → App Policy → Edit Policy.

​
What App Policy controls

Two kinds of controls, surfaced separately: There is no “Required Channels” control: the SDK already expresses positive ceilings on the Consent Profile the user sees during onboarding. The app layer’s only job is to restrict further, not to mandate.

​
General Settings

All five default to off for a newly registered app. Turn on only what your app actually uses; Synheart’s platform-level capability mask refuses to persist a flag that exceeds what your plan grants, so you’ll get an error rather than silently being over-permissive.

​
Restricted Channels

A check next to a channel here means your app will not collect that data. The end user’s consent doesn’t override it. Use this when:
  • A regulator or your privacy team has told you a specific data type is off-limits for this app, even if the SDK supports it.
  • You ship a focused product (e.g. sleep-only) and want to refuse incidental channels even if the user grants them.
  • You’re piloting a configuration and want to disable a channel temporarily without rolling a new SDK build.
Channels are grouped by the same taxonomy the SDK uses; see Consent System → Granular channels for the canonical list. Marking a channel restricted causes uploads tagged with that channel to be denied at the consent service before they reach the ingest pipeline.

​
How it composes with the other layers

  • Platform capability caps everything. If syni_integration is disabled at the platform level, no app can turn on Allow Syni.
  • App policy (this page) further restricts what your app may offer.
  • User consent narrows down to what the end user actually grants.
A request only succeeds when all three layers say yes. See Consent System → Three-layer authority for the SDK-side perspective.

​
Default behavior

A newly registered app has no policy until you create one. While missing, the consent service treats the app as deny-all for the gated upload classes, a safe default. Create a policy as soon as the app is registered. If you change a policy after the app is live:
  • Loosening a flag (turning Allow Research on) takes effect on the next consent token your users mint. Existing tokens carry the older snapshot until they refresh.
  • Tightening a flag (turning Restricted Channels on, or turning Allow Cloud Processing off) is enforced at the next upload; the consent service rechecks the policy on every request, so changes apply within seconds even to already-issued tokens.