COPPA Compliance Guide

COPPA (Children's Online Privacy Protection Act) applies to websites and online services directed at children under 13 in the United States.

Configuration

Age gate is a per-profile, per-locale dashboard setting, not acreateConsenti()/ConsentiSetup()config option — one global age doesn't fit every jurisdiction a multi-region deployment serves. In the dashboard's Profile Editor:

1. Step 1 → enable "Age gate", set minimum age to 13, check "Require parental consent".
2. Main Banner content step → author the age-gate modal's heading, body text, and Yes/No button labels for each locale you support.

The widget reads this straight off the resolved profile (profile.ageGate/profile.ageGateModal) — no separate widget-side config needed. For a standalone/local profile (registerProfile()), set ageGate/ageGateModal directly on the EmbeddedProfile/EmbeddedTranslations you register instead.

How it works

When the active profile's ageGate.enabled: true, the widget shows a Yes/No age-confirmation prompt before anything else — banner, GPC, CCPA opt-out all wait behind it on first visit:

1. Confirmed (visitor is minimumAge or older) → normal banner/GPC/CCPA flow proceeds; every consent submission from then on carries ageVerified: true.
2. Declined, requireParentalConsent: false → a deny-all consent is submitted immediately (mandatory/strictly-necessary cookies still granted), ageVerified: false, no banner shown.
3. Declined, requireParentalConsent: true → same deny-all submission, plus the widget requests a parentalConsentToken from the backend (signed with compliance.dataSigningHash, auto-generated if not set) and fires a consenti:parentalConsentRequired event carrying it — see UI Events.
4. The age_verified and parental_consent_token columns are stored on the consent record either way.

API fields

{
  "visitorId": "uuid",
  "consentJson": { "analytics": "denied" },
  "ageVerified": false,
  "parentalConsentToken": "pcon_..."
}

Parental consent flow

Consenti mints a stateless, signed parentalConsentToken and emits it — no server-side persistence of the token itself, and no email-sending infrastructure in this zero-runtime-dependency package. Both the request and the resolve step are plumbing for your own out-of-band verification process, for example:

1. Widget declines → calls POST /consent/:visitorId/parental-consent-request, fires consenti:parentalConsentRequired with the returned token
2. Your eventBus.on('consent.parentalConsentRequired', ...) listener sends the parent an email with a verification link containing the token
3. Parent clicks the link → your backend verifies them however you choose
4. Once verified, call POST /consent/parental-consent-resolve with { token } — either from the parent's page (via resolveParentalConsent() from @consenti/ui) or server-side. Consenti emits consent.parentalConsentGranted; your own eventBuslistener decides what "granted" means for stored consent (e.g. call PUT /consent/:visitorIdyourself) — Consenti doesn't update the record automatically.

Dashboard filtering

In the admin dashboard, consent records with age_verified: true are flagged so compliance officers can audit them separately.