Bot protection API

A bot protection API for crawler and scraper decisions.

A simple API decision point for developers who want bot protection without migrating DNS or changing CDN providers.

bot protection APIbot detection APIcrawler detection APIscraper detection API

Call the decision API from middleware

Send site ID, path, method, request headers, IP, and browser token state to receive an allow, log, challenge, or block decision.

Use runtime keys server-side

Server-side middleware should call the API with a Bearer runtime key. Browser collect calls remain public and use per-site challenge tokens.

Log decisions for review

Each decision can be logged with user-agent labels, client family, score, and action so operators can tune blocking safely.

Detection proof

Bot Protection API signals Voidek can separate before content is served.

Use these examples as rollout checks: start in monitor mode, confirm the log rows, then enforce only the classes that match your protected routes.

Decision requestsiteId, path, method, headersReturn allow, log, challenge, or block
Runtime keyBearer VOIDEK_API_KEYKeep server-side and rotate if exposed
Decision logsAction, score, family, pathTune rollout with evidence

Rollout path

Start with one protected site, one test request, and one Analytics row.

Voidek is meant to start quietly: save the runtime key, run a controlled test, then raise friction only where live logs support it.

01

Add one protected site

Create a personal account on the Free plan, add one protected site, and save the runtime key before turning on bot protection API.

02

Run the test decision

Copy the test request, export VOIDEK_API_KEY, then confirm the GPTBot row appears in Analytics with path, action, and score.

03

Enforce by route

Add the decision API at middleware or backend boundaries, then tune crawler detection API after live rows look clean.

FAQ

Questions site owners ask before turning on crawler defense.

Should backend API calls include an auth token?

Yes. Server-side decision calls should include an Authorization Bearer runtime key. Dashboard calls use the secure session cookie.

Can I test the API from docs or Swagger?

You can test public health endpoints without a key. Runtime decision examples should include the runtime key generated in the dashboard.

First setup

Set up one protected site before the next crawl spike.

Create a personal account, add one protected site, copy the runtime key, and run one test decision before enforcing bot protection API.