Skip to main content

14 posts tagged with "api"

View All Tags

Guides for transactions and payment-as-verification

Transactions and payment-as-verification now have full documentation on the developer hub.

What's new​

  • Transactions. Your product reports a child's purchases to k-ID, which surfaces them to the linked parent as a per-child Purchases view in Family Connect and in the recurring activity digest. Where you want a parent in the loop before a charge, a purchase-approval request asks them to approve it first, and the outcome arrives as the Transaction.PurchaseApprovalResult webhook. Both parts are configured per product in Compliance Studio.
  • Payment-as-verification. A completed card payment can stand in for the parental-consent step, mirroring the credit-card verification method one-to-one: it's honored exactly where that method is enabled for the session, credit-card funding only, and everywhere else the parent completes the standard verified parental consent flow unchanged.

Documentation​

Guides for verified parent linking, screentime, and activity ingestion

Three parent-controls capabilities now have full documentation on the developer hub: verified parent linking, screentime, and activity ingestion.

What's new​

  • Verified parent linking (VPL). A player can 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. VPL is a link, not a gate: nothing is blocked, and your product keeps working whether or not the parent accepts. The Session.Unlink webhook tells you when either side ends a link. VPL is enabled per developer organization.
  • Screentime. A parent sets daily limits, quiet hours, and break reminders for their child in Family Connect. Your product reports usage and honors the verdict k-ID returns; k-ID holds the rules, counts usage per child per day, and evaluates the schedule. Each limit is preceded by a warning event so a player can reach a save point, and a child can ask for more time through a screentime override.
  • Activity ingestion. Your product reports what a child did by pushing records against activity types you declare per product in Compliance Studio. k-ID stores and aggregates those records into the surfaces a trusted adult reads in Family Connect, including a recurring digest email. Activity is inbound only.

Documentation​

Protect essential product dependencies with a new mode on /session/delete

/session/delete can now protect (or clean up) other products that depend on the session being deleted.

What's new​

  • essentialDependencies on POST /session/delete. When a product is configured as essential to other products, deleting its session used to silently leave the dependent products' sessions behind, without the consent basis they relied on. The new field lets you choose what happens instead, on both the default revoke and hardDelete paths.
  • block refuses the delete instead of stranding a dependent. While the player still holds an active product that depends on the one being deleted, the call returns ESSENTIAL_DEPENDENTS_EXIST and names the dependent product IDs. No enablement needed.
  • cascade deletes the dependent sessions too, then the addressed session, each with its own webhook and (for hard deletes) its own deletion record. Opt-in per developer, because it removes sessions you didn't name (sending it without enablement returns FEATURE_DISABLED), and it requires a server-side API key rather than a client access token.
  • Every existing call is unaffected. Omitting the field, or sending ignore, behaves exactly as /session/delete always has, permanently. This is stable, opt-in surface, not a step ahead of a default change.

Documentation​

Email age estimation-only age verification endpoint

There is now a dedicated /age-verification/perform-email-age-estimation endpoint for running age verification with email age estimation as the only method, alongside the existing single-method endpoints (ID, AgeKey, ConnectID).

What's new​

  • POST /age-verification/perform-email-age-estimation. Bypasses automatic method selection and verifies the user with email age estimation only. It takes the same request shape as the other single-method endpoints (jurisdiction, subject, criteria, and optional options.redirectUrl / options.locale) and returns id, url, and shortUrl. The subject.email field is optional; if you omit it, the user provides their email on the hosted verification page.
  • 18+ signal. Email age estimation is an 18+ signal, not a precise age estimate. It can only establish that a subject is 18 or older and cannot distinguish younger age bands, so matching the request criteria to that capability is your responsibility.
  • Status and results unchanged. Poll /age-verification/get-status or handle the Verification.Result webhook as usual.

Documentation​

Permanently erase a session with a new flag on /session/delete

/session/delete can now permanently erase a session instead of only revoking it.

What's new​

  • hardDelete on POST /session/delete. Set to true to permanently delete a player session and its embedded consent, scoped to the calling product. Unlike the default revoke (which is internally retained), this physically removes the record and can't be undone.
  • Opt-in per developer. Available only to developers explicitly enabled for hard delete. Setting hardDelete: true without enablement returns FEATURE_DISABLED.
  • Every existing call is unaffected. Omitting hardDelete, or setting it to false, behaves exactly as /session/delete always has: a reversible revoke.
  • In-flight challenges are failed too. Any pending challenge tied to that exact session is set to FAIL, scoped to that session only (other sessions for the same player are untouched).

Documentation​

Credit card–only age verification endpoint

There is now a dedicated /age-verification/perform-credit-card-verification endpoint for running age verification with credit card as the only method, alongside the existing single-method endpoints (ID, AgeKey, ConnectID).

What's new​

  • POST /age-verification/perform-credit-card-verification. Bypasses automatic method selection and verifies the user with credit card only. It takes the same request shape as the other single-method endpoints (jurisdiction, subject, criteria, and optional options.redirectUrl / options.locale) and returns id, url, and shortUrl.
  • Adult (18+) assurance. Credit card verification is an adult assurance signal, not a precise age estimate. It is best suited to jurisdictions where card ownership is restricted to adults.
  • Status and results unchanged. Poll /age-verification/get-status or handle the Verification.Result webhook as usual; results report credit-card as the verification method.

Documentation​

Redirect URL for Automatic age assurance flows

/age-gate/check now accepts a redirect URL that k-ID navigates to once an Automatic age assurance challenge completes. This is intended for top-level browser handoffs (such as a mobile webview that bounces out to k-ID and back) where an iframe-based result handler isn't an option.

What's new​

  • options.playerAgeAssurance.redirectUrl. Pass an http(s) URL or a custom-scheme mobile deeplink (for example myapp://age-gate/return) on /age-gate/check. After the player completes or dismisses the CHALLENGE_AGE_GATE_AGE_ASSURANCE flow, k-ID redirects to that URL with challengeId, productId, sessionId (on PASS), and status (PASS or FAIL) appended as query parameters. Existing query parameters on the URL are preserved.
  • Scope. The option is only honored for CHALLENGE_AGE_GATE_AGE_ASSURANCE. CHALLENGE_PARENTAL_CONSENT is unaffected and continues to return through the trusted-adult flow.
  • Confirm outcomes server-side. The redirect query parameters are a UX hint. Treat the Challenge.StateChange webhook or /challenge/get-status as the source of truth before granting access.

Documentation​

Rate limits documentation

Default rate limits for the k-ID API and for user-facing age verification and parental consent flows are now documented on a dedicated page.

What's new​

  • API rate limits. Calls to the k-ID API are limited per product: 500 RPS in live mode and 10 RPS in test mode. Requests over the limit return HTTP 429 Too Many Requests.
  • Age verification and parental consent flow rate limits. User-facing flows are limited per product: 100 RPS in live mode and 20 RPS in test mode. When the limit is hit, the user sees an in-flow error asking them to wait and try again (no 429 is surfaced to your server).
  • Requesting an increase. These are defaults. Contact your k-ID representative if your product needs higher capacity.
  • Prelaunch checklists updated. Both the CDK and AgeKit+ prelaunch checklists now reference rate limits explicitly and link to the new page, since live mode ceilings are significantly higher than test mode.

Documentation​

Short URL field in age verification API responses

Age verification creation responses (from endpoints such as POST /age-verification/perform-access-age-verification) now include shortUrl in addition to id and url.

What's new​

  • Compact link: shortUrl is a shorter link that redirects to the same verification experience as the full url. Use it when a long query string is a poor fit, for example for QR codes or when the user completes verification on another device.
  • Full URL unchanged: The session JWT remains on the full url (token query parameter). Don't try to shorten or rebuild that URL yourself.
  • Opaque value: Treat shortUrl as an opaque string. Display or encode it as returned, and don't rely on a fixed path or query layout, which might change in the future.

Learn more​

Platform age signals documentation

We've published end-to-end documentation for platform age signals: how Apple iOS, Google Play, Xbox, Meta Horizon, and k-ID age data flows into k-ID, when the age gate can be skipped, and how verified versus unverified signals interact with high-risk permissions and age assurance.

What's New​

CDK — Platform age signals​

  • Platform age signals — Quick integration paths, API map, recommended request sequence, how POST /age-gate/check uses a platform signal, supported platforms and verified declaration types, and verified versus unverified signal behavior.
  • Platform signal details — Per-platform field shapes, how to obtain each native signal, endpoint-by-endpoint notes (get-requirements, check, get-default-permissions, session/get, get-platform-age-range, session/upgrade), validation, age conflicts, and k-id signal rules.

API reference (OpenAPI)​

Descriptions for session upgrade, AgeVerification, and platformAgeSignal now use verified platform signal wording consistently with the docs above.

Documentation​