DataDome: understanding and handling the block
DataDome is a bot-management solution used by many e-commerce and media sites. Here is how a block shows up (403, CAPTCHA), what it detects and how to approach it cleanly.
DataDome, server-side bot management
DataDome is a bot detection and blocking service, integrated by many sites (e-commerce, media, travel). It analyses every request and decides whether to let it through.
Unlike a plain firewall, it combines several signals — device fingerprint, behaviour, network — to estimate whether the visitor is human.
The 403 block: the first sign
The most visible block is an HTTP 403 (“Forbidden”) response, sometimes with an explicit page. It signals that the request was classified as non-human.
A 403 is not a bug in your code: it is a decision by the protection system. Fixing it means changing what it observes (fingerprint, behaviour, IP).
- HTTP 403 (“Forbidden”) response
- A protection-system decision, not a bug
- Often accompanied by a dedicated page
Behavioural detection
DataDome watches behaviour over time: request speed, regularity, page sequence, interaction with the page (mouse, scroll). A perfectly regular pace betrays a machine.
Slowing the pace, varying the paths and respecting realistic pauses make traffic more credible — and spare the site.
Device and network fingerprint
Beyond behaviour, the service inspects the device fingerprint (browser, rendering engine, capabilities) and the network (IP address, reputation, geographic consistency).
A minimal HTTP client, or a poorly configured headless browser, shows an inconsistent fingerprint that is enough to trigger a block. A realistic browser narrows that gap.
CAPTCHA and interactive checks
Depending on the level of doubt, DataDome may return a CAPTCHA rather than a direct block: it asks for a proof of humanity before letting the request through.
These checks run in the page (JavaScript): it must be executed and the challenge handled, which a bare HTTP request cannot do.
The ScraperFlow approach to DataDome
ScraperFlow runs a realistic headless browser, executes the page’s JavaScript and presents a fingerprint coherent with a real browser: the crudest signals disappear.
The pace is controlled to avoid “machine” behaviour. We do not promise to get past every configuration: DataDome adapts, and some sites choose a deliberately strict policy.
Limits, ethics and best practices
Solutions like DataDome evolve continuously: what passes today may be blocked tomorrow. Durable access relies on monitoring and adjustment, not a fixed recipe.
Automate responsibly: respect robots.txt and the terms of use, limit the frequency and volume, and process personal data under the GDPR.
- Monitor and adjust (defenses evolve)
- Respect robots.txt, terms of use and GDPR
- Limit frequency and volume
Frequently asked questions
Why does DataDome return a 403?
The 403 (“Forbidden”) signals that the request was classified as non-human by DataDome, based on several signals (fingerprint, behaviour, network). It is not a bug in your code, but a decision by the protection system.
Does DataDome use CAPTCHAs?
Yes, depending on the level of doubt: DataDome may return a CAPTCHA (or an interactive check) rather than a direct block, to ask for a proof of humanity before letting the request through.
What is behavioural detection?
It is the analysis of behaviour over time: request speed and regularity, page sequence, interaction with the page. A perfectly regular pace or a total lack of interaction is a strong signal of automated traffic.
Does ScraperFlow get past DataDome for sure?
No. ScraperFlow reduces the most obvious signals (fingerprint, JavaScript execution, pace), which gets past many configurations, but DataDome adapts and some sites enforce a deliberately strict policy. Results vary.