Platform age signals

Game platforms (Apple iOS, Google Play, Xbox, Meta Horizon, and k-ID itself) can provide age data about a player. This data can be passed to k-ID alongside, or instead of, a self-reported age. k-ID uses it to suppress the age gate when appropriate, resolve age conflicts, and, when the signal is considered verified, satisfy age verification requirements without additional verification steps.

Platform age signals work together with age assurance for high-risk features. For example, a verified Apple iOS signal can both skip the age gate and unlock loot box permissions in Brazil without a separate verification step.

Start here

Use this feature set when you want to:

• Reuse age information the platform already knows about the player
• Skip the age gate for verified adult signals
• Unlock high-risk permissions, such as Brazil loot boxes and targeted ads, without asking the player to verify again
• Detect when a platform age signal conflicts with a self-reported age

Quick integration paths

If your game has…	Send to k-ID	What usually happens
A verified adult signal from Apple iOS, Google Play, or k-ID	The platform signal on both GET /age-gate/get-requirements and POST /age-gate/check	The age gate can be skipped and verified-age permissions can be enabled immediately
An unverified signal, such as Xbox or Meta Horizon	The platform signal on get-requirements and check	k-ID can still use it for conservative age resolution, but it won't satisfy verified-age permissions
A category-based platform signal	The category directly, or first convert it with POST /age-gate/get-platform-age-range	k-ID resolves the category into a jurisdiction-specific age range
No platform signal at all	Your normal age-gate inputs	The standard age gate flow applies, and high-risk permissions can require age assurance later

API map

These are the endpoints developers use most during integration:

Endpoint	When to call it	Why it matters
GET /age-gate/get-requirements	Before showing an age gate	Tells you whether to show the gate and whether any verified-age permissions still need assurance
GET /session/get	After check or a challenge completes	Lets you refresh permissions and inspect ageVerification
POST /age-gate/check	Always, after you have the player's age inputs	Creates or updates the session and records verified age on the session when a verified platform signal allows it
POST /session/upgrade	When the player tries to use a high-risk feature	Either enables the requested permissions immediately or creates an age-assurance challenge
POST /age-gate/get-platform-age-range	Only for category-based platform signals	Converts a platform category to ageLow and ageHigh

End-to-end flow

Recommended request sequence

1. Get the platform signal at launch. If the platform exposes age data, capture it as early as possible so you can use it on both get-requirements and check.
2. Call GET /age-gate/get-requirements. This tells you whether to show the age gate and whether any permissions still need verified age.
3. Always call POST /age-gate/check. Even when the gate is skipped, you still need check to create or update the session.
4. Store the sessionId and current permissions. This is what your game should use to control feature access.
5. Call POST /session/upgrade only when needed. Do this when the player actively tries to use a high-risk feature that's not yet enabled.

tip

If shouldDisplay is false but you don't actually have a platform signal to send, call POST /age-gate/check with age: 1 as a conservative fallback.

How POST /age-gate/check uses platform signals

Key concepts

The PlatformAgeSignal object

A unified object describing a platform-reported age signal. Provide either category or both ageLow and ageHigh. Never provide both.

{
  "name": "apple-ios",
  "ageLow": 18,
  "ageHigh": 25,
  "declarationType": "governmentIDChecked",
  "verificationId": null
}

Field	Type	Required	Description
name	string	Yes	Platform identifier: apple-ios, google-play, xbox, meta-horizon, or k-id
category	string	No	Platform-specific age category (for example, digital-youth, TN, teen)
ageLow	integer	No	Minimum age in years from the platform. Should be paired with ageHigh.
ageHigh	integer	No	Maximum age in years from the platform. Should be paired with ageLow.
declarationType	string	No	How the platform determined the age (for example, governmentIDChecked, VERIFIED)
verificationId	string (UUID)	No	For k-id signals only: references a completed k-ID verification record

Supported platforms

Platform	Accepted input	Verified declaration types	Notes
apple-ios	ageLow + ageHigh only	paymentChecked, governmentIDChecked, guardianPaymentChecked, guardianGovernmentIDChecked	Category input returns 400
google-play	ageLow + ageHigh only	VERIFIED, SUPERVISED	Category input returns 400
Xbox	category (child, teen, adult)	None (unverified for age requirements)	Ranges are jurisdiction-dependent
meta-horizon	category (CH, TN, AD)	None (unverified for age requirements)	Ranges are jurisdiction-dependent (see Meta Horizon)
k-ID	category (digital-minor, digital-youth, adult)	KIDVerified (server-resolved)	A verified declaration requires valid verificationId from the same org within Compliance Studio

Verified and unverified signals

A platform signal is considered verified only when the declarationType is in the verified set for that platform. Verified signals can:

• Suppress the age gate (shouldDisplay = false) when the signal indicates an adult (ageLow >= civilAge)
• Satisfy age verification thresholds on permissions (for example, enabling loot boxes without a separate verification step)
• Record an ageVerification on the session for future permission checks

Unverified signals (for example, Xbox, Meta Horizon, or self-declared Apple or Google signals) are still useful for age conflict detection and conservative age resolution, but they can't bypass verification requirements.

Verified age threshold

Some permissions require a verified age before they can be enabled. In those cases, the permission includes a verifiedAgeThreshold value.

For example, in Brazil, loot-boxes-paid-cosmetic-only, loot-boxes-paid-gameplay-impacting, targeted-ads, and profiling require a verified age of 18, and direct-marketing requires a verified age of 12. If the player's effective age is below the threshold, the permission becomes PROHIBITED. If the player meets the threshold but hasn't verified age yet, the permission stays enabled: false until either:

• A verified platform signal satisfies the threshold, or
• The player completes age assurance for high-risk features

Age conflict detection

When both a primary age parameter (dateOfBirth, age, or kuid) and a platformAgeSignal are provided to /age-gate/check, the system compares their age categories:

• Platform younger than self-reported (for example, platform says "child" but player says "adult"): returns AGE_CONFLICT (400 error)
• Platform older than self-reported: permissible; the more conservative (lower) age is used
• Same category: no conflict; proceeds normally

info

Age conflict detection is a per-developer feature flag. Contact k-ID to enable it.

Next steps

• For exact request shapes, platform-specific notes, and validation rules, see Platform signal details.
• For verified-age permissions and session upgrade behavior, see Age assurance for high-risk features.