Account System Product

This guide explains how to implement the Account System Product (ASP) capability in k-ID. It allows your organization's central account or platform product to create authentication challenges and sessions on behalf of other products in your organization, using your Account System Product's API key and an optional header, without managing separate API keys per product.

Features

• Single API key: Your Account System Product uses its own API key for all cross-product calls; no per-product key management.
• Product-specific consent: When you create a challenge for another product, parents see only that product's data notices, permissions, and branding.
• Organization scoping: You can only act on behalf of products in the same organization; cross-org use is rejected.
• Full visibility: Both your Account System Product and the target product receive webhooks, with fields indicating who initiated the flow and on whose behalf.

Flow overview

Your Account System Product sends a request to one of the supported endpoints (/age-gate/check, /challenge/send-email, or /challenge/generate-otp) with the Kid-Target-Product-Id header set to the target (non–Account System Product) product's ID. The API validates that both products are in the same organization and that the caller is an Account System Product. The parent sees only the target product's configuration (notices, permissions, branding), not the Account System Product's. For each webhook event (for example, challenge state change), both the Account System Product and the target product receive the event: the Account System Product's payload includes onBehalfOfProductId, the target's includes initiatedByProductId.

Prerequisites

1. Account System Product flag: Your authentication/account product must have the Account System Product toggle enabled in Compliance Studio (Product Details → Information). Contact k-ID if the option isn't available for your organization.
2. Target products: The products you act on behalf of must be in the same organization and must have the Account System Product toggle disabled. You can only use the header for non–Account System Products.
3. API key: Use the API key of the Account System Product (the product with the toggle turned on). Don't use the target product's API key.

Step 1: Enable Account System Product in Compliance Studio

Enable the Account System Product setting for your designated product (for example, your central account or auth product) in Compliance Studio. Target products you act on behalf of keep their existing configuration; you don't need to create new products or API keys for them.

How to turn on Account System Product

1. In Compliance Studio, open Products in the left sidebar and select the product that acts as your Account System Product (the one that creates challenges and sessions on behalf of others).
2. Open the Information tab for that product.
3. In the Product Details section you'll see Account System Product (initially disabled). Click Edit (top right of the page).
4. Scroll to the Account System Product section at the bottom of the Product Details form. The description reads: "Enable this if this product can create challenges and sessions on behalf of other products."
5. Turn the Account System Product toggle on.
6. Click Push to Test to save and apply the configuration.

After this, that product's API key can be used with the Kid-Target-Product-Id header to perform actions on behalf of other products in the same organization.

Step 2: Call the API with the target product header

When your Account System Product needs to perform an action (such as an age gate check or creating a challenge) on behalf of another product, send the same request you would for your own product, and add the header:

Header	Value	Required
Kid-Target-Product-Id	The non–Account System Product ID (target product's k-ID product ID, positive integer)	Yes, when acting on behalf of another product

Use the Account System Product API key in the Authorization header. The request runs in the context of the target product, but authentication is with the Account System Product's key.

Example: Check age gate on behalf of a game

Your Account System Product checks whether the user can access a specific game (product ID 12345) without managing that game's API key:

POST /api/v1/age-gate/check
Content-Type: application/json
Authorization: Bearer ACCOUNT_SYSTEM_PRODUCT_API_KEY
Kid-Target-Product-Id: 12345

{
  "jurisdiction": "US-CA",
  "dateOfBirth": "2015-03-20"
}

As in the standard flow, the API returns a response that can include a URL when a challenge is required. That URL initiates the challenge for the target product (here 12345), not for the Account System Product. When the parent opens the URL, they see the target product's configuration (notices, permissions, branding), not the Account System Product's.

Example: Send challenge email on behalf of a product

Send a parental consent email for a challenge belonging to another product by including the header:

POST /api/v1/challenge/send-email
Content-Type: application/json
Authorization: Bearer YOUR_ACCOUNT_SYSTEM_API_KEY
Kid-Target-Product-Id: 12345

{
  "challengeId": "challenge-uuid",
  "email": "parent@example.com"
}

The email is sent in the context of product 12345; the parent sees that product's configuration when they complete the flow.

Endpoints that support Kid-Target-Product-Id

Only these endpoints accept the optional Kid-Target-Product-Id header when the caller is an Account System Product:

• /age-gate/check
• /challenge/send-email
• /challenge/generate-otp

If the header is omitted, the request applies to your own product (the Account System Product), as with a normal integration.

Multi-product approval

Account System Product works with multi-product approval. A common setup is to mark the Account System Product as an essential product of the target product (for example, a game). Then when you call /age-gate/check with your Account System Product API key and Kid-Target-Product-Id set to that game, the consent flow the parent sees can include both the game and the Account System Product in a single approval, so the parent approves the game and the platform together. Configuration is done in Compliance Studio on the target product: set the Account System Product as that product's essential product in the multi-product approval settings. For full options (essential products, bundling, dynamic bundling), see the Multi-product approval guide.

Step 3: Handle webhooks for cross-product flows

When your Account System Product initiates a flow on behalf of another product, each webhook event is sent to both endpoints in a pair: one to the Account System Product's webhook URL and one to the target (non–Account System Product) product's webhook URL. This happens for every event throughout the challenge lifecycle (for example, state changes), not only when the flow completes.

• Account System Product's webhook: includes onBehalfOfProductId (the target product ID you acted on behalf of).
• Target product's webhook: includes initiatedByProductId (the Account System Product ID that initiated the flow).

Event payloads use these fields so you can tell cross-product flows apart:

Field	Present on	Description
onBehalfOfProductId	Account System Product's webhook	The product ID you acted on behalf of (the target product).
initiatedByProductId	Target product's webhook	The product ID that initiated the flow (your Account System Product).

Example: Challenge.StateChange (account system side)

When the Account System Product's webhook receives a challenge state change for a flow it initiated on behalf of product 12345:

{
  "eventType": "Challenge.StateChange",
  "data": {
    "id": "9d6b056e-7d62-4a9e-907a-3d0f6f1d1b9a",
    "productId": 12345,
    "status": "PASS",
    "onBehalfOfProductId": 12345,
    "sessionId": "b6d1a7c2-8f34-4c83-bf0b-3a6d4a2f9d31",
    "approverEmail": "parent@example.com",
    "kuid": "7a1f2c3d-4e5f-6789-abcd-ef0123456789"
  }
}

Here productId and onBehalfOfProductId both refer to the target product. Your handler can use onBehalfOfProductId to know which product this consent was for.

Example: Challenge.StateChange (target product side)

The target product's webhook receives the same event with initiatedByProductId set to your Account System Product's product ID:

{
  "eventType": "Challenge.StateChange",
  "data": {
    "id": "9d6b056e-7d62-4a9e-907a-3d0f6f1d1b9a",
    "productId": 12345,
    "status": "PASS",
    "initiatedByProductId": 99999,
    "sessionId": "b6d1a7c2-8f34-4c83-bf0b-3a6d4a2f9d31",
    "approverEmail": "parent@example.com",
    "kuid": "7a1f2c3d-4e5f-6789-abcd-ef0123456789"
  }
}

99999 is the Account System Product's product ID. In the target product's payload, productId is the target product's own ID; initiatedByProductId identifies which Account System Product started the flow. The same dual delivery and field pattern applies to other webhook event types for that challenge (for example, session-related events). See Webhooks and Challenge.StateChange for full payload details.

Security and validation

• Organization check: The target product must belong to the same organization as your Account System Product. Requests for products in other organizations are rejected with 400 Bad Request.
• No ASP-to-ASP: The target product can't be an Account System Product. Such requests are rejected.
• API key: Only the Account System Product's API key can be used with Kid-Target-Product-Id. Using another product's key with this header returns 403 Forbidden.
• Header format: Kid-Target-Product-Id must be a positive integer. Invalid values return 400 Bad Request.

Typical flows

1. Unified account, multiple games
   Your platform is the Account System Product. When a user launches a game, your server calls the k-ID API with Kid-Target-Product-Id set to that game's product ID. Parents see only that game's consent; your Account System Product and the game both get webhooks.

2. Central auth service
   Your auth service is the Account System Product. It creates challenges and checks age gates for several client products (for example, games, apps) in the same organization. Each client product keeps its own Compliance Studio configuration and webhook URL.

3. Session and challenge consistency
   You can create challenges and retrieve sessions for the same target product using the same header on the relevant endpoints, so your Account System Product remains the single integration point while each product's compliance and UX stay independent.

Next steps

• Configure your Account System Product and target products in Compliance Studio.
• Use the API reference to confirm request/response shapes for the endpoints you use.
• Set up webhooks for both your Account System Product and target products, and handle onBehalfOfProductId / initiatedByProductId where needed.
• For multi-product consent flows (for example, essential products, bundling), see Multi-product approval.