The premise
A job-application page where the candidate's submission is gated on a successful Polyguard Trust Check. The form is built in Jotform; the submission is held in the browser until the candidate has verified their authentic identity, location, and on-device attestation through the Polyguard SDK.
Use this as a reference for Talent / Recruiting integrations — wherever a business needs to confirm the person on the other end of an application is real before accepting their data into the pipeline.
The flow
- The page fetches your Jotform via Jotform's JS Embed endpoint (
/jsform/<FORM_ID>) server-side, evaluates the script in a sandbox, and renders the resulting HTML inline. The form lives same-origin in our DOM — no iframe, so no cross-origin restrictions to work around and nothing to paste inside Jotform. - Jotform's native submit button is hidden on mount. The only path forward is the page-level “Submit with Polyguard” button.
- Clicking the button opens the Polyguard SDK modal. The candidate completes a Trust Check on their phone (face + document + region + on-device attestation — biometric data never leaves their device).
- The SDK resolves with a verification bundle. The page polls
/api/status/{linkUuid} until the matching encrypted webhook lands at /api/webhook and is decrypted server-side. - On
trust_check.completed, the page packs the verified claims into the form's hidden polyguard_jwt input, builds FormData, and POSTs it to Jotform's submission endpoint. The submission appears in your Jotform Inbox exactly as a native submission would.
The SDK integration
A single client component dynamically imports @polyguard/sdk and calls client.verify():
const { PolyguardClient } = await import('@polyguard/sdk');
const client = new PolyguardClient({
appId: process.env.NEXT_PUBLIC_POLYGUARD_APP_ID,
apiServer: 'api.polyguard.ai',
requiredProofs: ['pg_presence'],
scanType: 'multi',
});
const response = await client.verify(
'pg-qr-target',
/* rawJwt */ true,
);
The dynamic import() keeps the SDK (and its bundled deps — qrcode, reconnecting-websocket, superagent) out of the initial page chunk and out of SSR.
What Polyguard Mobile does
When the candidate scans the QR (or taps the deep link), Polyguard Mobile runs a fused identity verification — up to four factors confirmed in a single Trust Check:
- Person — 3D depth facial recognition on the candidate's device.
- Document — NFC chip verification of the government ID. Not OCR.
- Device — Apple AppAttest or Google Play Integrity confirms a real, untampered phone.
- Location — GPS plus PG-Presence optical distance bounding confirms the candidate is physically there, in real time.
Biometric data never leaves the device. The recruiter never sees it. Polyguard never stores it.
The webhook side
In parallel with the SDK response, Polyguard's backend posts an AES-256-GCM-encrypted webhook to /api/webhook. The route decrypts it with POLYGUARD_WEBHOOK_SECRET, checks the replay window, and stores the payload by link_uuid (Upstash Redis in production, in-memory map for next dev).
The browser polls /api/status/... for the matching payload. This split is on purpose: the SDK response is fast enough for UX, the encrypted webhook is tamper-evident enough for the audit trail.
Why this matters for hiring
Application fraud and identity-fronted talent rings are a growing problem for recruiting teams — and an even bigger one for the companies who hire those candidates. Confirming the person behind the application before their data enters the ATS pipeline closes that attack surface at the funnel stage, without adding friction for legitimate candidates.