What are the three verification layers?

Proof of work, browser instrumentation, and a gaming anti-cheat challenge. They run in series, so by the time a request reaches the game it has already paid the cost of every gate in front of it.

Do real visitors have to solve a puzzle?

They play a short game that takes a few seconds. Proof of work and browser instrumentation run invisibly in the background, so the visitor only ever sees the game.

Can Caputchin stop headless bots and AI solvers?

Yes. Browser instrumentation filters headless tools and scripts, proof of work taxes compute at scale, and the server-authoritative game with deterministic replay defeats solver farms and frontier AI models.

How do I check a result on my server?

The widget hands the browser a one-time token. Your backend calls the verify endpoint to confirm that token before trusting the request. The default path is the web component plus that one verify call.

What if the widget element does not fit my app?

Use the runtime API to drive verification yourself, hosted verification to point a form at us with no backend code, or the mobile WebView embed for native iOS and Android apps.

All features

Verification

Three layers of defense, Five surfaces, No bot can win

Verification is the core of Caputchin. The gates work together; the surfaces are how you plug them into your stack. The default path is the widget plus a verify call from your backend. The other surfaces are there when the default does not fit.

How a verification flows.

The visitor opens your page. The widget runs the gates. A signed token crosses to your backend. Your backend asks us to confirm it.

VisitorOpens your page
Caputchin widgetLoads in your page
Gaming anti-cheatRuns in a sandboxed iframe
Your backendReceives the wrapped token
/siteverifyCaputchin confirms the token

Same shape whether you ship the widget, call the API directly, or use hosted verification. The wrapped token is the only thing that crosses from the visitor's browser to your backend.

Threat matrix

Every plan

Each layer raises cost on a different attack.

No single layer is supposed to beat every attack alone. The point is composition: by the time a request reaches the game, it has already paid the tax of every gate in front of it. Honest map below.

How each verification layer addresses common bot attack patterns.
Attack pattern	Proof of work	Browser instrumentation	Gaming anti-cheat
Curl and fetch scriptsBare HTTP scripts hitting your endpoint directly.		Addresses this attack
Headless browsersPuppeteer, Playwright, or Selenium running in the background.		Addresses this attack
Real-browser bot farmsReal Chrome instances on rented servers, sometimes humans driving them.	Addresses this attack		Addresses this attack
Solver-as-a-servicePaid solver farms that take a challenge and hand back the answer, often cheap human labor.	Addresses this attack		Addresses this attack
Frontier AI modelsVision and agent models that read image grids, solve OCR puzzles, and clear legacy CAPTCHAs in milliseconds.			Addresses this attack

Curl and fetch scripts
Bare HTTP scripts hitting your endpoint directly.
Layers that address it
- Browser instrumentation
Headless browsers
Puppeteer, Playwright, or Selenium running in the background.
Layers that address it
- Browser instrumentation
Real-browser bot farms
Real Chrome instances on rented servers, sometimes humans driving them.
Layers that address it
- Proof of work
- Gaming anti-cheat
Solver-as-a-service
Paid solver farms that take a challenge and hand back the answer, often cheap human labor.
Layers that address it
- Proof of work
- Gaming anti-cheat
Frontier AI models
Vision and agent models that read image grids, solve OCR puzzles, and clear legacy CAPTCHAs in milliseconds.
Layers that address it
- Gaming anti-cheat

Gaming anti-cheat

Every plan

More than a game. A verification engine.

A tiny, varied game humans play in seconds and enjoy. Underneath, it runs the same anti-cheat playbook competitive multiplayer games use to catch cheaters: our servers set up every round before you play (server authority) and re-simulate it after (deterministic replay), so the game cannot be faked, only played. It is the layer no other CAPTCHA has, and the reason Caputchin exists.

Before you play

Server-authoritative setup

A signed, single-use ticket (30-minute window) mints the round. Spend it once and it can never be replayed.
The game and its random seed are chosen on our servers, never in the browser, so nothing client-side can pick an easier target.
A different game from the pool each time. A solver never knows which one it will face, so it cannot pre-train.

Same model as a competitive game server: the client sends only inputs, never the verdict.

After you play

Deterministic replay

Your exact inputs are replayed on our servers under the same seed, inside a sealed isolate with no network and a hard time budget.
Pass or fail is recomputed by that replay, never taken from the browser.
Every game's code is hash-checked before it runs, so the artifact cannot be swapped underneath you.

Built on the same determinism lockstep multiplayer relies on: the round is re-simulated from the seed to confirm it was really played.

Sandboxed in your page

An isolated iframe with no network and no reach into your cookies, storage, or DOM.

Game variety

Different sites get different games, and the catalog keeps growing.

Sealed replay

The replay runs with no network and a hard CPU budget. Nothing gets in or out.

Tamper-proof code

Each game artifact is verified by hash before a single frame runs.

No profiling

We do not watch your mouse or timing. We re-run the round instead.

Two more gates, stacked alongside

Gaming anti-cheat never works alone. A proof-of-work gate and browser instrumentation run with it, each raising cost on a different attack pattern. Composed in series, every layer the attacker reaches has already paid a tax.

Every plan

Proof of work

Every verification attempt forces the visitor's browser to run a small cryptographic puzzle. A human waits a few hundred milliseconds and never notices. A bot farm paying for compute at scale feels every cycle.

Where it fits

Sign-up forms targeted by automated account creation. Each fake account costs the attacker measurable compute, and bulk abuse becomes too expensive to be worth running.

Every plan

Browser instrumentation

The widget reads environment signals the visitor's browser exposes. Real browsers always have them. Headless tools and scripts usually fake them badly, or not at all. A per-site switch, automated-browser blocking, hard-rejects anything the instrumentation flags as headless or driver-controlled (Playwright, Selenium, Puppeteer). It is opt-in, so leave it off if you expect legitimate automation.

Where it fits

Comment forms and contact pages targeted by Playwright or Selenium scripts. With automated-browser blocking on, the script gets filtered at the door instead of being handed a challenge to solve.

Integration surfaces

Five ways to put verification in front of a visitor. Pick whichever fits the shape of your code, your stack, or your team.

Every plan

Drop-in web component

One HTML tag mounts the widget. It runs the gates and hands you a token when the visitor passes. Works in React, Vue, Svelte, Angular, or plain HTML, because web components are native to the browser and don't need a framework wrapper.

Where it fits

The default path. Add bot protection to your sign-up form in minutes without picking up a new dependency.

Every plan

Runtime API

The verification API has two parts. The verify call your backend uses on every integration to confirm a token is real. And the lower-level challenge endpoints to drive verification yourself, for the rare cases where the widget isn't a fit. Distinct from the REST management API your team uses for account and configuration changes.

Where it fits

Verify call: every backend, always. Direct API: chats, paywalls, multi-step forms woven through your own UI, anywhere the widget element can't render.

Every plan

Mobile WebView embed

A purpose-built embed page for native iOS and Android apps that render the challenge inside their WebView. Same widget, smaller footprint, no native SDK to install.

Where it fits

Mobile apps that need verification without shipping framework-specific SDKs or rebuilding a CAPTCHA flow native to every platform.

Alpha tier

Hosted verification

Point your form action at us. We verify the visitor, then forward submissions to your inbox or your endpoint. No backend code on your side at all.

Where it fits

Static sites and no-code builders that don't have a backend to verify tokens themselves. Ship a contact form with bot protection in the time it takes to swap a form action attribute.

Alpha tier

Proxy page-gate

A full-page verification that runs at your reverse proxy, in front of a whole site or route. One game solve clears the visitor for a while (a short-lived signed cookie), so they keep browsing without re-solving. The protected app needs no script tag and no backend hook.

Where it fits

Sealed apps you cannot embed a script into (an admin panel, an SSO portal, an internal tool). Gate the whole host at the proxy instead of touching the app.

Common questions

How Caputchin verifies a visitor, and the surfaces you plug it into.

What are the three verification layers?: Proof of work, browser instrumentation, and a gaming anti-cheat challenge. They run in series, so by the time a request reaches the game it has already paid the cost of every gate in front of it.
Do real visitors have to solve a puzzle?: They play a short game that takes a few seconds. Proof of work and browser instrumentation run invisibly in the background, so the visitor only ever sees the game.
Can Caputchin stop headless bots and AI solvers?: Yes. Browser instrumentation filters headless tools and scripts, proof of work taxes compute at scale, and the server-authoritative game with deterministic replay defeats solver farms and frontier AI models.
How do I check a result on my server?: The widget hands the browser a one-time token. Your backend calls the verify endpoint to confirm that token before trusting the request. The default path is the web component plus that one verify call.
What if the widget element does not fit my app?: Use the runtime API to drive verification yourself, hosted verification to point a form at us with no backend code, or the mobile WebView embed for native iOS and Android apps.

Ship verification on a single site key. Free.

Start free