> For the complete documentation index, see [llms.txt](https://docs.apexsolutions.lol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.apexsolutions.lol/cloudflare-js-d/getting-started.md).

# Getting Started

How Cloudflare JS-D works, how to tell a site uses it, and what the solve returns.

If you already know how JS-D works, skip to the **API reference**. This page explains what it is, how to tell a site uses it, and how the whole flow fits together — you do not need to reverse-engineer anything.

Everything here assumes you already meet the **Core Requirements** — a Chrome TLS client, the right header order, and a sticky proxy.

## Understanding Cloudflare JS-D

Cloudflare JS-D (JavaScript Detections) is a challenge that serves a small script to the browser. The script builds a fingerprint of the client and, when it looks like a real browser, Cloudflare issues a `cf_clearance` cookie that lets your requests through.

On the page it shows up as two pieces: an inline `__CF$cv$params` block that carries the challenge values (`r` and `t`), and a script loaded from `/cdn-cgi/challenge-platform/scripts/jsd/main.js`. When the challenge resolves, the browser ends up with a `cf_clearance` cookie (and sometimes `__cf_bm`).

## Identifying Cloudflare JS-D

Before anything else, confirm the site actually uses JS-D. Three signs are enough:

1. **The inline challenge block.** The page HTML has `window.__CF$cv$params` with `r` and `t`:

```html
<script>
  window.__CF$cv$params = { r: "{r}", t: "{t}" };
  ...
</script>
```

2. **The JS-D script request.** Look for traffic to `/cdn-cgi/challenge-platform/scripts/jsd/main.js`, which 302-redirects to a versioned script: `/cdn-cgi/challenge-platform/h/{sitekey}/scripts/jsd/{hash}/main.js`.
3. **The `cf_clearance` cookie.** Once a challenge resolves, the browser carries a `cf_clearance` cookie and sends it back on the protected routes.

Two honest caveats:

* **Not every Cloudflare challenge is JS-D.** If the page shows `window._cf_chl_opt` instead (a Managed or Turnstile challenge), the JS-D provider does not solve it — Apex answers with a clear error rather than pretending otherwise.
* **Deferred challenges.** If the site is behind Cloudflare but the `__CF$cv$params` block is not served inline on the first request, Apex reports the challenge as deferred instead of resolving it.

## How a session is built

A JS-D "session" is the `cf_clearance` cookie. Apex fetches the page, reads the `r`/`t` values from the inline block, pulls the JS-D script, and uses it to build and submit the challenge payload through your proxy. When Cloudflare accepts it, the response sets `cf_clearance` (and `__cf_bm` when Cloudflare sends it). You do not need to understand the payload's internals — you only replay the cookie.

## Solution Flow

Here is the flow from the client's point of view:

1. **Request the protected page.** Use a Chrome TLS client and the exact browser header order (Core Requirements).
2. **Confirm JS-D.** Check for the `__CF$cv$params` block and the `jsd/main.js` script. You do not need to extract the challenge values — Apex does that.
3. **Solve through Apex.** Send the target URL, `challenge: "jsd"`, your sticky proxy, and your real Chrome-on-Windows User-Agent. Apex returns the `cf_clearance` cookie (and `__cf_bm` when present). See the API reference for the exact request.
4. **Replay the clearance.** Attach `cf_clearance` (and `__cf_bm` if present) to your requests — with the **same User-Agent and the same proxy** that obtained it.

## Important Notes

{% hint style="info" %}
**The clearance is tied to its origin.** `cf_clearance` only validates when replayed with the same User-Agent, IP, and proxy that solved it. JS-D has no follow-up requests — there is no session id and no flush endpoint. A `proxy` is always required, and the `user_agent` must be Google Chrome on Windows.
{% endhint %}