What Is DataDome and Why It Blocks Your Scraper
What DataDome is, how it scores requests, how to recognise it, why the datadome cookie causes challenge loops, and what actually keeps a scraper unblocked.
DataDome is a commercial bot-protection service that sits in front of a website and scores every request in real time, then lets it through, shows a challenge, or blocks it. If your scraper or monitor suddenly gets HTTP 403 responses, a "you have been blocked" page or a slider puzzle on a site that used to work, DataDome is a common cause. This guide explains what DataDome looks at, how to recognise it, why scrapers specifically trip it, and the one piece of state — the datadome cookie — that explains most repeated challenges. For background on challenges in general, see what a CAPTCHA test is.
What is DataDome?
DataDome is bot and fraud protection sold to websites and apps. It runs at the edge of the site (through a CDN or server integration) plus a JavaScript tag in the browser and SDKs in mobile apps. Each request gets a decision before it reaches the site: allow, challenge, or block. Challenges are usually an invisible device check or a slider CAPTCHA; blocks are typically a 403 response.
It is used mostly by e-commerce, ticketing, travel, classifieds and media sites — the businesses that lose money to price scraping, scalping, fake accounts and credential stuffing. That is why price and availability monitors meet it so often; our price monitoring guide covers that use case.
How DataDome decides a request is a bot
DataDome combines many weak signals into one decision rather than relying on any single test. The scraping guides that rank for this topic agree on the main layers, and DataDome's own case study of a scraping attack on a luxury fashion site shows them working together against a scraper that rotated large numbers of IPs and user agents.
- Network: the reputation and type of the IP address. Datacenter ranges are treated more cautiously than residential or mobile ones, and addresses that recently sent bad traffic carry that history.
- Connection fingerprint: the TLS handshake and HTTP/2 settings your client sends. An HTTP library announcing a Chrome user agent but negotiating TLS like Python is an obvious mismatch.
- Headers: missing, extra or out-of-order headers, and combinations no real browser sends.
- Browser environment: what the JavaScript tag can read — automation flags, rendering, screen and device properties.
- Behaviour: request rate, navigation paths that skip normal pages, and, on the slider, how the drag actually moves.
Treat specific numbers in vendor articles with care. Several ranking pages quote signal counts, decision times or block rates without a source; we have left those out.
How to tell a site is using DataDome
Check the response, not the page design. A DataDome-protected site usually shows at least one of these:
- a
Set-Cookieheader creating a cookie nameddatadome; - an
x-datadomeresponse header, or DataDome scripts loaded by the page; - a 403 status with a short HTML page instead of the content you requested;
- a slider puzzle served in an iframe from a DataDome captcha domain.
If you see Cloudflare's "Verifying you are human" screen instead, that is a different system — see our guide to Cloudflare's check.
The datadome cookie: why challenges keep coming back
The datadome cookie carries your session's trust state, and losing it is the most common reason a scraper is challenged again and again. DataDome's own cookie documentation says the cookie is used for both server-side and client-side detection, is encrypted, contains no personal data, and has a lifetime of one year. Its mobile SDK guide adds that the cookie records whether the user has passed a DataDome CAPTCHA or Device Check, and that losing it can cause a "challenge loop" of challenge after challenge.
Scrapers lose it constantly: a new HTTP session per request, a cookie jar that is not persisted between runs, or a manually set Cookie header that overwrites the one DataDome just issued. Every one of those turns a session that had already earned trust into a brand-new, unknown visitor.
Why scrapers get blocked (and what actually helps)
Scrapers get blocked because they look inconsistent, not because they are fast. The fixes that hold up are the boring ones:
| What the scraper does | What DataDome sees | What helps |
|---|---|---|
| New session for every request | Endless first visits with no cookie | Keep one cookie jar per session and persist it |
| Rotates IP on every request | The same cookie arriving from many places | Hold one exit IP per session; rotate between sessions |
| Browser user agent on an HTTP library | Headers and TLS that disagree | Use a real browser, or a client whose fingerprint matches its user agent |
| Hits product URLs directly at high rate | Navigation no person makes | Slow down; follow normal entry paths; respect robots and rate limits |
| Ignores the slider and retries | A session that failed its challenge | Pass the challenge once, then reuse the cookie |
Before any of this, check you are allowed to collect the data. Many sites that run DataDome publish an API or a data feed, and their terms may prohibit scraping outright.
When a solver helps with DataDome
A solver helps when a session you are allowed to run reaches the slider. Solving it returns a fresh datadome cookie for that session, which you then send with your following requests. Because the cookie is judged together with the network and client that earned it, it has to be produced through the same proxy and user agent your scraper uses — a cookie minted elsewhere is the classic way to pass the slider and still be blocked on the next request.
That is why our DataDome solver refuses a task without your proxy instead of returning a cookie that cannot work. You send the page URL, the challenge iframe URL, your proxy and your user agent; you get back the cookie to send with your following requests, using the same user agent you supplied. The request format is in the API reference, and the same concepts for other systems are in why captcha tokens get rejected.
What a solver will not fix
A solver will not fix a hard block. If the site answers with a 403 and no challenge, the decision was made before any puzzle was offered; that usually means the IP or fingerprint is already distrusted, and the answer is a cleaner session, not a solve. It also will not make high-volume scraping of a site that forbids it acceptable. Our acceptable use policy sets out what CaptchaNo may be used for.
Frequently Asked Questions
What is the datadome cookie?
It is the cookie DataDome sets to track a visitor's trust state. DataDome's documentation says it is encrypted, contains no personal data, lasts one year and is used for both server-side and client-side detection. It records whether the session has passed a CAPTCHA or device check, so keeping it avoids repeated challenges.
Why does DataDome keep showing me the slider?
Usually because the datadome cookie is being lost, so every request looks like a new visitor. Blocked cookies, a new session per request, or overwriting the cookie header all cause it. DataDome's own guide calls the result a challenge loop. Persisting the cookie and keeping the same IP and user agent for the session usually stops it.
Is DataDome the same as Cloudflare?
No. Both are bot-protection services but they are separate companies with different systems. Cloudflare shows a "Verifying you are human" page or a Turnstile widget and sets a cf_clearance cookie. DataDome shows a slider or a 403 block page and sets a datadome cookie. The troubleshooting principles are similar, but the cookies and challenges differ.
Can you get past DataDome with a proxy alone?
Rarely. A residential proxy improves the network signal but DataDome also scores the connection fingerprint, headers, browser environment and behaviour. A proxy combined with an inconsistent client still looks automated. A stable session that keeps its cookie, IP and user agent together matters more than the proxy type on its own.
Why is a solved DataDome slider still blocked?
The cookie from the solve is evaluated together with the IP address and client that earned it. If the slider was solved through one IP and the next request comes from another, or with a different user agent, the session looks inconsistent and is challenged again. Solve through the same proxy and replay the returned user agent.
Keep authorised monitoring running
If your authorised scraper meets DataDome's slider, start a free CaptchaNo trial and solve it through the proxy your session already uses. Per-type rates are on the pricing page.