How to Bypass DataDome Without a Headless Browser: Request-Based Guide

You can bypass DataDome without a headless browser by doing what the browser would do, but over plain HTTP. You identify which DataDome challenge you've been served, send the payload it expects, and do all of it from a request session that looks consistent from start to finish. The solve itself is rarely the hard part. Most blocks that remain come from the requests around it: the TLS fingerprint, the headers, the cookies, the IP and a browser capture that wasn't clean.

This guide covers that workflow: how to recognise what DataDome is doing, how to build a consistent session, where the solve fits in, and how to debug a setup that still gets blocked. A fair warning: this approach is technical and not beginner-friendly.

#1. Before you start: what a request-based DataDome bypass means

A headless browser runs DataDome's scripts and produces the right data as a side effect. A request-based setup skips the browser. You generate the data DataDome's scripts would have produced and send it with an ordinary HTTP client, together with your normal requests to the site.

That means no browsers to run or maintain, and no automation framework for DataDome to fingerprint. It also means nothing hides the details from you: every request your client sends has to be right. How this compares with browser automation in detail is covered on our DataDome product page (linked at the end). This guide focuses on the implementation.

Scope: everything here applies to DataDome on websites, with Chrome on Windows or macOS as the client. DataDome is used on mobile too, but not enough for Hyper Solutions to tailor payloads to it.

#2. Identify which DataDome problem you have

DataDome has three main flows: the interstitial, the slider and tags. The first two are challenges that block you; tags are background telemetry that affects how much DataDome trusts your session. Start by working out which one you're dealing with.

• A 403 block page whose dd object has rt: 'i' and loads i.js: Interstitial: a device check. In a browser it looks like a white page or a short animation before the site loads. See Interstitial docs.
• A 403 block page whose dd object has rt: 'c' and loads c.js: Slider: a puzzle you drag from left to right. Some sites show it right away, others only when the interstitial isn't enough. See Slider captcha docs.
• A JSON or XHR call returns a body with a url pointing at captcha-delivery.com: The same challenge, returned inline by an API endpoint instead of a block page. Route on the path (/interstitial/ → interstitial, /captcha/ → slider) and pass that url straight through as the device link; there is no dd object to parse. See DataDome getting started.
• The dd object has t: 'bv': Your IP is hard-blocked. The response is an HTML block page with no usable scripts or challenge to generate a payload from, so there is nothing to solve. Change proxy/IP.
• Your request-based client gets an interstitial or slider where a real browser doesn't: Often tags are missing or sent too late. See Tags docs.
• You solve a challenge and get another one, in a loop: Usually a problem with your requests or session consistency, not simply too few tags. See sections 5 and 6 below.

One flow can lead to another: an interstitial solve can redirect you to the slider. Treat this list as a starting point, not a diagnosis.

#3. Build a consistent request session

This is where most of the work is. DataDome judges the whole session, not one request. Every request should look like it came from the same Chrome browser on the same machine.

• TLS fingerprint. Your HTTP client must look like a current version of Chrome at the TLS level, and standard HTTP libraries don't. Our examples use TLS clients built for this. Background: TLS fingerprinting.
• Header order and values. Match Chrome's headers and header order 1:1, including Client Hints. Stale Client Hints are an easy giveaway. See header order.
• User agent. Use an up-to-date Chrome user agent and keep it for the whole session.
• IP. Keep the same IP from the blocked request through the solve to the follow-up requests. Use the same proxy for every request in the session, including the device link. The IP you pass to the API must be your proxy's outbound IP, so use sticky sessions rather than rotating proxies. See Proxies & IP.
• Cookie jar. Use one jar per session and let DataDome's responses update the datadome cookie. Don't copy cookies between sessions.
• Tags, early. Post tags as early as possible, for example right after the first homepage request. Sending them early helps you avoid interstitial or slider blocks on your first requests. See the tags docs.
• A clean reference capture. Record the site in a clean Chrome profile and use that as your reference for headers and request order. A capture from a browser with extensions or leftover state teaches you the wrong behaviour. Our blog on why bad DataDome captures still get blocked explains this in detail, and our powhttp guide shows how to capture and compare requests.

Get this foundation right before you touch any challenge. Otherwise you won't know whether a block comes from the solve or the session.

#4. Solve the challenge and continue

Once the session is consistent, handle the challenge you identified. The division of work is simple:

• Hyper Solutions generates what DataDome expects: the interstitial payload, the slider solution from the challenge images, and tags payloads. You pass in what the docs describe for that flow, such as the device link and the challenge page.
• You fetch the device link, submit the result and continue, all from your own session with the same proxy and headers.

Which steps a site needs depends on the site and on how DataDome responds to your session. There is no single flow that fits every DataDome site, so follow the challenge-specific docs rather than a fixed recipe. The interstitial and slider pages linked in section 2 have the exact calls, and the DataDome API reference lists the fields.

New DataDome builds are handled by our update pipeline, so you keep calling the same API. Occasionally an integration needs a small change. The challenge script field is a recent example; it is optional, and integrations that don't send it keep working.

#5. Why a solved challenge can still get blocked

A common situation: the solve is accepted, and you still get blocked or challenged again. The cause is usually in the requests around the solve, not in the solve itself:

• Wrong TLS fingerprint. The payload says Chrome; the connection says Python or Go.
• Header mismatch. Wrong order, a missing header, or Client Hints that don't match the user agent.
• IP mismatch. The device link, the solve and your follow-up requests didn't all go out through the same IP.
• Rotated user agent. The user agent changed somewhere between the block and the follow-up requests.
• Wrong cookie state. The updated datadome cookie wasn't stored, or an old one was sent.
• Missing or late tags. If you get an interstitial or slider where a real browser doesn't, tags are often missing or sent too late.
• Lost inputs from the blocked response. The device link needs the URL that got blocked (used as the referer) and the datadome cookie set on that blocked response. Keep both before you move on.
• Polluted browser capture. Your reference capture came from a browser with extensions or leftover state, so your client copies behaviour a clean Chrome wouldn't show.
• Hard-blocked IP. If the dd object has t: 'bv', the response is an HTML block page with no usable scripts or challenge to generate a payload from. There is nothing to solve: change proxy/IP.

A challenge loop, where every solve leads to another challenge, usually points to these request and session problems, not simply to too few tags.

A solver can't fix these for you. They live in your request stack.

#6. How to debug a failing DataDome implementation

When something fails, work through these checks in order. Change one thing at a time.

1. Is the challenge identified correctly? Check rt, the script URL and whether it came as a block page or as inline JSON.
2. Is the IP hard-blocked? If t is bv, there is no challenge to solve. Switch proxy/IP before anything else.
3. Same IP for every request? The blocked request, the device link, the solve and the follow-ups.
4. Same up-to-date user agent everywhere?
5. Are the cookies right? One jar, the datadome cookie updated from DataDome's responses.
6. Is TLS consistent? The same Chrome-like TLS client on every request.
7. Do headers, header order and Client Hints match a clean capture? Compare them header by header.
8. Are you sending tags early enough? Post them as early as possible, for example right after the first homepage request. See the tags docs.
9. Did you follow the challenge-specific docs? Interstitial and slider each have their own flow.

Stuck in a challenge loop? Go back to steps 3 to 7: it is usually request or session consistency, not the number of tags. If all of that checks out, compare your flow with the examples repository.

#7. When a browser is still the better choice

Simple flows are often where request-based pays off most: a few requests per page, no browser to start, and much less infrastructure per request. A browser makes more sense when your flow depends on long-lived browser state:

• persistent sessions that have to stay alive for a long time;
• logged-in accounts;
• flows that build up a lot of browser state over many steps.

Request-based work is technical and takes time to get right. The payoff is that you don't need to run browsers, which can save a lot of infrastructure cost at volume. Our LLM plugins, the docs and the SDK examples help you learn it, but expect a learning curve.

#8. Request-based DataDome checklist

Before you go live, check:

• Chrome-like TLS client on every request
• Headers, header order and Client Hints match a clean Chrome capture
• One up-to-date user agent per session
• One IP per session, including the device link and the solve
• One cookie jar per session; datadome cookie updated from DataDome's responses
• Challenge detection covers block pages and inline JSON responses
• Blocked URL and datadome cookie kept from the blocked response
• Interstitial and slider handled per the docs, including the redirect from interstitial to slider
• Tags posted as early as possible (e.g. right after the first homepage request)
• Hard-block (t: 'bv') detected and routed to a proxy/IP change (nothing to solve)
• Monitoring for challenge loops (check request/session consistency first)

#9. FAQ

#Why does DataDome keep challenging me after a successful solve?

If a real browser isn't challenged on the same site but your request-based client gets an interstitial or slider, tags are often missing or sent too late. Post tags as early as possible, for example right after the first homepage request, and make sure the updated datadome cookie is stored and sent.

#Why do I get another DataDome challenge after solving one?

A challenge loop usually points to request or session consistency, not simply to too few tags. Check the IP, user agent, cookie state, TLS client, header order and Client Hints, and whether your reference capture was clean. Work through steps 3 to 7 in section 6. An interstitial solve that redirects you to the slider is a different case (see section 2), not a loop.

#Do I need to keep the same proxy IP throughout the DataDome flow?

Yes. Use the same IP for the blocked request, the device link, the solve and your follow-up requests. An IP mismatch is one of the usual reasons a solve is accepted and you still get blocked.

#What does t: 'bv' mean?

Your IP is hard-blocked. The response is an HTML block page without usable scripts or a challenge to generate a payload from, so there is nothing to solve. Change proxy/IP.

#When should I send DataDome tags?

As early as possible, for example right after the first homepage request. Sending them early helps you avoid interstitial or slider blocks on your first requests. See the tags docs.

#10. Next steps

• Docs: start with DataDome getting started, then the interstitial, slider and tags pages linked in section 2.
• Code: the examples repository has working DataDome flows in Go, Python and Node.js, with TLS client setup, header ordering and cookie handling.
• Product: the DataDome captcha solver API page covers supported challenges, outputs and pricing.
• Try it: every account starts with a free one-week trial. Create an account.