I've been evaluating WAF and DDoS solutions for our deployment pipeline's external endpoints. Imperva is on my shortlist, but I'm hitting a wall with the initial onboarding. Their free trial signup process appears to be non-functional.
After navigating to the official trial page, the form submission consistently results in a generic error: "We are unable to process your request at this time." No specific validation errors, no confirmation email, nothing. I've attempted this across three different browsers (with extensions disabled) and from two separate network environments.
Has anyone successfully navigated this recently? My standard troubleshooting steps—clearing caches, trying incognito mode, verifying no ad blockers—haven't yielded results. I'm particularly interested if there's an alternative entry point, perhaps through their developer portal or a partner channel, that bypasses this broken front-end flow.
Ideally, I'd like to test the API integration with a simple CI/CD stage that pushes a configuration change. My goal is to see how their security rules can be managed as code, perhaps through a Terraform provider or a REST call from a GitHub Action.
--crusader
Commit early, deploy often, but always rollback-ready.
I encountered a similar issue last month. In my case, the problem was the company email domain on my application. Using a personal email address allowed the form to submit successfully, suggesting their trial system may have a poorly documented filter for certain corporate domains or subnets.
Regarding your API integration goal, their Terraform provider is functional but lags behind their UI by several releases. You can find it in the Terraform registry. For initial testing, you might have better luck using their official API documentation directly to script a proof of concept, assuming you can get an API key via an alternative channel like their sales engineering team.
prove it with data
The corporate domain filter observation is plausible. I've seen similar systems block entire IP ranges associated with large cloud providers as well. If you're coming from a known AWS or GCP IP block, you might also trigger a silent security rule.
Your point about the Terraform provider lagging is a significant cost factor. Using an outdated provider can lead to deploying resources that aren't optimized for the current pricing model, which can quietly burn through trial credits or result in suboptimal configurations that are more expensive to run long-term. Direct API calls might be more work initially, but they give you precise control over what you're provisioning.
CloudCostHawk
That's a frustrating start, especially when you're trying to set up a critical pipeline. The workaround about the corporate email domain or cloud IP is likely the culprit.
If you need an API key to test that CI/CD stage, you could try their live chat support directly from the main site. They're often quicker for generating trial access than the broken form. Just be ready to verify it's for a real business evaluation.
Once you're in, their API docs are decent for scripting config changes, but I found their rule definitions can be a bit verbose for simple tests. Maybe start with a single, non-production endpoint?
That's a really good point about cloud IP blocks being a silent filter. I hadn't considered that, but it makes perfect sense for a security company. I wonder if the filter is based on a third-party threat intel feed they've integrated. Those can sometimes flag entire netblocks from data centers due to historical abuse, which isn't helpful for legitimate trial users.
The cost angle on using an outdated Terraform provider is something I'm always nervous about. Beyond just credits, could a deprecated provider resource definition potentially create a configuration that violates their current security policies? Like, it might let you deploy a rule set that's technically accepted by the API but is considered an insecure default now, leaving you exposed without realizing it. That feels like a hidden risk on top of the financial one.
Ugh that sounds exactly like my experience last week! The exact same error. I gave up on the form and used their live chat like someone else mentioned. It took maybe 15 minutes but the sales support person just created a trial account for me directly after a couple quick questions.
But yeah, that broken form for a security product is... not a great sign, right? Makes me wonder about the onboarding for their actual API.
What kind of CI/CD stage were you thinking of testing? I'm trying to connect it to a simple Zap for alerting, but it's taking me ages to figure out.
Yeah, that broken signup for a security service is a bit ironic, isn't it? 😅 Your experience with the live chat lines up with what I've heard - it's the de facto backdoor.
> trying to connect it to a simple Zap for alerting
If you're hitting API snags for a Zapier integration, their webhook setup can be finicky. I ended up using a tiny Python Flask server as a relay for testing. Sometimes it's easier to have a script log the raw JSON from their alert endpoint first, just to see the exact structure, before plugging it into Zapier's webhook step. The docs sometimes show a simplified version that doesn't match reality.
Prompt engineering is the new debugging
That broken signup flow is a classic pain point during vendor evaluation, and you've done the right diagnostic work. Since the official channel is blocked, you often need a backchannel.
The suggestions about corporate email or IP blocks are valid. For your specific goal of testing API integration for CI/CD, I'd recommend bypassing the trial form entirely. Contact their sales engineering team directly via the website's chat or a contact form, stating you need a trial specifically to evaluate their API for pipeline automation. They can usually spin up a sandbox environment manually and provide you with an API key.
This approach actually gives you a better starting point, as you can ask specific questions about their Terraform provider's release cadence versus their API stability before you write any code. It turns a broken process into a direct technical conversation.
null
>Contact their sales engineering team directly... stating you need a trial specifically to evaluate their API for pipeline automation. They can usually spin up a sandbox environment manually
This is, somewhat tragically, the correct advice for a broken process. But let's not frame this as a positive "direct technical conversation" so quickly. Having to beg sales engineering for basic trial access is a filter in itself. It filters for teams with the patience and political capital to schedule a sales call just to kick the tires.
What you're really testing is their pre-sales responsiveness, not their API. If it takes them 48 hours to manually provision a sandbox, what does that imply about their actual support SLAs? The conversation might be more direct, but it's also one where you've already conceded to their inefficient workflow. It's a great way to see if their sales engineer is sharp, and a terrible way to gauge how the product works when you're on your own.
Forget the broken form. The live chat is your bypass. They'll manually create a trial after a couple of verification questions.
Don't bother with the Terraform provider for your initial test. It's stale. Script the API call directly from your GitHub Action first to see if the control plane is actually automatable.
> testing their API integration for a simple CI/CD stage
Their alert webhooks are verbose and often mismatch the docs. Spin up a local listener first to capture the real payload before you commit it to a pipeline.
slow pipelines make me cranky
That's a good practical point about skipping the stale provider to test the API directly. But if the docs are unreliable and you have to spin up a local listener to capture the real webhook payload, doesn't that add a lot of setup time just for a trial evaluation? It feels like their API's testability is low.
Yeah, that's the exact trade-off. All that extra setup for a trial does feel heavy, but maybe it's a filter? Like, they only want people who are serious enough to do the work.
But honestly, if the docs are unreliable, it makes me question the whole API stability. If I can't trust the docs for a simple webhook, how do I trust it for a production pipeline?
How much extra time would you say that listener setup added?
You've put your finger on the core concern. If they use poor docs as a "filter for serious users," they're filtering for people who tolerate bad documentation, which isn't a group you'd want to build a product team around.
That extra listener setup time is a real cost. For me, it was about an hour to get something logging. But the bigger question is what happens when you need to update your integration six months from now, and you have to reverse-engineer the API all over again because the docs are still wrong. That's the hidden long-term cost.
Keep it civil, keep it real.
That broken form is frustrating. I had to use the live chat too to get my trial, just like others said. They asked for my work email and created the account in a few minutes.
For testing the API from a GitHub Action, did you try their Cloud WAF API directly? I'm curious if the trial keys they give you have the same rate limits as the main docs say.
The extra setup time for the listener is a direct, measurable friction cost that's often omitted from ROI calculations for vendor trials. It's not just an hour; it's an hour multiplied by every engineer who needs to run the same evaluation.
If you're quantifying "API testability," I'd propose a simple metric: the time from receiving credentials to successfully receiving and parsing a valid, documented webhook event. A high time-to-first-value here strongly correlates with future integration maintenance debt, as user622 noted.
You could benchmark this against other services in the space. For a well-designed API, this process should take under fifteen minutes using only curl and their documented schema.
Data first, decisions later.