Request Unsuccessful Incapsula Incident ID: Causes, Fixes

The page reading "Request unsuccessful. Incapsula incident ID:" followed by a long number is a block page from Imperva's cloud WAF and bot protection. Incapsula is the product's old name, and Imperva is now part of Thales. The site's owner set a rule, and your request matched it. The incident ID is a reference number that only the owner can look up.

What does the Incapsula incident ID mean?

Imperva sits in front of the website as a proxy. It inspects each request before the request reaches the site. When a request breaks one of the owner's rules, Imperva returns its own error page instead of the site's content.

According to Imperva's Cloud WAF error codes documentation (last updated August 25, 2026), the error page carries "information to help you identify the error in your account in the Cloud Security Console". The details include the error code, a time stamp, "the source IP address of the request", the IP and internal ID of the Imperva proxy, and "the incident ID".

The owner's side of that process is spelled out in the same page: "You can use these details, such as the Incident ID, to filter for and investigate the incident on the Security Events page in the Cloud Security Console." You cannot look the incident up yourself. The ID is useful only once you hand it to the site.

Is Incapsula the same as Imperva?

Incapsula and Imperva are the same service. Incapsula was the brand of Imperva's cloud application security, and the string "Incapsula" survived on block pages after the rename. Imperva now belongs to Thales, and its documentation lives on docs-cybersec.thalesgroup.com. Whatever the page calls it, the block comes from the site owner's Imperva configuration, not from your ISP or your browser.

What do the Imperva error codes mean?

When the block page shows an error code, the code tells you which kind of rule fired. The table below quotes or paraphrases Imperva's own descriptions.

Why am I being blocked by Imperva?

Imperva blocks a request because something in that request matched a rule the site owner turned on. The common triggers are:

• IP reputation and source. The request came from a datacenter, a VPN exit or a proxy range that other traffic has already abused. Block Specific Sources (code 16) and Block IP (codes 14 and 15) act on this.
• Bot signals. The client does not behave like a browser. It may skip JavaScript, send unusual headers or fire requests faster than a person would. Bot Access Control (code 16) handles this.
• No cookies. Imperva tracks sessions with cookies. A client that drops them looks like a fresh visitor on every request, and code 17 names that case directly.
• A challenge that never ran. A CAPTCHA page (code 12) is content a script does not see as a challenge. The script records it as the response and moves on.

Code 14 deserves a closer reading. Imperva states: "Once the user or IP is blocked, the related session is blocked, and subsequent requests trigger this error." Every request in that session keeps failing. Refreshing the page will not clear it, and neither will retrying the same call in a loop.

How do I fix the Incapsula block as a visitor?

Work through these steps in order and stop when the page loads.

1. Retry in a normal browser. Use a current Chrome, Firefox or Safari with cookies and JavaScript on. Turn off script blockers for that one site.
2. Clear the site's cookies. Imperva gives this advice for code 3, and it also resets a damaged session.
3. Switch off your VPN or datacenter proxy. Retry from your home broadband or your phone's mobile data. Many sites block hosting ranges outright, and a VPN exit shares its address with thousands of strangers. If you think a VPN is off but the page still fails, a WebRTC leak test shows whether another address is being exposed.
4. Check what your IP looks like. The check below shows whether your current address reads as mobile, residential, datacenter or VPN.

5. Contact the site owner. Send the incident ID, the time you saw the page (with your time zone) and your public IP. Those three details are what the owner filters on in the Security Events page. "I got blocked" with no ID leaves them nothing to search.

If the address checks out as a plain consumer connection and the block persists, the rule is about you or your session rather than your network. Only the owner can lift that.

Why does a scraper or API client get the Incapsula block?

Scripts hit Imperva blocks far more often than browsers. A script usually runs from a cloud server, which means a datacenter IP. A script also tends to drop cookies between requests and skip the JavaScript a browser would run. Each of these maps to one of the codes above. A datacenter IP alone can be enough to get the request refused before it reaches the site. Datacenter vs residential vs mobile proxies explains how sites tell those IP types apart.

Some fixes come before any change of IP:

• Use the official API if the site offers one, and authenticate the way its documentation says.
• Keep cookies across requests. A session object in your HTTP library does this for you. Python Requests proxy setup shows sessions and proxies together.
• Slow down and respect robots.txt and the site's terms. A polite crawl rate trips fewer rules.
• For a partner integration such as an OData or OAuth connection, ask the owner to review the incident and make an exception for your traffic. Allowlisting a fixed server IP is usually a cleaner fix than routing through a proxy.

For lawful collection of public data, the source IP still matters. VoidMob runs mobile proxies on real 4G/5G devices, alongside non-VoIP SMS verification and eSIM. Every exit, in the shared pool and on dedicated devices, is a real device on a consumer carrier connection. Its public IPv4 address sits behind the carrier's CGNAT, shared with that carrier's ordinary subscribers.

As of October 2026, the shared pool costs from $3.99 per GB on a list that rotates per request or holds a sticky IP, and dedicated devices start at $49 a month. A mobile IP fixes the source signal only. Bot Access Control also judges the client, so a client without cookies or one that ignores challenges can still be refused. Mobile proxies for web scraping covers the full setup.

How is the Incapsula block different from a Cloudflare block?

Both are WAF block pages, and both are triggered by the site owner's rules. They come from different vendors, though, so the reference you send the owner differs. Imperva gives an incident ID. Cloudflare gives a Ray ID. If a Cloudflare page is what you are seeing, Sorry, you have been blocked walks through that one.