Ask for the proof
Your application requests the proof required for an action — for example over 18 or human verified.
CHECKIFY FOR DEVELOPERS
Add age, human and identity verification through Checkify’s JavaScript tools, server verify API and supported platform plugins. Request the proof your application needs — Checkify handles the verification journey.
INTEGRATION MODEL
Your application asks for a proof. Checkify runs the customer journey. You receive a result and decide what happens next.
Your application requests the proof required for an action — for example over 18 or human verified.
Checkify determines whether sufficient proof exists or whether the customer needs to complete additional verification.
Your server confirms the result and allows, blocks or continues the protected action.
REAL API
After the customer completes a Pass session, your backend verifies the request_id with a site API key. Never put the site API key in browser code.
Request
POST /v1/qr/results/verify
Authorization: Bearer YOUR_SITE_API_KEY
Content-Type: application/json
{
"request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
"required_claims": ["age_over_18"],
"consume": true
}
Response
{
"success": true,
"status": "completed",
"approved_claims": {
"age_over_18": true
}
}
The browser or plugin stores a request_id (often as checkify_token). Your server is the authority — confirm approved_claims before allowing the action.
WHAT YOU CAN REQUEST
Change the request type or required claims for each journey — without rebuilding verification infrastructure.
Request an age threshold such as over 13, 16, 18 or 25.
age_over_18Establish that a real person is present for forms, login and abuse controls.
human_verifiedRequest the assurance level appropriate to risk — from basic through highAssurance.
basic → highAssuranceAssurance levels and exact evidence options depend on the journey, device and configured policy. See the server verify guide for claim names.
HOW YOU INTEGRATE
Start with the path that matches your stack. All production paths use the same proof model.
WordPress, WooCommerce and Joomla / J2Commerce for common CMS and checkout gates.
WordPress guide →CDN embed and bindForm for custom websites. Starts Pass sessions and writes the token into your form.
Embed docs →Confirm results with POST /v1/qr/results/verify and a site API key (csk_).
Server verify →Venue and device-to-device journeys using Pass and QR handoff.
Physical staff guide →Shopify and Wix are on waitlist / coming soon and are not listed as live production integrations here.
Credentials
Checkify uses two different credentials. Using the wrong one in the wrong place is the most common integration mistake.
Browser embed, WordPress, Joomla — frontend only.
Backend verify API — server only, never in JavaScript.
RESULT DELIVERY
For standard website and checkout flows, verify the request_id on your server when the protected action is submitted. Optional status polling is available for custom frontends.
Your page or plugin starts a Checkify Pass request bound to your site.
The customer verifies or approves in the Checkify app.
Call the verify endpoint, check approved_claims, then allow or block.
General-purpose verification webhooks are not required for standard integrations today. Partner outbound webhooks (for example GoHighLevel) are configured separately in the business dashboard.
DOCUMENTATION
Use these guides for implementation depth. This page stays focused on the integration model.
Embed a Pass and bind a form for your first protected action.
Open quickstart →Endpoints used by public integrations, including verify and status.
Open API docs →data-checkify attributes, bindForm options and request types.
Open embed docs →Site API keys, required_claims, consume and signed_result.
Open server guide →Add Checkify to one journey first — age, human or identity — then expand as your product needs grow.