How to integrate

Everything below talks to the container you're already running (see Deployment). There's no SaaS endpoint and no API key — requests go to your own host, e.g. http://localhost:3000.

There are two ways to use it. Pick based on whether you need a real browser for the rest of your job, not on which sounds more robust.

	HTTP clients	Playwright / browser
Cost	~4 HTTP requests	a full browser per session
Speed	fast	slow
TLS fingerprint	yours (your client's)	Chrome's, genuinely
Use when	you just need the clearance cookie	the site needs a browser anyway

If all you want is a cookie, use HTTP clients. It's dramatically cheaper, and it's the path most integrations should take. Reach for the browser approach when you were going to drive a browser regardless — because the site is a SPA, needs a login flow, or renders content you can't get from raw HTML.

Calling the API

Both approaches are plain HTTP (plus a WebSocket, for Akamai in the browser flow) against your container:

Endpoint	What it does
GET /hc	Health check — {"status":"ok"}
POST /dd/solve	Solve a DataDome captcha or interstitial
POST /akamai/solve	Solve an Akamai sensor challenge from a URL
WS /akamai/session	Streaming Akamai session for browser-driven solving
GET /akamai/queue-metrics	Solve-queue depth, for autoscaling

Full contracts: Akamai · DataDome · OpenAPI spec.

If you're in TypeScript, the SDK gives you typed request and response shapes for these endpoints (types only — you still make the calls yourself).

Authentication

The container ships with no authentication in front of /akamai and /dd. It's licence-gated at startup, not per-request. Put it behind your own network boundary — a private subnet, firewall rules, or a reverse proxy that enforces an API key.

If you do front it with a reverse proxy that checks a header, every example in these docs threads an optional key through as x-api-key.

Two rules that decide whether this works

Almost every "the solve failed" report comes down to one of these.

1. Submit from the IP you'll browse from

Anti-bot vendors bind the clearance cookie to whichever IP submitted it. If the solver submits on your behalf, you get a cookie that's valid for the container and void from your scraper — a fresh 403 on the very next request, which looks exactly like a failed solve.

/dd/solve is built around this: it returns a prepared submission rather than sending one, so you make the request from the address you'll browse from. See why you send the submission.

2. Keep the identity consistent

The profile / js_profile you send the solver has to match the headers you actually put on the wire — user agent, sec-ch-ua, platform, language, timezone. These get cross-checked. Changing a user agent in one place and not the other is the single most common way to get a solve rejected, and the error it produces looks nothing like the cause.

Solving is not the same as staying unblocked

Worth setting expectations: the solve can succeed and the site can still refuse you afterwards. Clearance cookies get you past the challenge; whether the site then honours the cookie depends on separate signals — chiefly your TLS fingerprint and IP reputation.

If you're solving successfully but still getting blocked:

• Datacenter IPs are frequently rejected regardless of a valid cookie. Try a residential pool.
• Non-browser TLS fingerprints are visible to the site even when the cookie is good. This is a different problem from solving, and it's the main reason to use the browser approach despite the cost.

Next

• Using HTTP clients — axios, undici, fetch
• Playwright / browser
• SDK