reese84 cookie?Short answer: reese84 is the cookie Imperva (the company formerly known as Incapsula) issues after its JavaScript sensor has run on your browser and passed. It is short-lived — commonly five to fifteen minutes — and bound to the session, user agent and IP that produced it. It replaced the older incap_ses / visid_incap pair as the bot-detection signal of record, though both of those still appear on Imperva-protected sites.
If you arrived here with a 403 and an Incapsula incident ID, skip to the 403 section. If you are deciding between running a browser and calling a solving API, read two ways to handle it.
A reese84 value is an opaque string, typically a few hundred characters, URL-safe base64-ish — letters, digits, and occasionally + / =. It carries no readable timestamp and no readable user id. You cannot decode it into a fingerprint, and there is nothing to learn by base64-decoding it beyond noise; what it encodes is checked server-side against a keyed hash.
Two practical consequences:
In Chrome DevTools it appears under Application → Cookies for the protected host with a Path of / and, usually but not always, HttpOnly set. If it is HttpOnly, document.cookie in the page cannot see it — read it from the response headers or from the browser context, not from injected JavaScript.
The page loads a sensor script — often served from a path containing _Incapsula_Resource, or from a per-site UT.mvc URL. That script gathers browser signals, encrypts them with per-site keys, and POSTs back to an endpoint that answers with Set-Cookie. Three consequences follow directly:
That third point is where most projects break. The cookie is not a bearer token; it is a verdict attached to a specific client. Copying it into a different IP, a different User-Agent, or a different TLS stack invalidates it immediately.
| Binding | Symptom when violated |
|---|---|
| IP address | Immediate re-challenge on the next request, even seconds later. |
| User agent + TLS fingerprint | Cookie looks valid, endpoint returns 403 with an Imperva block page. |
| Cookie lifetime (minutes) | Works, then flips mid-run. Long jobs must refresh, not cache. |
| Request rate | Cookie revoked early; the value that survived 50 requests fails at 200. |
The short lifetime is deliberate. A five-minute window forces any automated client to keep proving it can run the sensor, which is exactly the thing a bot farm cannot do at scale. For a scraper, this converts into an architectural requirement: a refresh loop, not a login.
Before optimising anything, confirm the vendor — the fix for Imperva is not the fix for Cloudflare or Akamai.
X-CDN: Incapsula, and very often X-Iinfo with a colon-separated tuple._Incapsula_Resource, and a UT.mvc script URL.reese84, incap_ses_*, visid_incap_*, nlbi_*.If you see __cf_bm / cf_clearance instead, that is Cloudflare — see cf_clearance. If you see _abck / bm_sz, that is Akamai — see _abck. If you see datadome, that is DataDome.
Imperva's block response is not a JSON error. It is a full HTML page, usually with HTTP 403, containing an incident ID like Request unsuccessful. Incapsula incident ID: 123-000000000-000000000000000. The incident ID is Imperva's own correlation handle; it identifies the block event on their side and is not a code you can look up. What it tells you is which layer blocked:
| Where the 403 came from | What usually fixes it |
|---|---|
No reese84 at all | Solve once to obtain one, then send it on every request with the same IP. |
reese84 present but stale | Refresh. Do not retry the same value; it fails deterministically. |
| Cookie present and fresh, still blocked | Fingerprint mismatch — the cookie was minted for a different client. Re-solve from the client that will use it. |
| Works, then blocks after N requests | Rate. Slow down or spread across exits, and expect earlier revocation. |
incap_ses_* — session identifier, one per session, suffixed per zone.visid_incap_* — visitor identifier, longer-lived, used for returning-visitor scoring.nlbi_* — load-balancer affinity, not a security cookie, but useful for session stability.__utmvc — sensor bookkeeping, seen alongside the others on some properties.Keep all of them in one cookie jar keyed by exit IP. Mixing cookies from two solves across one jar is a common self-inflicted block.
Run the sensor yourself. A real browser on a fixed IP passes the challenge and holds the cookie for its short life. This is what a scraping browser pool does: honest and expensive. In Playwright the shape is:
ctx = browser.new_context(proxy=PROXY) # same exit every time page = ctx.new_page() page.goto(url) # sensor runs here jar = await ctx.cookies() # reese84 now present # reuse jar for direct HTTP calls through PROXY only, # and re-run this block when a 403 shows up
The two mistakes to avoid: rotating proxies inside one context (the cookie is bound to the exit that minted it), and caching the cookie across runs (it will already be dead).
Ask for the cookie. A solving API takes the site URL — and the script URL when the site hides it — and returns a fresh reese84 together with the proxy exit that should be used with it. SolveHub exposes this through one REST endpoint and bills per completed task; the detail that matters is that real requests must leave through the same exit that produced the cookie.
There is a third path people miss: Imperva-protected sites usually leave sitemaps, RSS feeds, static assets and some JSON APIs completely unprotected. If the data you want is reachable there, no cookie is needed at all.
Is reese84 the same as incap_ses? No. incap_ses is a session id; reese84 carries the bot verdict from the sensor.
Can I reuse one cookie for many parallel requests? Briefly, if they share the same IP and fingerprint. Aggressive fan-out is itself a revocation trigger.
Why does the endpoint return challenge HTML instead of JSON? The cookie expired or the session drifted. Re-solve instead of retrying the same value.
Does reese84 work from requests or httpx alone? Yes, once you have a live value — but only if the HTTP client's TLS fingerprint and headers match the client that minted it. Plain requests usually does not match, which is why the cookie appears to "not work" when it is in fact just mismatched.
How often should I refresh? Assume six to ten minutes as the safe ceiling, and treat any 403 as an immediate refresh signal rather than a retry signal.
Is reese84 ever long-lived? Rarely. Some properties issue a longer window for already-trusted visitors, but you cannot reach that state from a cold start, so plan for the short case.