Skip to main content

Custom workflow

The k-ID custom workflow for age gate and Verifiable Parental Consent (VPC) involves multiple steps that determine whether a player can access your game and what permissions they have.

Workflow overview​

The flow chart below shows a view of the k-ID Engine workflow. API calls are identified at the points in the workflow where they're used.

k-ID Workflow

Note: If you have a kuid for a user you can use that to look up if they have a session for a game.

Workflow steps​

1. Get age gate requirements​

Call /age-gate/get-requirements with the player's jurisdiction to determine:

  • Whether an age gate should be displayed
  • What age collection methods are allowed
  • Age thresholds (digital consent age, civil age, minimum age)
  • Whether age assurance is required

2. Collect age (if required)​

If an age gate is required (shouldDisplay = true), collect the player's age with the approved methods for the jurisdiction.

3. Check age for access​

Call /age-gate/check with the player's date of birth and jurisdiction to determine the next step:

  • PROHIBITED: Player is below the minimum age - block access
  • CHALLENGE: Player requires parental consent - create a challenge
  • PASS: Player can continue - create or return a session

If a challenge is created:

  • Display the challenge to the player (QR code, OTP, email input)
  • Notify the trusted adult (via email if provided)
  • Wait for consent (via webhooks or polling)
  • Process the result (grant access if consent is granted)

5. Get session​

Once consent is granted or if consent isn't required, retrieve the session by calling /session/get to get the player's permissions and age status.

6. Use permissions​

Use the session permissions to control access to features in your game based on the enabled and managedBy fields for each permission.

Account system integration​

Some studios have a common Account system that spans across multiple games. It's often desirable in these situations to integrate an age gate and to handle Verifiable Parental Consent (VPC) directly in the Account creation flow so that players are asked for their age only once for all games from the same publisher.

When doing this type of integration, there are a few important considerations:

Product context for VPC​

If the games all require an Account to play, then VPC can be triggered from the Account creation process. However, the request for consent must be specific to a game so that a parent knows what they're consenting to. The k-ID API determines what Product should be presented to the parent during the consent process based on what API key is used when triggering VPC.

In practice, the integration of k-ID into an Account system must be able to determine at the time of Account setup what game triggered the Account creation process, and map that to a k-ID API key.

Using a kuid to access k-ID sessions​

k-ID exposes a global identifier for all players that have had some form of trusted adult consent called kuid or k-ID User ID. The kuid is returned as a property of the Session object. When integrating with an Account system across multiple games, the kuid should be associated with the player's identity in the Account system when present in a Session. This allows retrieval of a k-ID Session, if it exists, for any k-ID Product by calling /session/get providing only the kuid as a parameter and using the appropriate API key for the correct Product.

Caching sessions for multiple products​

When integrating with an Account system, Sessions from multiple Products are cached. Session objects can all be cached as a map in the Account system by using the k-ID Product ID as a key. When a player attempts to play a new game, the map containing Session objects can be queried by Product ID, and if a Session is already present, the player can then be allowed to continue without further trusted adult consent.

Account-level product​

When configuring an Account System integration of k-ID, it's typical to create one k-ID Product for each game, and then a separate k-ID Product for the Account System itself in the Compliance Studio. This is useful to represent any permissions and disclosures that are common or global for all games, or the Account itself.

When a Product is mapped to the Account system, this means that for each game, there are two Session objects retrieved, one for the k-ID Product mapped to the game, and one for the k-ID Product mapped to the Account system. The k-ID API is scoped to a Product by the API key. The correct API key must be used depending on whether you are trying to access the k-ID Product mapped to the Account system or the game.