Do you generate reese84 or solve UTMVC?

Both. Takion covers the newer reese84 sensor and the older ___utmvc obfuscated-JS challenge, and returns them alongside the incap_ses and visid_incap session cookies so the full set replays cleanly.

Is Incapsula the same as Imperva?

Yes, Incapsula is Imperva's bot-protection product. Whether the target labels it Incapsula or Imperva, the reese84 and UTMVC flows are the same and Takion covers both under one endpoint.

The reese84 payload keeps changing. Do you track it?

Yes. reese84 rotates and re-obfuscates, so we generate it against the live script on each call and run regression tests against a real Imperva target to catch changes early.

What about the new GeeTest-based Incapsula challenge?

Imperva has begun layering a GeeTest captcha on some reese84 sites (SmythsToys, for one). Takion handles that variant as well, on the same endpoint.

How do you generate the reese84 cookie?

In two steps. You POST the challenge script to /reese84 and we return an encrypted **payload**. You POST that payload to the site's own reese84 endpoint, and the site answers with the **token** you set as your reese84 cookie. We do the hard part, the encrypted payload Imperva's obfuscated script would have built. The final POST stays on your side, so the cookie is bound to your own session and IP.

How does the ___utmvc solve work?

Pull the `_Incapsula_Resource` script URL out of the page HTML (a `src="/_Incapsula_Resource?..."` match), load that script, then POST its content plus your current session cookies to /utmvc. We return the ___utmvc value. Set it on your session and retry the original request. That is the whole flow, no browser anywhere in it.

Why do I get a 403 even with a valid reese84 cookie?

Almost always a User-Agent, proxy, or TLS mismatch. reese84 is bound to the session it was solved under. Pass the **same User-Agent** on the challenge fetch, the Takion call, and the final request, and replay through a clean proxy with consistent TLS. A cookie that is valid but replayed from a different fingerprint reads as a hijack and gets blocked.

Is bypassing Incapsula allowed?

Takion is for data you are authorized to reach: your own accounts, public listings, ticket price and availability, sites you have permission to automate. It is not for fraud or abuse, and our acceptable-use policy draws that line. What you do with a cleared session is on you.

Incapsula bypass, reese84 generated.

An Incapsula (Imperva) bypass without a browser. Takion generates a valid reese84 sensor and the ___utmvc cookie in one POST, so your requests clear Imperva and reach the data.

Last updated July 2026 · Coverage tested against a live Incapsula / Imperva target.

Getting blocked by Incapsula?

Incapsula (Imperva) will not serve you until your request carries the cookies it expects: a validated reese84 sensor or the ___utmvc challenge cookie, plus the incap_ses / visid_incap session pair. Takion generates them from the live challenge script, server-side, and returns the full set ready to replay. Attach the cookies to your request and Imperva lets you through.

How Incapsula works

Incapsula (Imperva) ships two challenge families: the older UTMVC obfuscated-JS challenge that sets the ___utmvc cookie, and the newer reese84 sensor that POSTs an encrypted payload to an /_Incapsula_Resource endpoint and gets back a validated cookie. Both are heavily obfuscated and rotate, and the reese84 payload in particular is a moving target that breaks naive re-implementations.

Takion generates both (a valid reese84 sensor and the ___utmvc cookie) and returns them with the incap_ses and visid_incap session cookies. One POST, no browser, no de-obfuscating Imperva's script by hand; the cookie set comes back ready to replay against the target.

Imperva has also started layering a new WAF on some reese84 sites, a GeeTest-based captcha on top of the ___utmvc or reese84 cookie (SmythsToys is one). Takion covers that path too, under the same endpoint.

Challenges Takion covers
reese84 sensor generation
UTMVC obfuscated-JS challenge (___utmvc)
_Incapsula_Resource POST flow
incap_ses / visid_incap session cookies

What one call returns

One call to the Incapsula endpoint returns the validated cookie set, reese84 or ___utmvc plus the session cookies, ready to replay against your target.

reese84

the sensor cookie in its validated state

___utmvc

the UTMVC challenge cookie

incap_ses / visid_incap

the session cookies paired with the sensor

# reese84
curl -X POST https://incapsula.takionapi.tech/reese84 \
  -H "x-api-key: $TAKION_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "script": "<the reese84 challenge script>" }'
# → { "payload": "<reese84 cookie value>" }
#
# UTMVC: POST https://incapsula.takionapi.tech/utmvc with the challenge HTML → { "___utmvc": "..." }

Read the Incapsula / Imperva docsSame key, every wall. Same JSON shape, every vendor.

How the Incapsula bypass works, end to end

Two challenge paths, one endpoint. No browser, no de-obfuscating Imperva's script by hand.

1
You hit the wall
Instead of the page, Incapsula serves a challenge. Either the reese84 script (a JSON body with a token) or a _Incapsula_Resource script for the ___utmvc path.
2
You grab the challenge script
For reese84, read the challenge script response. For ___utmvc, pull the _Incapsula_Resource URL out of the page HTML and load it.
3
You POST it to Takion
Send the script text to /reese84, or the script content plus your current session cookies to /utmvc. One call, no SDK.
4
We generate it server-side
Takion runs the logic Imperva's obfuscated JS would have run and builds the encrypted reese84 payload or computes the ___utmvc value. No headless Chrome anywhere.
5
You set the cookie and replay
For reese84, POST the payload we return to the site's reese84 endpoint and set the token it hands back as your reese84 cookie. For ___utmvc, set the cookie directly. Send your request again through the same session and you are in.

The Incapsula cookies, decoded

Two sensors, a session pair, and a captcha layer. Here is what each one is:

reese84: the sensor cookie, generated from an encrypted payload you POST back to the site. Imperva's main gate on ticketing sites like Ticketmaster
___utmvc: the older challenge cookie, computed from the _Incapsula_Resource obfuscated script. Validates browser-specific signals
incap_ses / visid_incap: the session and visitor cookies Imperva pairs with the sensor. They tie your requests to one session
GeeTest WAF: the newer captcha layer on some reese84 and ___utmvc sites (SmythsToys). The ___utmvc path sets incap_sh_xxx cookies on top

Why request-based beats a headless browser here

reese84 is heavily obfuscated and it rotates. The browser way to beat it is a fleet of headless Chrome instances, each running Imperva's script, building the sensor payload, and hoping the fingerprint holds. It works until Imperva re-obfuscates, and it costs you a browser farm, constant patching, and seconds per request.

Takion reverses the challenge and generates the payload directly. A solve is one HTTP round trip instead of a full page render. No Chrome farm to babysit, no Selenium retries when a container dies mid-challenge. You send the script, you get the payload or the cookie back. Same story for the ___utmvc path.

What gets an Incapsula session flagged

A valid cookie is necessary, not sufficient. Imperva watches for these the moment you replay:

User-Agent drift. The most common failure. Your User-Agent has to be identical on the challenge fetch, the Takion call, and the final request. One mismatch and the sensor reads as a different client.
Proxy or TLS mismatch. Even a valid reese84 fails behind a bad proxy or a mismatched TLS stack. Keep the client consistent and the proxy clean.
Skipping the payload POST. reese84 is not the value we return. You POST our payload to the site, then set the token it answers with. Set our payload directly and it will not clear.
Missing session cookies. A reese84 or ___utmvc without the incap_ses / visid_incap pair reads as an incomplete session.
Bad-reputation proxies. Flagged datacenter ranges get blocked before the challenge even loads. Clean residential or ISP proxies clear the reputation gate first.

The one rule that kills most 403s

Keep one User-Agent across the whole session. Same UA on the challenge fetch, the Takion call, and the final request. Match it with a clean proxy and consistent TLS, and Imperva stays cleared.

Some sites using Incapsula

Incapsula / Imperva guards these sites. Takion clears it on each, so a smyths toys bypass is the same one POST as any other wall.

Smyths Toys

reese84 and the new GeeTest WAF

Incapsula bypass FAQ

: Both. Takion covers the newer reese84 sensor and the older ___utmvc obfuscated-JS challenge, and returns them alongside the incap_ses and visid_incap session cookies so the full set replays cleanly.
: Yes, Incapsula is Imperva's bot-protection product. Whether the target labels it Incapsula or Imperva, the reese84 and UTMVC flows are the same and Takion covers both under one endpoint.
: Yes. reese84 rotates and re-obfuscates, so we generate it against the live script on each call and run regression tests against a real Imperva target to catch changes early.
: Imperva has begun layering a GeeTest captcha on some reese84 sites (SmythsToys, for one). Takion handles that variant as well, on the same endpoint.
: In two steps. You POST the challenge script to /reese84 and we return an encrypted payload. You POST that payload to the site's own reese84 endpoint, and the site answers with the token you set as your reese84 cookie. We do the hard part, the encrypted payload Imperva's obfuscated script would have built. The final POST stays on your side, so the cookie is bound to your own session and IP.
: Pull the _Incapsula_Resource script URL out of the page HTML (a src="/_Incapsula_Resource?..." match), load that script, then POST its content plus your current session cookies to /utmvc. We return the ___utmvc value. Set it on your session and retry the original request. That is the whole flow, no browser anywhere in it.
: Almost always a User-Agent, proxy, or TLS mismatch. reese84 is bound to the session it was solved under. Pass the same User-Agent on the challenge fetch, the Takion call, and the final request, and replay through a clean proxy with consistent TLS. A cookie that is valid but replayed from a different fingerprint reads as a hijack and gets blocked.
: Takion is for data you are authorized to reach: your own accounts, public listings, ticket price and availability, sites you have permission to automate. It is not for fraud or abuse, and our acceptable-use policy draws that line. What you do with a cleared session is on you.

Incapsula / reese84 reverse-engineering write-ups

Every other wall

DataDome PerimeterX / HUMAN NuData Castle AWS Cognito Akamai Bot Manager Cloudflare hCaptcha GeeTest

Start bypassing Incapsula today.

Start free, no card. One key clears every wall, and your first solve lands within the hour.

Free trial Pricing