Test keys and testing · Docs

Test keys #

Use these keys for local development, continuous integration and preview deployments, from any origin including http://localhost. They need no account, never touch customer data, are never billed and work against the production API.

Key	Behaviour
`ba_pk_test_always_pass`	Site key: no work, issues the dummy token `XXXX.DUMMY.BLOCKALT.TEST.TOKEN.XXXX`
`ba_pk_test_always_fail`	Site key: every token request is refused (`refused`, reason `rule_blocked`)
`ba_pk_test_proof_of_work`	Site key: real proof of work at difficulty 12, then the dummy token
`ba_sk_test_always_pass`	Secret: the dummy token is `accepted`, with `test: true` in the answer; any other token fails with `invalid_token`
`ba_sk_test_always_fail`	Secret: every token fails with `invalid_token`
`ba_sk_test_already_used`	Secret: every token fails with `already_used`

The answers never change: with ba_sk_test_always_pass the dummy token is accepted on every call, never already_used, and the official Node SDK sends every call with a test secret to siteverify without caching anything. Test secrets have their own budget of 1,200 verifications a minute (burst 300) per client network.

Real secrets refuse the dummy token, so a test site key that slips into production fails closed. A test secret in production refuses your real visitors with invalid_token, because it accepts only the dummy token, which anyone can obtain from the always-pass site key: you notice at once, but replace it immediately. Pin the configuration keys from GET /v1/keys as usual:

JavaScript

const protection = BlockAlt.create({
  siteKey: "ba_pk_test_proof_of_work",
  apiUrl: "https://blockalt.click",
  configPublicKeys: ["MCowBQYDK2VwAyEAXmYdcBh/jf+z+0H+hs2QvZ9UG4PBgkRvHX/JuXyjIL8=","MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE34qdEtOeD21+CmmfTmFyRr/vySsY1TD6BJZFtwF37pkelvN2vRYWWHdLrUouzkQXEfnA7V50xK2QcmnBCGsxbA==","MCowBQYDK2VwAyEAtkfghYcdvSRf2wA01gjQtgTqdYGjaDUZsOPXzgLnnT0=","MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYYmQNAMnVKK7G3VVguAk3SC/RFT5SDjCoxcFMOPFx0vmsGycJWOK8hCdxuTCHlvShng1fo0y4Q9PJHPIGQ9EfA=="],
});

Do not reuse test keys as a way around limits, and do not resell or publish integrations that depend on them.

A separate staging site #

For a staging environment that should behave exactly like production, create a second site in your workspace with its own keys, origins (for example https://staging.example.com) and actions. Its decisions and usage are separate from production. Hostnames must be verified with a TXT record like production ones; real sites do not accept localhost origins on the hosted service.

Unit tests for your backend #

Your verification code needs to handle every answer, not only accepted. The test secrets above give you real accepted, invalid_token and already_used answers; for the rest, stub the HTTP call and feed it realistic responses:

Allowed without a checkJSON

{ "success": true, "reason": "unpaid", "id": "1d3f9a77-4b2e-4e0a-8c1d-5a6b7c8d9e0f" }

RefusedJSON

{ "success": false, "reason": "wrong_hostname", "id": "a8d0e8f2-6a3e-4c55-9b0c-7e5c2a9f4d21" }

Also simulate a timeout, a 503 and a 401, and check that your code refuses the action (or applies your fail-open policy) in each case. With the Node SDK, pass a custom fetch to createVerifier to return these responses, together with precheck: false and tokenKeys: false: otherwise the SDK refuses your fake tokens locally before your stub is called.

End-to-end tests #

With ba_pk_test_proof_of_work and ba_sk_test_always_pass, browser tests exercise the real script, the real proof of work and your real verification code in a few tens of milliseconds. Against a staging site with real keys, also assert that a second submit of the same token is refused with already_used.

Questions about testing: support@blockalt.click.