← Glossary / DataDome Device Check API

What is DataDome Device Check API?

DataDome Device Check API is the telemetry ingestion endpoint used by DataDome's client-side scripts to transmit browser fingerprints, hardware signals, and behavioral biometrics back to their classification engine. For scraping pipelines, it represents the active phase of detection: failing to submit a valid, properly encrypted payload to this API guarantees a persistent 403 block on all subsequent requests.

Anti-botTelemetryJS ChallengePayload EncryptionDataDome
// 02 — definitions

The telemetry
choke point.

How DataDome shifts detection from passive network analysis to active client-side interrogation, and why naive headless browsers fail the test.

Ask a DataFlirt engineer →

TL;DR

The Device Check API receives heavily obfuscated JSON payloads containing over 40 client signals — from canvas hashes to mouse velocity. It evaluates this telemetry to issue the clearance cookie. Bypassing it requires either executing the obfuscated JS in a pristine browser environment or reverse-engineering the payload encryption.

01Definition & structure
The DataDome Device Check API is the backend endpoint that receives telemetry from DataDome's client-side scripts. When you visit a protected site, the server returns a lightweight HTML page containing an obfuscated JavaScript file. This script executes, profiles your browser environment, encrypts the resulting data, and POSTs it to the Device Check API. If the API validates the payload as human, it responds with a datadome cookie, granting access to the actual site content.
02The payload lifecycle
The lifecycle consists of three phases:
  • Collection: The script reads navigator properties, renders a hidden canvas, measures execution timing, and tracks mouse movements.
  • Transmission: The data is serialized, encrypted (often AES-CBC with dynamic keys), and sent via XHR/Fetch to the API.
  • Evaluation: The backend decrypts the payload, checks for anomalies (e.g., a Linux OS claiming to be an iPhone), and issues either a clearance cookie or a CAPTCHA challenge.
03Encryption and obfuscation
DataDome heavily obfuscates its JavaScript to prevent scrapers from understanding how the telemetry is gathered or encrypted. The payload itself is typically encrypted using keys that are dynamically generated or rotated frequently. Attempting to deobfuscate the script to forge the payload manually is a massive time sink; the script will likely change before your reverse-engineering effort is complete.
04How DataFlirt handles it
We do not attempt to forge Device Check payloads. Instead, our infrastructure routes requests through a fleet of hardened, fingerprint-perfect headless browsers. When DataDome serves its challenge script, our browsers execute it natively. Because our browser environments are meticulously patched to remove automation flags and present coherent hardware profiles, the script naturally generates a valid, high-trust payload. The API issues the cookie, and we extract the data.
05The "block the script" misconception
A common mistake among junior scraping engineers is attempting to block the DataDome script (e.g., using ad-blocker rules or Puppeteer request interception) to speed up page loads. This is fatal. DataDome operates on a default-deny model. If the Device Check API does not receive a valid payload, you will never receive the clearance cookie, and you will remain permanently locked out of the target site.
// 03 — the classification model

How telemetry
becomes a block.

DataDome evaluates the Device Check payload against known bot signatures and historical session data. DataFlirt monitors the exact thresholds that trigger a challenge.

Telemetry validity = V = crypto_valid × signal_coherence
If the payload decryption fails or signals contradict (e.g., iOS User-Agent with Windows fonts), V = 0. DataDome client architecture
Session trust score = S = 1 − (anomalies / total_signals)
A score below the target's configured threshold triggers an interstitial CAPTCHA. Anti-bot heuristic model
DataFlirt pass rate = P = successful_device_checks / total_challenges
P > 0.994 across our fleet as of v2026.5. Internal SLO
// 04 — network trace

Intercepting the
Device Check payload.

A live trace of a DataDome JS challenge execution, showing the encrypted telemetry POST and the resulting cookie issuance.

POST /js/AES-CBCdatadome cookie
edge.dataflirt.io — live
CAPTURED
// 1. Initial request blocked
GET /api/v1/pricing
status: 403 Forbidden
response: <script src="https://cc.datadome.co/tags.js"></script>

// 2. Script executes, gathers telemetry, encrypts payload
POST https://api-js.datadome.co/js/
content-type: application/x-www-form-urlencoded
payload: "jsData=U2FsdGVkX1%2B9x...&event=load"

// 3. API evaluates payload
status: 200 OK
set-cookie: datadome=13m...; Max-Age=31536000; Path=/; Secure; SameSite=Lax

// 4. Retry original request with clearance cookie
GET /api/v1/pricing
cookie: datadome=13m...
status: 200 OK // Access granted
// 05 — payload signals

What the API
actually collects.

The Device Check payload contains dozens of signals. These are the highest-weight features DataDome uses to classify the session.

PAYLOAD SIZE ·  ·  ·  ·   ~2.5 KB encrypted
EXECUTION TIME ·  ·  ·    40–120 ms
UPDATED ·  ·  ·  ·  ·  ·  2026-05-19
01

WebDriver & Automation Flags

binary kill switch · navigator.webdriver, cdc_adoQpoasnfa76pfcZLmcfl
02

Canvas & WebGL Hashes

hardware proof · Validates GPU rendering matches the User-Agent
03

Execution Timing

CPU benchmark · Detects slow VMs and patched JS environments
04

Mouse & Touch Biometrics

behavioral · Velocity, acceleration, and click coordinates
05

Plugin & Font Enumeration

entropy · Checks for standard OS font stacks
// 06 — our stack

Execute, don't emulate,

why reverse-engineering DataDome payloads is a trap.

Many scraping tools try to reverse-engineer DataDome's JS to forge the Device Check payload. This works for about a week until the encryption keys or payload structure rotate. DataFlirt takes a different approach: we execute the actual DataDome script inside a hardened, fingerprint-perfect browser environment. We don't fake the telemetry; we provide a real environment that generates valid telemetry naturally. This shifts the maintenance burden from cryptography to browser orchestration.

device-check.trace

Live execution metrics for a DataDome challenge in our fleet.

target.domain protected-ecommerce.com
script.version v4.11.2
execution.env DataFlirt Hardened Chromiumclean
telemetry.post 200 OK48ms
cookie.issued datadome=...valid
captcha.triggered false
pipeline.status proceeding to extraction

Stay ahead of the pipeline

Data engineering
intel, weekly.

Anti-bot shifts, scraping infrastructure updates, dataset delivery patterns, and business outcomes from our pipelines. Short, technical, no fluff.

By submitting, you acknowledge our Privacy Notice.

// 07 — FAQ

Common
questions.

Common questions about handling DataDome's telemetry endpoints, payload encryption, and clearance cookies.

Ask us directly →
Can I just block the DataDome JS script from loading? +
No. If you block the script, the Device Check API is never called, the telemetry is never sent, and you will never receive the datadome clearance cookie. Without that cookie, every subsequent request to the target will return a 403. You must execute the script and pass the check.
How often does the payload encryption change? +
DataDome rotates their obfuscation techniques and encryption keys frequently — sometimes multiple times a week. This makes static reverse-engineering of the payload highly brittle. Executing the script in a real browser bypasses this issue entirely, as the script handles its own encryption.
What happens if the Device Check API times out? +
DataDome is designed to fail-closed. If the client cannot reach api-js.datadome.co (e.g., due to a network block or ad-blocker), the session is treated as highly suspicious. You will either remain blocked or be served a hard CAPTCHA on the next navigation.
Does DataFlirt solve the visual CAPTCHA? +
We rarely have to. By providing pristine telemetry to the Device Check API via our hardened browser fleet, we achieve a high enough trust score that the CAPTCHA is never triggered. When it is triggered (usually due to IP reputation), our automated solvers handle it, but avoidance is the primary strategy.
How do mobile SDKs differ from the web JS? +
DataDome's iOS and Android SDKs collect different signals (e.g., device orientation, battery state, jailbreak/root status) and POST to different endpoints, but the core concept is identical. Mobile scraping requires either intercepting and forging these specific payloads or using physical device farms.
Is it legal to execute their JS in a scraper? +
Yes. Executing JavaScript provided by a website is the standard behavior of any web client. As long as you are accessing public data and not violating specific jurisdictional laws (like the CFAA in the US), executing the challenge script is legally indistinguishable from a normal user browsing the site.
$ dataflirt scope --new-project --target=datadome-device-check-api READY

Tell us what
to extract.
We do the rest.

20-minute scoping call. Pilot dataset within the week. Production within two. Whether you need a one-off catalogue dump or a continuous feed across millions of records — we scope, build, and operate the pipeline.

Start a pipeline → View pricing
hello@dataflirt.com  ·  Bengaluru  ·  IST  ·  typical reply < 4h
// 08 — keep reading

Related glossary terms

Anti-Scraping

DataDome 403 Block

The immediate consequence of failing the Device Check API telemetry evaluation.

Read →
Anti-Scraping

DataDome Score Threshold

The internal metric that determines if your telemetry earns a cookie or a CAPTCHA.

Read →
Anti-Bot Bypass

JavaScript Challenge

The broader category of active client-side interrogation techniques used by modern WAFs.

Read →
Anti-Bot Bypass

Browser Fingerprinting

The passive and active signals collected to uniquely identify your scraping client.

Read →