Hey folks, been evaluating Imperva's suite for a while now, primarily for API security in our FastAPI microservices. The tech itself is solid, but I'm curious about the business side.
Our team has been approached about their partner/reseller program a couple of times. On paper, it looks like a logical step since we already recommend and implement similar solutions for clients. But I've learned to test the business model twice before diving in, just like I test my code 😄
Has anyone here gone through their partner onboarding? I'm particularly interested in:
- The real margins after all the tiers and requirements.
- Technical support responsiveness for partners versus general support. Is there a dedicated channel, or is it the same queue?
- The commitment in terms of mandatory training or sales targets. The documentation is a bit vague on the ongoing obligations.
From a technical integration standpoint, I can vouch for their API. Setting up a simple policy via their API for a new client deployment is straightforward. Something like this for a baseline check:
```python
import requests
def create_initial_policy(api_url, api_key, site_id):
headers = {'x-api-key': api_key}
policy_data = {
"name": "Base_API_Policy",
"application": "API",
"detectionMode": "prevent",
"acls": [
{
"name": "Block_Excessive_Rate",
"action": "block",
"filter": {"rateBased": {"threshold": 1000, "window": 60}}
}
]
}
response = requests.post(
f"{api_url}/api/v2/sites/{site_id}/policies",
json=policy_data,
headers=headers
)
return response.json()
```
But the ease of tech integration doesn't always translate to a good partner experience. Would love to hear any stories—good or bad—before we consider signing anything.
Good on you for testing the business model like code. I can speak to the support and training side.
The technical support channel is indeed separate for partners, but my experience is that the response time advantage isn't as significant as they imply. You still often get routed to a Tier 1 queue before escalation. The real differentiator is having a partner-specific technical account manager after you hit a certain revenue threshold, which is a game changer for complex deployments.
Regarding mandatory commitments, the training is substantial and non-negotiable. You'll be looking at several certification paths just to get started. The sales targets are soft initially, but they become a hard requirement for maintaining your discount tier after the first year. If you miss them, your margin can drop by 10-15 points overnight. My advice is to model your projections using that lower margin figure to be safe.
Your API snippet is a good start, but you'll want to build a more robust pipeline for managing policy configurations across clients. I ended up creating a simple metadata-driven system in dbt to track and version our client's Imperva policy states because their own reporting for partners is surprisingly poor on historical configuration changes.
Garbage in, garbage out.
The point about modeling projections with the lower margin figure is critical. We built our internal ROI calculation exactly that way, and it flagged two clients as unprofitable at the lower tier, which changed our entire go/no-go decision tree.
Your dbt approach for tracking policy states is clever. We've faced similar reporting gaps and opted for a different path, using Terraform's Imperva provider to manage configurations as code, then leaning on Terraform Cloud's state versioning for audit. It creates a single source of truth for deployment drift, though it doesn't help with historical reporting on policy efficacy.
What was the driver for choosing dbt over the infrastructure-as-code route? Was it primarily for the analytics layer, to aggregate data from their APIs for client reporting?
infra nerd, cost hawk
Good question about the technical side of their API. I've used it in production, and while the basics are straightforward, you need to account for their eventual consistency model. Creating a policy with that Python snippet might show a success, but the policy won't be fully active and propagated across their network for a few minutes. Your automation needs to poll for the actual `"status": "active"` state before assuming it's live.
The bigger gotcha is their API rate limiting. It's strict and not well documented in the standard partner materials. For provisioning across multiple client accounts, you'll hit 429 errors unless you build in significant backoff and retry logic. I'd recommend wrapping all your calls in a resilient client from day one.
On the partner support channel, I agree with user517's point, but I'd add that the quality of the initial response is higher. You get someone who understands the partner context, even if they're Tier 1. The real value for me has been the internal documentation access - their runbooks for common integration patterns are solid and saved us a lot of trial and error.
Prod is the only environment that matters.