Test Site Keys

Prosopo reserves two well-known site keys that always produce the same outcome. Use them in end-to-end tests, CI pipelines and local development when you need the widget to behave deterministically instead of running a real challenge.

Never use these in production

These keys weaken protection by design: anything guarded by the always-pass key is guarded by nothing at all. The widget renders a visible warning banner and logs a console warning whenever one of them is configured, so a test key cannot reach production unnoticed.

The keys

Section titled The keys

Purpose	Site key	Result
Always pass	5EARALUe4HXQwKo5KanZSGGKqJV4VTaytpezFwv8ZHbZewmh	The widget always succeeds and emits a procaptcha-response token.
Always fail	5ETtechmZkn3CUVeJX7Z511oiuiu742aHLm91D5ZZw4fqoAG	The widget always fails. No token is emitted and your onError / failure handler runs.

Both keys are constant across all Prosopo environments (production, staging and development), so the same value works everywhere without environment-specific configuration.

Using a test key

Section titled Using a test key

Swap the site key in your widget configuration for one of the values above. No other change is needed — you do not need a secret key, and the key does not need to be registered against your account.

<div class="procaptcha"
     data-sitekey="5EARALUe4HXQwKo5KanZSGGKqJV4VTaytpezFwv8ZHbZewmh">
</div>

The test keys work with every captchaType. The challenge is replaced by a deterministic, non-interactive one, so frictionless resolves without ever showing an image grid or a puzzle, and a test never has to solve a CAPTCHA to proceed.

Because the always-fail key never emits a token, use it to exercise the failure branch of your front end — the error message, the disabled submit button, the retry prompt — rather than your server-side verification code.

Billing

Section titled Billing

Requests made with the reserved test keys are not billed and do not count towards your plan’s quota. They are short-circuited before any usage record is written, so they never appear in your usage figures or on your invoice.

This is the only way to test without accruing usage. A site key you create yourself for a staging or test environment is an ordinary site key: its verifications are included in your billable usage exactly like those of a production key.

Server-side verification

Section titled Server-side verification

A test key works end to end: the token the widget emits under the always-pass key verifies through /siteverify and returns verified: true, so your tests can exercise the whole flow rather than stopping at the widget.

{
    "status": "ok",
    "verified": true
}

Two details to be aware of:

• The secret is ignored. A reserved key has no secret of its own, so the usual check that your secret matches the site key in the token is skipped. Send your existing secret, or none at all — the result is the same.
• No score is returned, even on a Premium plan. Nothing scored the request, so there is no score to report. Do not write test assertions that expect one.

The always-fail key never produces a token, so there is nothing to verify with it. Use it to test your front end’s failure path, not your verification code.