Add Lifecheck to your site.

Quickstart

The whole flow, top to bottom:

<!-- 1 · load Lifecheck once (in your <head> or before </body>) -->
<script src="https://swiftaw.com/lifecheck/lifecheck.js" async defer></script>

<!-- 2 · put the widget inside the form you want to protect -->
<form method="POST" action="/signup">
  <input name="email" type="email">

  <div class="lifecheck" data-sitekey="YOUR_SITE_KEY"></div>

  <button type="submit">Create account</button>
</form>

Lifecheck auto-renders the .lifecheck element, sizes its own frame, and injects a hidden <input name="lifecheck-token"> so the token rides along with a normal form POST. Then verify it on your server. That's the entire integration.

Site & secret keys

Lifecheck uses a key pair, one public and one private:

Register your domain with Swiftaw to receive a pair. Keys look like lc_site_xxx and lc_secret_xxx.

1 Add the widget

Load the script once per page, then place a container. You can configure it entirely with data- attributes:

<div class="lifecheck"
     data-sitekey="YOUR_SITE_KEY"
     data-callback="onLifecheckPass"
     data-expired-callback="onLifecheckExpired"></div>

See every attribute in the data-attribute reference. Prefer to render manually, say inside a modal that opens later? Skip the auto-render and call the API yourself:

<div id="check"></div>

<script>
  Lifecheck.render("check", {
    sitekey: "YOUR_SITE_KEY",
    callback: function(token){ console.log("passed:", token); }
  });
</script>

2 Read the token

On a successful check, Lifecheck gives you the token three ways. Use whichever fits:

• Hidden field. A <input name="lifecheck-token"> is added inside the container, so a plain form POST already carries it.
• Callback. Your data-callback function is invoked as callback(token, widget).
• DOM event. The container emits a bubbling lifecheck:verified event with detail.token.

Or pull it on demand:

const token = Lifecheck.getResponse();   // "" until verified

// e.g. gate an AJAX submit
form.addEventListener("submit", async (e) => {
  const t = Lifecheck.getResponse();
  if (!t) { e.preventDefault(); alert("Please complete the check."); }
});

3 Verify on your server

The client token proves nothing on its own. Always confirm it from your backend (never browser JS, or you'll leak your secret and hit CORS). Verification is a single call to Lifecheck's function endpoint with your secret key and the token:

curl -X POST \
  "https://mwszvynzzugbowdngzab.supabase.co/rest/v1/rpc/lifecheck_verify_token" \
  -H "apikey: sb_publishable_dqsqX2klo1j4xSyEFA7O1w_UjM8lEGf" \
  -H "Content-Type: application/json" \
  -d '{ "p_secret": "YOUR_SECRET_KEY", "p_token": "THE_TOKEN_FROM_THE_BROWSER" }'

// server-side only - keep YOUR_SECRET_KEY out of the browser
const res = await fetch(
  "https://mwszvynzzugbowdngzab.supabase.co/rest/v1/rpc/lifecheck_verify_token", {
  method: "POST",
  headers: {
    "apikey": "sb_publishable_dqsqX2klo1j4xSyEFA7O1w_UjM8lEGf",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    p_secret: process.env.LIFECHECK_SECRET,
    p_token: req.body["lifecheck-token"]
  })
});
const data = await res.json();
if (!data.success) return res.status(400).send("Failed Lifecheck");

$r = file_get_contents(
  "https://mwszvynzzugbowdngzab.supabase.co/rest/v1/rpc/lifecheck_verify_token", false,
  stream_context_create(["http" => [
    "method"  => "POST",
    "header"  => "apikey: sb_publishable_dqsqX2klo1j4xSyEFA7O1w_UjM8lEGf\r\nContent-Type: application/json",
    "content" => json_encode([
      "p_secret" => $SECRET,
      "p_token"  => $_POST["lifecheck-token"]
    ])
  ]]));
$ok = json_decode($r)->success;

Response

{
  "success":      true,
  "score":        0.85,                  // 0..1, real as of v1.3
  "passed":       "signals",             // "signals" | "challenge" | "signals-invisible"
  "mode":         "checkbox",            // "checkbox" | "invisible"
  "challenge_ts": "2026-07-31T18:04:11Z",
  "hostname":     "yoursite.com",
  "v":            "1.3",
  "error-codes":  []
}

No backend? Verify in the browser safely

A direct browser call to the verify RPC fails CORS on purpose - it stops you shipping your secret to the client. For a fully static site, deploy the lifecheck-verify Edge Function (in supabase/functions/): the browser sends only the public site key + token, and the function looks up the secret server-side and returns a CORS-enabled verdict. Your secret never leaves Supabase. Try it live on the token verifier.

// deploy once:  supabase functions deploy lifecheck-verify --no-verify-jwt
const r = await fetch(
  "https://mwszvynzzugbowdngzab.supabase.co/functions/v1/lifecheck-verify", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ sitekey: "lc_site_...", token: Lifecheck.getResponse() })
});
const verdict = await r.json();   // { success:true, passed:"challenge", ... }

Data-attribute reference

JavaScript API

Everything hangs off the global Lifecheck object.

Verify endpoint

POST /rest/v1/rpc/lifecheck_verify_token (JSON body) request parameters:

Send Lifecheck's public API key (sb_publishable_dqsqX2klo1j4xSyEFA7O1w_UjM8lEGf - the same for everyone, not one of your own keys) in the apikey header. The endpoint accepts cross-origin requests, but call it from your backend so p_secret never reaches a browser.

Response fields:

Error codes

Invisible mode v1.3

Add data-size="invisible" and Lifecheck draws nothing at all. Call Lifecheck.execute() at the moment you actually need a human - on submit, usually. Most visitors never see a thing; the ones the check isn't sure about get a challenge that unfolds in place.

<div class="lifecheck"
     data-sitekey="YOUR_SITE_KEY"
     data-size="invisible"
     data-callback="onPass"></div>

<script>
  // the token arrives here, exactly as in checkbox mode
  function onPass(token){ form.submit(); }

  submitBtn.addEventListener('click', function(e){
    e.preventDefault();
    Lifecheck.execute();
  });
</script>

The container gets data-lifecheck-expanded="true" and fires a lifecheck:expand DOM event when a challenge appears, so you can make room for it. Leave the element where the challenge should show up.

Frame events (advanced)

Under the hood the sandboxed widget talks to the loader over postMessage. You normally never touch this (the loader turns it into the callbacks above), but for custom hosts, messages are shaped:

{ source: "swiftaw-lifecheck", v: "1.3", event: "verified", token: "LC1.3_…" }
{ source: "swiftaw-lifecheck", v: "1.3", event: "resize",   height: 74 }
{ source: "swiftaw-lifecheck", v: "1.3", event: "ready" }
{ source: "swiftaw-lifecheck", v: "1.3", event: "error",   code: "sitekey-rejected", message: "…" }
{ source: "swiftaw-lifecheck", v: "1.3", event: "expand" }   // invisible mode wants a challenge
{ source: "swiftaw-lifecheck", v: "1.3", event: "collapse" } // …and is done with it

Testing aids v1.3

Two query parameters on the frame make a widget easier to look at while you're wiring it up. Both only affect what you can see - neither makes a check easier to pass.

Anti-theft model

People ask how they can integrate Lifecheck without being able to just copy it. Here's the honest answer:

• The detection logic and the five challenges live in embed.html, served only from swiftaw.com and loaded inside a sandboxed <iframe>. Integrators embed a URL, not a re-hostable copy of the checks.
• Tokens are minted server-side. When a visitor passes, the widget asks Swiftaw to issue a token, which only happens if your site key still exists and the host is on its allow-list. A copied widget with no valid key gets nothing back.
• Live revocation. Delete a key and token issuance stops that instant, and the secret-side verify can no longer find the key. Pages already open can't keep verifying - no reload required.
• The token is single-use and useless until your secret key verifies it. A stolen widget shell can't produce tokens that pass your server check.

Changelog

Ready to wire it up? Jump back to the quickstart or see the overview.