One integration. Every jurisdiction's age claim.
Your product asks one question: may this viewer see this? ClaimKit answers with a signed over-18 claim, produced by whichever verification provider the viewer's regulator accepts, such as Yoti, Persona, or Epic KWS. Passports, selfies, and birthdates never touch your servers.
{
"iss": "https://api.claimkit.com",
"aud": "yourplatform.com",
"sub": "b3f1…9c2e", // anonymous id, unique to your site
"claim": "over_18",
"jurisdiction": "GB",
"method": "photo_id_match",
"assurance": "high",
"iat": 1783468800,
"exp": 1791244800
}
Age checks stopped being a UK problem in December.
Each jurisdiction accepts different providers and methods, and none accepts self-declaration. Platforms are wiring checks jurisdiction by jurisdiction, provider by provider, and carrying the identity data risk themselves.
The next deadline is a
policy, not a project.
UK today, Australia next, the EU after that. The age gate in your product and the claim your code checks stay the same. You switch on the new jurisdiction, connect a provider its regulator accepts, and ship.
A React gate, one backend route, one verification call.
Most teams ship this in about one engineering day. The developer kits are TypeScript, and the claim is an open format your team can check with ordinary web libraries.
Drop in the gate
<ClaimKitGate> from @claimkit/react wraps anything you need to protect: paywalled posts, DMs, calls, livestreams. A plain JavaScript client is also available.
Add one backend route
Your server identifies the logged-in user and starts a verification session with your secret key. The key that lives in the browser is read-only; it can never start sessions for other users.
The viewer verifies once
On ClaimKit's hosted page, against your own provider account. If a check comes back uncertain or a provider is down, ClaimKit moves to the next provider on your list. A genuine underage result never gets a second try.
You hold a signed claim
The gate unlocks once your servers confirm the claim is genuine, and your backend gets a signed notification. Returning viewers are recognized from a saved pass: no repeat verification, no conversion hit.
// the only backend code you must add import { ClaimKit } from '@claimkit/node'; const ck = new ClaimKit({ apiKey: process.env.CLAIMKIT_SECRET_KEY, }); export async function POST(req) { const userId = await currentUserId(req); const session = await ck.sessions.create({ policy: 'uk_osa_adult_content_v0', subject: { platform_user_id: userId }, surface: 'content_view', return_url: 'https://yourapp.com/members', }); return Response.json(session); }
@claimkit/react · @claimkit/browser · @claimkit/node · TypeScript, v0.1
What ends up on your servers, and what never does.
The point of the architecture: your platform learns one fact, not one identity. Evidence stays with the verification provider; ClaimKit itself stores no documents and no birthdates.
You hold
- ✓ A signed over-18 claim, tied to your domain
- ✓ An anonymous viewer id that means nothing anywhere else
- ✓ Signed notifications confirming each outcome
- ✓ A tamper-evident audit trail you can export for your compliance file
You never hold
- ✕ Passports or identity documents
- ✕ Selfies or face-scan data
- ✕ Birthdates or ages (you hold only the yes-or-no fact)
- ✕ The provider's raw verification data
Built for the questions your privacy and legal teams will ask.
- Viewers can't be tracked across sites
- Each viewer's id is scrambled differently for every customer. The same person shows up with a different id on every platform, so neither ClaimKit nor its customers can connect viewers across sites. That holds by construction, not by policy.
- Failover that can't be gamed
- Uncertain results and provider outages roll over to the next provider on your list, so an outage doesn't cost you conversions. A genuine underage result never rolls over, so a declined viewer can't shop around for a provider that lets them through.
- Deletion without losing your defense
- When a user asks to delete their proof, the claim is revoked, but a record that a high-assurance check occurred is retained, with no personal data in it. You can honor deletion requests and still show a regulator the check happened.
- Your servers check claims themselves
- A claim's signature can be verified with standard web libraries, on your own servers. There's no call to ClaimKit on every page view, and no lock-in on the claim format itself.
- Your provider contracts, your rates
- ClaimKit runs on your own Yoti, Persona, or Epic KWS account. Your provider relationship, pricing, and data-processing agreements stay yours; ClaimKit adds the claims, routing, and audit layer on top.
- Evidence on demand
- Every check, outcome, and revocation lands in a tamper-evident audit trail with no personal data in it. Export it per user or per period when a regulator, payment processor, or app store asks what your age checks actually did.
Keep your provider. That part works.
ClaimKit runs on your existing provider account, so this isn't a rip-and-replace pitch. The contract you negotiated, your rates, and your data-processing agreement all stay exactly where they are.
What a direct integration usually leaves out is the layer around the check: returning viewers get re-verified (and re-billed) because there's no pass for them to hold, access rules are hand-written for every corner of the product, and a second jurisdiction means a second project. That's the part ClaimKit adds on top of the provider you already trust: viewers verify once and are recognized after, and the next jurisdiction becomes configuration rather than engineering.
In private pilot. Deliberately.
We're a small team onboarding a limited number of design partners: platforms under active UK enforcement pressure, or facing their second jurisdiction. No logos wall, no invented quotes. If the architecture above solves a problem you have, we'd like to talk.
The full flow works today: hosted verification page, signed claims, notifications to your backend, provider failover, and the audit trail. TypeScript developer kits are published (v0.1), and the whole flow is covered by automated tests.
Yoti, Persona, and Epic Kids Web Services, running on your own provider account. Getting set up with a provider is part of the pilot.
One part of your product gated in your staging environment within a week, a shared Slack channel, and direct access to the people writing the code. Pricing worked out together, in the open.
Or reply to the email that sent you here; it goes to the same person.