FaceGUID
For organisations

Proof of human, as one API call.

Every face resolves to one global identifier — the same GUID on any device, in any country, next year. Ask FaceGUID whether the person in front of your product is a live human, and whether they are the same live human as last time. Get a signed answer in under a second.

One face, one GUID Signed ES256 proofs Single-use, replay-proof No biometric data leaves us

Bots cannot pass it

Three server-issued digits, spoken aloud, with lip articulation and voice cross-checked against each other. A scraped photo produces no mouth movement; a deepfake video cannot know digits issued two seconds ago.

One person cannot be a thousand

The GUID is derived from the face itself, so a second account needs a second face. Sybil resistance stops being a heuristic and becomes an identity property.

You never hold biometrics

Your systems receive a UUID and a signed assertion. No image, no video, no descriptor — which keeps face data out of your breach surface and out of your DPIA.

Where organisations put it

Account integrity

One signup per human. Kill multi-accounting, referral farming, review fraud and ban evasion at the point of registration rather than chasing them afterwards.

Step-up authentication

Re-verify before a wire transfer, a password reset, a privileged deployment. The face is the second factor, and it cannot be phished, SIM-swapped or shared.

Marketplaces & social

Badge real accounts. Rate-limit by human rather than by IP. Let people prove they are a person without publishing their name.

AI-era content provenance

Sign submissions, reviews and votes with a proof of human. When generated text is free and unlimited, a per-human signature is the scarce thing.

Remote workforce & exams

Confirm the person who started the shift, the exam or the interview is the one still at the keyboard an hour later.

Physical and hybrid access

The same GUID works at a kiosk, a turnstile or a service desk. One identifier across every channel, with no badge to lose.

The integration, end to end

Four steps
1
Register below. You get a client_id, a secret shown once, and the origins allowed to run the SDK.
2
Drop in the SDK. One script tag and one call. FaceGUID opens the camera on its own origin — you never request camera permission.
3
Send the token to your backend. It is opaque and useless on its own.
4
Verify it. One POST with your secret returns human: true, a stable subject, and the account age signals. The token is then spent.
Both halves, in full
<!-- browser -->
<script src="https://faceguid.com/sdk/faceguid.js"></script>
<script>
  const fg = new FaceGUID({ clientId: 'fg_YOUR_CLIENT_ID' });

  document.querySelector('#verify').onclick = async () => {
    const { nonce } = await (await fetch('/api/nonce')).json();
    const proof = await fg.proveHuman({ nonce });
    await fetch('/api/human', {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({ token: proof.token, nonce }),
    });
  };
</script>

// server
import { FaceGUIDServer } from 'https://faceguid.com/sdk/faceguid-server.js';

const fg = new FaceGUIDServer({
  clientId: process.env.FACEGUID_CLIENT_ID,
  clientSecret: process.env.FACEGUID_CLIENT_SECRET,
});

app.post('/api/human', async (req, res) => {
  const { human, sub, verifications, enrolled_at } =
    await fg.verifyProof(req.body.token, { nonce: req.body.nonce });

  if (!human) return res.status(403).end();
  await users.upsert({ faceSubject: sub, seenTimes: verifications });
  res.json({ ok: true });
});

Plans

A verification is one completed proof. Failed attempts are never billed.

Create your organisation

Your face is the credential. The person who signs the organisation up goes through the same ceremony their users will — which is both the demo and the security model.

Verify to continue
Why a face, to sign up a company

Credentials that mint proofs of human are worth stealing. Binding them to a face means a leaked password is not enough to issue verifications in your name, and every administrative action is attributable to a person rather than to a shared login.

You can add more admins afterwards by their FaceGUID, and remove them the same way. No seats to provision, no password policy to write.

Nothing about your face is stored in your organisation record — only the GUID it resolves to.