Platform overview
A managed trust layer between the browser and your backend.
HumanProof keeps the challenge backend behind the platform, maps public site keys to internal challenge keys, applies domain and plan checks, enriches challenge starts with risk signals, and gives your server one simple verification endpoint.
Loads widget.js and sends challenge requests with widget context.
Checks project, domain, plan, billing, and risk rules before proxying.
Issues and redeems proof-of-work challenges through internal project keys.
Records protected attempts, outcomes, risk reasons, and usage history.
Verifies humanproof-token with the backend secret before accepting the action.
Challenge engine
The browser never talks directly to the private challenge backend. It calls the HumanProof project endpoint with the public site key. HumanProof translates that into the internal challenge key, forwards the request, and returns only the challenge payload or redemption result needed by the widget.
| Challenge start | The widget asks for a challenge. HumanProof checks project state, origin, plan capabilities, limits, billing, and risk mode first. |
|---|---|
| Challenge redeem | The widget submits the proof result. Successful and failed redeem attempts are tracked as protected attempts. |
| Siteverify | Your backend verifies the token after the form submit. This confirms the browser-side challenge result without exposing internal challenge secrets. |
Risk signals
The HumanProof widget sends lightweight interaction signals with challenge starts, such as trigger type, widget variant, elapsed time, focus and blur counts, keyboard activity, pointer activity, and page visibility. These signals help identify suspicious automation without replacing server-side verification.
Signals are recorded and shown in usage/risk views, but HumanProof still forwards eligible challenges.
Requests that exceed the project preset threshold can be blocked before the challenge engine is called.
Balanced, strict, and custom project settings control challenge difficulty and risk blocking thresholds.
Protection presets
Protection presets combine challenge-engine settings with HumanProof risk scoring thresholds. They let you tune friction and enforcement without editing code for every form.
| Preset | Challenge profile | Risk threshold | Best for |
|---|---|---|---|
| Relaxed | Difficulty 3, 60 challenges, lighter obfuscation, higher rate limit. | Blocks at 8.0 / 10 when enforce mode is enabled. | Low-risk forms, internal flows, or trusted traffic. |
| Balanced | Difficulty 4, 80 challenges, default obfuscation, standard rate limit. | Blocks at 6.0 / 10 when enforce mode is enabled. | Most public contact, signup, and lead forms. |
| Strict | Difficulty 5, 120 challenges, stronger obfuscation, lower rate limit. | Blocks at 4.0 / 10 when enforce mode is enabled. | Login, registration, checkout, and abused endpoints. |
The preset still tunes the challenge engine. Risk scores are recorded but not used to block requests.
The same preset also defines the risk score where HumanProof can block before the challenge engine is called.
Domain and plan gates
Before a challenge is issued, HumanProof verifies that the request origin matches a configured production or testing domain, the project is active, billing allows traffic, monthly usage is available, and the requested widget variant or branding is allowed by the organization plan.
Usage accounting
A protected attempt is counted when the challenge flow produces value: a solved challenge, a failed redeem, or an enforced risk block. Backend siteverify calls do not double-count the same browser solve; they are tracked separately as verification analytics.
Security boundary
The browser is responsible for rendering the widget and obtaining a token. Your backend is responsible for deciding whether the protected action continues. Never trust a client-side widget state alone; always verify the submitted token with your backend secret.