status=PROHIBITED when a player is below your product's minimum age. That status is now documented on the widget redirect URL, in the Widget.AgeGate.Result event, and in the API reference, so you can reliably detect and block below-minimum-age players.
redirectUrl callback query parameters (status, sessionId, challengeId, age) for both the age gate and end-to-end widgets, with a below-minimum-age example.PASS, FAIL, PROHIBITED).Widget.AgeGate.Result: Added a status-values table (PASS / FAIL / PROHIBITED), the data.age field returned on PROHIBITED, and a PROHIBITED example.redirectUrl descriptions for /widget/generate-age-gate-url and /widget/generate-e2e-url now list PASS, FAIL, and PROHIBITED, and explain that PROHIBITED appends the entered age and creates no session.Treat the redirect and event status as a UX hint: confirm the outcome server-side via the Challenge.StateChange webhook or /session/get before granting access.
Verification.Result webhooks and GET /age-verification/get-status now return provider, the vendor that ran the verification method.
provider on both the webhook and the endpoint. Present whenever method is present, so a completed verification tells you which vendor produced the result.age-estimation-scan is served by several, and credit-card carries the merchant of record when a payment stood in for the check. Use provider for your own logs and analytics, not for access-control decisions.Session.ApproverEmailUpdate webhook tells your product when they do.
Session.ApproverEmailUpdate. Emitted once per child session when a parent commits an email change, so your server can update the parent email you store against that player. The payload carries id (the session), productId, oldEmail, and newEmail.ACTIVE, keeps the same sessionId and permissions, and the child carries on uninterrupted. Don't send the player back through the age gate or consent.Session.ApproverEmailUpdate for your webhook endpoint on the product's Developer Settings page in Compliance Studio, or k-ID drops the event without a delivery attempt or an error. It's listed only once parent email change is enabled for your organization.Transaction.PurchaseApprovalResult webhook. Both parts are configured per product in Compliance Studio.Session.Unlink webhook tells you when either side ends a link. VPL is enabled per developer organization.Live v7 can also read as "pre-launch tuning" when someone comes looking a month later./session/delete can now protect (or clean up) other products that depend on the session being deleted.
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.ignore, behaves exactly as /session/delete always has, permanently. This is stable, opt-in surface, not a step ahead of a default change.ageRangeSource value from Google Play Age Signals v0.0.4 as the declarationType on a google-play platform age signal.
ageRangeSource on the google-play signal. Google Play Age Signals v0.0.4 replaced userStatus with ageRangeSource. Provide the ageRangeSource value from the Google Play age signals responses as the declarationType on your PlatformAgeSignal when you call the age gate and session endpoints.userStatus values still work. k-ID continues to accept the legacy userStatus values for stores still on the earlier schema, so signals from apps that haven't migrated are unaffected./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).
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./age-verification/get-status or handle the Verification.Result webhook as usual.confirmed declaration type as a verified platform age signal for players on iOS 26.5 and later.
confirmed is a verified Apple declaration type. Starting in iOS 26.5, Apple's Age Range Service returns only selfDeclared, guardianDeclared, or confirmed, where confirmed means the age range was set using a scrutinized method such as a credit card or government ID. k-ID treats confirmed as verified, so it can suppress the age gate, satisfy verification thresholds, and record an ageVerification.paymentChecked, governmentIDChecked, guardianPaymentChecked, and guardianGovernmentIDChecked. k-ID continues to accept these for backwards compatibility, so signals from earlier iOS versions are unaffected.selfDeclared and guardianDeclared remain unverified. They don't bypass age verification requirements.The age gate and end-to-end widgets are fully supported on mobile. For the age gate and consent steps, we encourage building the UX natively with the custom workflow, following the CDK UX guidelines, for the most brand-integrated experience.
The age verification and age assurance URLs returned by the k-ID API are displayed the same way. See the mobile apps guide for the specific endpoints and challenge types.
The Mobile apps guide has been re-centered on age verification, the most common web embed on mobile:
/age-verification/perform-access-age-verificationVerification.Result DOM event and server-side confirmation via /age-verification/get-statusA default external browser method has been documented under the mobile implementation methods. It works on both Android (Intent.ACTION_VIEW) and iOS (UIApplication.open), fully supports AgeKeys, and returns focus to your app through the redirectUrl callback.
Age verification works best in portrait orientation. Because in-app browser surfaces inherit your app's orientation lock, apps with a locked landscape orientation should open the verification URL in the default external browser. The browser manages its own orientation, so users can rotate to portrait, and the redirectUrl callback returns them to your app when the flow completes.
/session/delete can now permanently erase a session instead of only revoking it.
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.hardDelete: true without enablement returns FEATURE_DISABLED.hardDelete, or setting it to false, behaves exactly as /session/delete always has: a reversible revoke.FAIL, scoped to that session only (other sessions for the same player are untouched)./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).
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./age-verification/get-status or handle the Verification.Result webhook as usual; results report credit-card as the verification method./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.
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.CHALLENGE_AGE_GATE_AGE_ASSURANCE. CHALLENGE_PARENTAL_CONSENT is unaffected and continues to return through the trusted-adult flow.Challenge.StateChange webhook or /challenge/get-status as the source of truth before granting access.verifiedAgeThreshold flows for high-risk permissions), sessions and permissions, webhooks, plus cross-cutting adjuncts for server trust boundary and mobile/native.git clone for all other compatible tools.github.com/kidentify/skills.ai-chat, ai-media-generation, ai-voice-mode, ai-memory, ai-companion-chatbot, ai-media-upload, and ai-model-training.429 Too Many Requests.429 is surfaced to your server).Adult, Teen, Child, or Passes / Fails Age Check), enter a custom age range or date of birth, and simulate Inconclusive or Fraudulent failures. Submissions flow through the same server path as real providers, so webhooks, sessions, and DOM events behave identically.Fallback only, in addition to enabled or disabled.
Fallback only: A method with this setting is offered only after the user has attempted another verification method and that attempt didn't produce an age signal (no conclusive age determination). It won't appear in the initial list of methods.POST /age-verification/perform-access-age-verification) now include shortUrl in addition to id and url.
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.url (token query parameter). Don't try to shorten or rebuild that URL yourself.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.