Skip to main content

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​

Mobile Integration Guidance for Widgets and Age Verification

We've updated the documentation to clarify how k-ID is best integrated on mobile: for the age gate and consent steps, a natively built UX gives players the most seamless experience, and web embeds such as the age verification and age assurance URLs are displayed through system browser surfaces.

What's New​

Mobile Guidance for Age Gate and End-to-End Widgets​

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.

Reworked Mobile Apps Guide​

The Mobile apps guide has been re-centered on age verification, the most common web embed on mobile:

Default Browser Method​

A 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.

Device Orientation Guidance​

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.

Updated Documentation​

Next Steps​

  • If you're integrating on mobile, consider building your age gate and consent UX natively using the custom workflow and CDK UX guidelines for the most seamless experience
  • Use the default browser method for landscape-locked apps when displaying verification URLs

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​

Official k-ID Agent Skills bundle for AI coding agents

k-ID now publishes an official bundle of Agent Skills — small, composable instruction packs that teach an AI coding agent how to integrate k-ID correctly across every jurisdictional regime k-ID supports: COPPA (US), GDPR-Kids (EU), UK AADC, the UK Online Safety Act, Brazil ECA Digital, Australia Online Safety / social media minimum age, and other regional requirements. They work with 35+ AI coding tools, including Claude Code, Cursor, OpenAI Codex, GitHub Copilot, and Gemini CLI.

What's new​

  • Eight focused skills cover the k-ID integration surface end-to-end: age gate, parental consent, age verification and assurance (including verifiedAgeThreshold flows for high-risk permissions), sessions and permissions, webhooks, plus cross-cutting adjuncts for server trust boundary and mobile/native.
  • Cross-jurisdictional by design. The same skills drive integrations for COPPA, GDPR-Kids, UK AADC, UK OSA, Brazil ECA Digital, and Australia Online Safety — jurisdictional behaviour is configured server-side in Compliance Studio, not branched in client code.
  • One-command install for Claude Code via the plugin marketplace; one-line git clone for all other compatible tools.
  • Open standard — the skills follow the Agent Skills specification and work with any compatible agent, not just one vendor.
  • Doc-first contract — skills encode integration patterns and known pitfalls, and link back to this documentation site for API shapes, so they never drift out of sync with the API.

Try it​

Learn more​

AI products quick start guide

A new quick start guide for AI-specific products is now available, alongside an AI permissions category in the Compliance Studio reference.

What's new​

  • AI products quick start. Walks you through end-to-end integration for AI products: configuring AI permissions in Compliance Studio, collecting parental consent, gating AI features, and responding to permission changes.
  • AI permissions category. The permissions reference now lists the AI category with its seven permissions: ai-chat, ai-media-generation, ai-voice-mode, ai-memory, ai-companion-chatbot, ai-media-upload, and ai-model-training.

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​