Anti-Bot Detection API — Batch Website Bot-Protection Profiler

Programmatic, batch-friendly detection of the anti-bot stack protecting a website. Point it at a URL and get back structured JSON describing the defense you are up against — a pre-flight fingerprint for your own scraper fleet.

This is a detection-as-intelligence tool. It reports what defenses a site runs so you can plan with your own tooling. It does not provide instructions for getting past those defenses, and it makes no promise of access.

What it detects

• The stack: Cloudflare, DataDome, Akamai, PerimeterX, Imperva, or none
• A confidence score and the raw signals that triggered the match
• A descriptive defense_profile (for example, "Cloudflare present; expect an interactive JS challenge")
• A coarse difficulty_estimate: easy | medium | hard | unlikely
• js_challenge_likely: whether an interactive JS challenge is expected
• recommended_profile: the request profile the detection engine would select
• recommended_action: an honest, machine-branchable hint for how to approach the target with your own tooling — standard_request, browser_render_recommended, or high_defense_expect_friction. It describes the kind of request to plan for; it never describes getting past a defense and is not a promise of access.

Input

Field	Type	Default	Description
url	string	—	The URL to fingerprint.
deep_playwright	boolean	false	If the cheap HTTP probe cannot identify the stack, render the page in a real browser and re-inspect. Slower, costs more.

Output

{
  "url": "https://shop.example.com",
  "stack": "cloudflare",
  "confidence": 0.95,
  "recommended_profile": "stealth",
  "recommended_action": "browser_render_recommended",
  "signals": ["header:cf-ray"],
  "defense_profile": "Cloudflare present; expect an interactive JS challenge (e.g. Turnstile) on protected routes.",
  "js_challenge_likely": true,
  "difficulty_estimate": "hard"
}

How it works

A lightweight HTTP probe inspects the response headers and the first few KB of the body for known signatures. Only when that probe cannot identify the stack and you set deep_playwright: true does the Actor escalate to a full browser render and re-inspect — keeping the common path cheap and fast.

The batch JSON output is the point: pipe many URLs through it and let your pipeline decide what to do, instead of checking sites one at a time by hand.

Bring your own proxy

For an actual fetch (not just detection), pair this with the companion stealth-scraper Actor, which accepts a single proxy parameter.

Pricing

Pay-per-event. Lightweight recon events are inexpensive; a deep browser render costs more because it runs a real browser.

Build & deploy

This Actor is self-contained: the Docker build context is this Actor folder. Apify confines the build context to the Actor's own directory, so a COPY cannot reach outside it.

This Actor depends on the repo-local fenlo_engine package (source at packages/engine — outside this folder). Because Docker cannot COPY across folders, the engine is vendored here as a pre-built pip wheel (fenlo_engine-*.whl). Build the wheel into this folder first, then build the image with this folder as the context:

# From the repo root: build the engine wheel into a throwaway dist/ and copy it
# into this Actor dir. Do NOT use `-o actors/recon-meta`: `uv build` writes a
# `.gitignore` containing `*` into its output dir, which would re-ignore this
# Actor's .actorignore and break `apify push`. dist/ is already git-ignored.
rm -f actors/recon-meta/fenlo_engine-*.whl
uv build --wheel packages/engine -o dist
cp dist/fenlo_engine-*.whl actors/recon-meta/

# From inside this Actor dir (context = ".")
cd actors/recon-meta
docker build -t fenlo-recon-meta .

The Dockerfile (referenced from .actor/actor.json) then:

1. installs the vendored engine with pip install fenlo_engine-*.whl, and
2. installs this Actor's requirements.txt (the Apify SDK),

so import fenlo_engine resolves inside the container. The base image is apify/actor-python-playwright, which ships a Chromium matched to the engine's Playwright dependency (used by the optional deep_playwright path).

Trade-off: the wheel is a vendored copy, so rebuild it whenever packages/engine changes (otherwise the Actor ships a stale engine). The wheel is git-ignored; a .actorignore re-includes it so apify push still uploads it.

To publish on Apify: cd actors/recon-meta && apify push (rebuild the wheel first). See docs/launch/PUBLISH.md.