Verified Parent Linking (VPL)

Verified parent linking (VPL) lets a player invite their own parent into your product. Once the parent verifies their identity, they can see and set that player's controls, for example, screentime.

What's verified parent linking?

Verified parent linking establishes a supervisory relationship between a parent and a player who's already allowed to use your product. It's the player's choice: they start the flow, and your product keeps working whether or not the parent ever accepts. Nothing waits on the parent, which is what separates it from parental consent.

A link, not a gate

This is the distinction that governs the whole feature, so it's worth stating plainly.

Verifiable Parental Consent (VPC) is a gate. The player reaches something they aren't allowed to do, access is blocked, and a trusted adult has to approve before anything proceeds. It's legal consent for data processing.

VPL is a link. Nothing waits on a parent, and no consent is being given. It establishes a supervisory relationship, not a legal one.

	VPC	VPL
Stands for	Verifiable Parental Consent	Verified parent linking
Triggered by	The player is under the access age at sign-up, or reaches a GUARDIAN-managed feature	The player chooses to invite their own parent
Who starts it	The parent, while the player waits	The player, and the parent has no relationship with your product yet
Legal frame	Consent for data processing (for example COPPA, GDPR-K)	A supervisory relationship, not consent for data processing
Strength	Hard. The feature or the product is blocked until approval	Soft. The product works fully without it
What it writes	The enabled value of the consented permissions	Allowances and per-control state, such as screentime. Never permissions
Default state	Blocked until approved	Unlinked, and the invite is opt-in
challenge.type	CHALLENGE_PARENTAL_CONSENT or CHALLENGE_SESSION_UPGRADE	CHALLENGE_PARENT_INVITE
Endpoints you call	/age-gate/check then /challenge/send-email, or /session/upgrade	/age-gate/check then /challenge/invite-parent

VPC and VPL are mutually exclusive

important

If VPC can apply to a player in any form, VPL isn't offered to them.

A session is eligible for VPL only when both of the following are true:

• The player is at or above the access age for their jurisdiction, so /age-gate/check returned PASS and minted a session.
• No permission on that session is managedBy: GUARDIAN for the player's jurisdiction and age.

Every case where VPC could fire is therefore a case where VPL is rejected. The following table lists them:

The player's situation	What VPC does	Why VPL isn't available
Under the jurisdiction's access age	/age-gate/check returns CHALLENGE with a CHALLENGE_PARENTAL_CONSENT challenge, and no session is minted	Without a session there's nothing to invite a parent to, so /challenge/invite-parent is never reachable
Under the access age with data-lite mode on	Same CHALLENGE response, with childLiteAccessEnabled: true as a cue to let the player in with your own safe-default experience while consent completes	Still no session, so the invite is never reachable
At or above the access age, but the session carries a GUARDIAN-managed permission	The session is minted with that permission locked, and VPC fires mid-session through /session/upgrade when the player reaches the feature	The invite is rejected with FEATURE_DISABLED. Read permissions[] on the session to check this yourself before calling
The product is prohibited for that jurisdiction and age	/age-gate/check denies	No session

In practice, VPL applies to products that have no GUARDIAN-managed permissions in the jurisdictions they're configured for.

A single product can still use both flows for different players. There's no product-level switch: which flow applies is derived per session from the player's jurisdiction, age, and your product's permission set. If your product has GUARDIAN-managed permissions in some jurisdictions but not others, players in the first group go through VPC and players in the second are eligible for VPL.

What linking grants, and what it doesn't

Once a parent is linked, whatever they set during the flow is persisted against the session:

• Allowances are returned on the session by GET /session/get.
• Per-control state, for example the screentime schedule (daily limit, quiet hours, break reminders), is returned by GET /screentime/get-state.

Enforcement stays with you. k-ID reports the state the parent set, and your product acts on it.

VPL never changes what permissions[] grants. The values stay exactly as the age gate left them, because changing what a player is allowed to do belongs to VPC alone.

Neither flow writes managedBy. It's derived per response from the player's age and your jurisdiction configuration, so it doesn't flip when consent completes, and it can change on its own as the player ages up. See Permissions for what does change.

Sessions and the kuid

The sessionId you get from /age-gate/check is your permanent handle for one player on your product. It survives link, unlink, and relink. Key your own user records on it.

The kuid is k-ID's identifier for the persistent child profile the session is attached to. k-ID assigns it when a parent completes the link, and clears it from the session if the link is later removed. Its presence therefore tells you a parent is linked to the session.

Stage	sessionId	kuid	Session state
Age gate only, first time	New, stable from here on	None	managedBy: PLAYER, hasApproverEmail: false
Parent links	Same	Assigned, and delivered on the Challenge.StateChange webhook	hasApproverEmail: true
Unlinked	Same	Cleared	Session stays ACTIVE, permissions and pushed data intact
Relinked	Same	The same profile's kuid returns	Session and pushed data continue, but the parent starts from nothing and sets their controls again

Use one session per player and reuse it. Creating a second session for the same player splits their data across both.

Availability

Please contact k-ID to have this capability turned on for your organization.

Next steps

• The quick start guide to Verified Parent Linking walks through the invite, cancel, and unlink calls end to end.
• Session.Unlink is the webhook that tells you when either side ends a link.