Skip to main content

Multi-product approval

Multi-product approval allows you to present multiple products to parents for approval in a single consent flow. This reduces friction in the trusted adult consent process, making it easier for families to access your games and services while maintaining compliance with privacy regulations.

Benefits​

  • Reduced Trusted Adult Friction: Trusted Adults can approve multiple products at once instead of going through separate consent flows for each product
  • Improved Child Experience: Children gain access to multiple products simultaneously, reducing wait times and abandoned consent flows
  • Flexible Configuration: Choose which products to bundle together based on your platform architecture and user needs
  • Maintain Compliance: All products in a bundle maintain their individual permission settings and regulatory requirements

multi-product approval

Use cases​

Multi-product approval is ideal for:

  • Platform + Games: You have an account system or platform that multiple games depend on
  • Game Collections: You offer multiple related games that families typically want to access together
  • Tiered Access: You have core services and optional add-ons that can be approved simultaneously

Configuration options​

There are three ways to implement multi-product approval:

1. Product bundling (static configuration)​

Configure which products automatically appear together in consent flows through the Compliance Studio.

How to Configure:

  1. In the Compliance Studio, select your product
  2. Go to Configuration, and click Edit within the Multi-Product Approval section.
  3. Click the toggle next to Enable Multi-Product Approval
  4. Select which products to bundle with the current product
  5. Click Push to Test

multi-product approval

Trusted Adult Experience - When parents receive a consent request for the primary product, they'll automatically see the bundled products included. Trusted Adults can remove bundled products if they don't want to approve them.

Best for products that are commonly used together but don't have hard dependencies

2. Essential products (required dependencies)​

Mark another product as required for your product to function. This is typically used when your product depends on a platform or account system.

How to Configure:

  1. In the Compliance Studio, select your product
  2. Go to Configuration, and click Edit within the Multi-Product Approval section.
  3. Click the toggle next to Enable Multi-Product Approval
  4. Under Essential Product, select the product that must be approved alongside this product
  5. Click Push to Test

Trusted Adult Experience - The essential product can't be removed from the consent flow. Trusted Adults must approve both products together, or reject the consent request entirely.

Important Restrictions:

  • A product can only have one essential product
  • Essential products can't themselves require another essential product (no chaining)
  • Use this only for true dependencies, not just convenience

Best for products that can't function without access to another product (for example, a game that requires a platform account)

3. Dynamic bundling (API-based)​

Programmatically select which products to bundle at the time of creating a consent challenge with the API.

How to Use:

Call the /challenge/create-bulk API endpoint with the specific product IDs you want to include:

{
  "jurisdiction": "US-CA",
  "requestedProductIds": [123, 456, 789],
  "kuid": "12b9fa0e-6d6d-4903-a1fc-f2233027b71d"
}

Trusted Adult Experience - Trusted Adults see the specific bundle of products you've defined for this consent request.

Best for:

  • Contextual bundling based on user behavior
  • A/B testing different product combinations
  • Complex logic that determines which products to offer together

Best practices​

Choosing the right approach​

  • Use Bundling when products are often used together but don't have technical dependencies
  • Use Essential Products only when one product truly can't function without another
  • Use Dynamic Bundling when you need runtime flexibility or contextual product selection

Configuration tips​

  1. Start Simple: Begin with essential products only, then add bundling as needed
  2. Consider the Trusted Adult Journey: Don't overwhelm parents with too many products in one bundle
  3. Test Your Flows: Use Test Mode to verify the parent experience before going live
  4. Document Dependencies: Keep clear records of which products depend on others for your development team

Permission considerations​

When multiple products are bundled:

  • Trusted Adults see the union of all permissions from all products
  • Each product maintains its own permission configuration
  • Trusted Adults can allow or disallow permissions for each product individually
  • All data disclosures from bundled products are presented together

Common patterns​

Pattern 1: Account and multiple games​

Configuration:

  • Account System product (no essential product)
  • Game A: Account System as essential product
  • Game B: Account System as essential product
  • Game C: Account System as essential product

Result - Any game approval automatically requires account system approval, but parents can approve multiple games at once.

Account System Integration - When integrating with an account system that spans multiple games, it's typical to create one k-ID Product for each game, and then a separate k-ID Product for the Account System itself. 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.

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.

Pattern 2: Game suite with optional add-ons​

Configuration:

  • Main Game: No essential product
  • Expansion Pack A: Main Game as essential product, bundled with Main Game
  • Expansion Pack B: Main Game as essential product, bundled with Main Game

Result - Trusted Adults can approve the main game with optional expansions in one flow.

Pattern 3: Platform approach​

Configuration:

  • Platform Product: No essential product
  • Social Features: Platform as essential, bundled with Platform
  • Premium Content: Platform as essential, bundled with Platform

Result - Trusted Adults approve platform access, with easy add-ons for additional features.

Technical details​

Webhook events​

For detailed information about the webhook event structure, see Challenge.StateChange.

When parents approve a multi-product bundle, you'll receive separate Challenge.StateChange webhook events for each approved product. All sessions share the same kuid (k-ID user ID), allowing you to associate them with the same child.

Session management​

Each approved product in a bundle creates its own session with its own sessionId. You should:

  • Cache all sessions associated with a player's kuid
  • Use the appropriate session when checking permissions for each product
  • Query sessions using /session/get with the relevant sessionId or kuid and product API key

Using kuid for cross-product session access​

k-ID exposes a global identifier called kuid (k-ID User ID) for all players who have had trusted adult consent. 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.

When a trusted adult gives consent for a child to play one or more Products, the registered webhook endpoint for each approved product is invoked with eventType set to Challenge.StateChange. Each of the Session objects have the same kuid for the player. For more information about webhooks, see Webhooks.

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.

API endpoints​

Edge cases and considerations​

Age minimum requirements​

Important

The Rule - A child must meet the age requirements for all products in a bundle.

If an essential product has a higher age minimum than the product that depends on it, children below that age are denied access to both products.

Example:

  • Game A: Minimum age 10, requires Account System as essential product
  • Account System: Minimum age 13

Result - Children must be at least 13 to access Game A, even though Game A's configured minimum is 10.

Best Practice - Set the age minimum of dependent products to be equal to or higher than their essential product's age minimum.

Permission handling​

Important

The Rule - Trusted Adults must approve the most restrictive permission requirements across all bundled products.

When products are bundled together, k-ID evaluates each permission across all products and applies the most restrictive setting:

  • If a permission is required in any product, it becomes required for the entire bundle
  • If a permission is optional in one product but required in another, it becomes required
  • Trusted Adults must grant all required permissions to complete the consent flow

Example:

  • Game A: "Voice Chat" is optional (parent can choose)
  • Account System (essential to Game A): "Voice Chat" is required (parent must approve)

Result - Trusted Adults must approve "Voice Chat" to grant consent, even though Game A alone would have made it optional.

Best Practice:

  • Align permission requirements between dependent products when possible
  • Review the combined permission set that parents see
  • Consider whether certain permissions should be required at the platform level or game level