Skip to main content

PROHIBITED status documented for age gate widget redirects

The age gate and end-to-end widgets return 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.

What's new​

CDK: Embedded flow​

  • Receiving the result on the redirect URL: New section covering the redirectUrl callback query parameters (status, sessionId, challengeId, age) for both the age gate and end-to-end widgets, with a below-minimum-age example.
  • The event-handling example now branches on all three statuses (PASS, FAIL, PROHIBITED).

Event reference​

  • Widget.AgeGate.Result: Added a status-values table (PASS / FAIL / PROHIBITED), the data.age field returned on PROHIBITED, and a PROHIBITED example.

API reference (OpenAPI)​

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.

Documentation​

Verification results now name the vendor

Verification.Result webhooks and GET /age-verification/get-status now return provider, the vendor that ran the verification method.

What's new​

  • provider on both the webhook and the endpoint. Present whenever method is present, so a completed verification tells you which vendor produced the result.
  • A method doesn't imply a vendor. 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.
  • Nothing else changes. Every other field keeps its shape and presence rules.

Documentation​

New webhook for parent email address changes

A parent can change the email address on their k-ID account, and the new Session.ApproverEmailUpdate webhook tells your product when they do.

What's new​

  • 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.
  • Nothing else about the session changes. It stays 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.
  • Only children who have an active session. A child with no active session in your product has nothing to move, so no event fires for them. If that child later gets a session, it's created against the new address.
  • Opt in per endpoint. Select 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.

Documentation​

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​

Version history and rollback in Compliance Studio

Every configuration a product has published is now kept and listed, and an administrator can point Live back at a configuration it served before without waiting on k-ID.

What's new​

  • The History tab. A product now has a History tab holding two sections. Activity lists everything that has happened to the product, and any entry that changed the configuration carries a View changes link showing exactly what that one entry changed. Versions lists every configuration published to Live and to Test, newest first, with the one being served marked Current.
  • Rollback. The version Live is serving offers Rollback, which repoints Live at the configuration published before it. It doesn't create a new version, so numbering is unaffected and the version you rolled off stays in the list and can be made current again. A rollback takes effect within minutes, with no review step, so the confirmation shows the full diff of what Live would serve.
  • Reset to published. A working copy with unpublished edits can be reset back to whatever Live or Test is serving, previewed the same way. This is separate from a rollback: a rollback changes what players are served and leaves your working copy alone, a reset does the opposite.
  • Naming a version. Versions can be given a name, so Live v7 can also read as "pre-launch tuning" when someone comes looking a month later.

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​

Google Play Age Signals v0.0.4 `ageRangeSource` is now accepted

k-ID now accepts the ageRangeSource value from Google Play Age Signals v0.0.4 as the declarationType on a google-play platform age signal.

What's new​

  • 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.
  • Deprecated 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.

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​

Apple iOS "confirmed" age signals are now accepted

k-ID now accepts Apple's confirmed declaration type as a verified platform age signal for players on iOS 26.5 and later.

What's new​

  • 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.
  • Deprecated types still work. Apple deprecated 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.

Documentation​