Shield
Testing & CI
Shield ships fixed test keys with deterministic behaviour, so your test suite never needs real credentials, never depends on scoring outcomes, and never pollutes your widget's analytics. They work on any hostname.
Test Sitekeys (Client Side)
Use these in place of your real sitekey to force a specific widget behaviour:
| Sitekey | Behaviour |
|---|---|
es_test_pass | Always verifies — the widget shows the normal success state and produces a token |
es_test_block | Every solve fails — exercise your error handling and no-token paths |
es_test_interactive | Background attempts always escalate to the "I am human" confirmation first |
<!-- In your test/staging environment -->
<div class="edge-shield" data-sitekey="es_test_pass"></div>Test Secrets (Server Side)
Use these in place of your real secret to force a specific siteverify response, regardless of the token you send:
| Secret | siteverify response |
|---|---|
es_secret_test_pass | success: true, score 90 |
es_secret_test_fail | success: false with invalid-input-response |
es_secret_test_spent | success: false with timeout-or-duplicate — the replayed-token path |
# Always succeeds, score 90
curl -X POST https://shield.edge.network/siteverify \
-d "secret=es_secret_test_pass" \
-d "response=anything"
{
"success": true,
"score": 90,
"challenge_ts": "…",
"hostname": "localhost",
"error-codes": []
}What Test Traffic Can and Can't Do
-
Test keys work on any hostname, including localhost, with no widget configuration. -
Test challenges use trivial proof-of-work, so CI runs stay fast. -
Test traffic records no analytics and no scoring signals — it cannot skew your real widgets' metrics or the network's scoring. -
Tokens minted by test sitekeys are dummy strings that only test secrets accept — a real secret will never validate one, and vice versa.
Never ship test keys to production. es_secret_test_pass
accepts anything — a form "protected" by it is protected by nothing. Keep test keys in
test configuration only, exactly as you would a mock.