Web Unlocker · DataDome
DataDome web scraping usually stops at the first request: a 403 and a page of under two kilobytes that asks for JavaScript. The Web Unlocker sends your URL from a residential or mobile IP as a browser-grade request, opens a real browser when DataDome serves its device check, and returns the page behind it as JSON.
On 11 November 2026 our canary got the real page back on 11 of 12 calls to DataDome-protected pages. The whole run of that day, 27 protected pages called 3 times each, returned it on 72 of 81 calls, with a median of 4.1 s. See the method and each run on the status page
A DataDome refusal is small and always the same, which makes it easy to spot in a log once you know it. These are the marks.
| Where to look | What DataDome leaves there |
|---|---|
| Status code | 403 on a blocked page. A call to the site's API gets 403 with a short JSON body whose url points to captcha-delivery.com. |
| Page text | "Please enable JS and disable any ad blocker". The whole page weighs under two kilobytes: that sentence and a script. |
| Script | A var dd={...} object and a script from ct.captcha-delivery.com. Inside dd, rt is i for the device check and c for the captcha. |
| Response headers | x-datadome: protected on the answers of a protected site, and a set-cookie: datadome=... on every one. |
| What a person sees | A short screen that checks the device and clears by itself, or a slider puzzle to drag. |
| Cookie | datadome. It is refreshed on every answer and checked against the client that presents it. |

DataDome scores every request, not only the first, on its own servers and before the site answers. Four things go into the score: the IP and its history, the TLS handshake and HTTP/2 settings compared with the User-Agent, the device check that a script runs in the browser, and the datadome cookie.
The cookie is the part that surprises people. It belongs to the client that earned it. Copied from your own browser into a script, even on the same IP, it is refused and the check starts again. So there is no one-off fix to paste in: the request has to be right each time, from an IP that has not been burned and from a client that can run the check.
The first attempt is a browser-grade request from a residential exit. If DataDome lets it through, you get the page from the fast tier. If it answers with the device check, a real browser opens the page, lets the check finish and returns the page behind it; tier_served then says browser.
A refused attempt is retried from a fresh exit, so one bad IP does not decide the call. After a pass, your next calls to the same site reuse the session, and the answer reports it in the clearance field. You do not store, refresh or replay the datadome cookie yourself.
One POST with the URL and the country the site serves. The example is curl; the API docs have the same call in Python, Node.js, PHP and Go.
Read blocked before you parse body. On DataDome sites a block is a 403 page of a few hundred bytes, and a job that stores it as data is hard to clean up later.
curl -X POST https://app.quantumproxies.io/api/v1/scraper/unlock \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/", "country": "us"}'
The full request and answer in the Web Unlocker docs
| Field | On a DataDome site |
|---|---|
| status | The status the site answered with: 200 for the real page. |
| blocked | true when the page that came back is still DataDome's. The block page is then in body, for inspection. |
| blockClass | js_challenge for the device check, captcha for the slider. |
| vendor | datadome. |
| tier_served | tls or browser. On a site that serves the device check, expect browser on the first call. |
| attempts | The number of attempts, with one attempt_log entry each: tier, exit country, outcome, milliseconds and bytes. |
| cost | Bytes moved and their cost for this call, retries included. |
A blocked answer on DataDome usually carries one of the first two classes below, and they call for different reactions. The third appears when a site refuses the exit itself.
DataDome watches the rate and the history of each IP, so a job that pins one address and hammers it is the job that gets the slider. Leave rotation on, which is the default, and let the session reuse do its work: the first call waits for the device check, the following ones do not until the site asks again.
Calling the site's own JSON API works the same way. Send the API URL with the headers it needs. A DataDome block on an API call is a 403 with a JSON body, and the answer flags it as blocked just like a page.
A proxy changes one of the four inputs. If your scraper is a real browser that already passes the device check and only needs a cleaner IP, residential or mobile proxies will do. If it is an HTTP client, the handshake and the missing check still give it away from a home IP. That is the case the Web Unlocker is for.
The slider puzzle, like any other captcha that needs a person, is not solved; you get blocked true and blockClass captcha, never a page that pretends to be the content. The Web Unlocker does not sign in and does not create accounts, so it is for the public pages of a site.
DataDome protects the site; it does not set the rules for the data. Whether you may collect a page depends on the site's terms and on the law that covers the data, and that is yours to check.
Yes, for public pages. It sends the URL from a residential or mobile IP as a browser-grade request and opens a real browser when DataDome serves its device check. The JSON answer holds the page, the status and the tier that served it. If the call stayed blocked, it says so, with blockClass and vendor datadome.
The slider asks for a person and is not solved. The call comes back with blocked true and blockClass captcha, and body holds the block page, not a fake success. Retry later or from another country: each new call leaves from a fresh exit, and the device check that clears by itself is handled by the browser tier.
It will not help. DataDome ties the cookie to the client that earned it and refreshes it on every answer, so a cookie taken from your browser is refused when another client presents it. The Web Unlocker keeps the session it earned and reuses it on your next calls to that site.
Start on the residential tier, which is the default. If a site keeps answering access_denied there, the hint in the answer suggests the mobile tier: add tier mobile to the call and the same request leaves from 4G/5G carrier IPs. The two tiers are separate GB balances in the dashboard.
The answer names the system in vendor: datadome, when it recognised the block page. In the raw response the marks are the x-datadome header, the datadome cookie and a script from captcha-delivery.com. Through the forward proxy the same verdict arrives in the x-qp-vendor and x-qp-block-class headers.
Skip the marketing. QuantumProxies.io publishes a machine-readable site map, Markdown for every page, a free MCP server, and APIs billed from the same balance as your proxies.
Connect in one command: npx -y quantumproxies-mcp