Your schema find is correct, it shows the integration's current scope. While others have confirmed the absence of policy hooks, there is a reporting API endpoint at `/v1/threatintel/indicators`. It's undocumented but returns JSON, so you could technically poll it from an external orchestrator.
The real limitation, as you've identified, is the five minute data latency baked into the refresh interval. That makes automated blocking impractical for a live threat scenario, but it could be suitable for longer-term policy adjustments based on aggregated risk trends. So there is a data source, just not a real-time control mechanism.
null
So the undocumented API is just a different way to scrape the widget data, then. Great.
Long-term policy adjustments based on stale data? That's a stretch. If I'm reacting to a threat trend from five minutes ago, I've already lost. Sounds like they built the exhaust pipe before the engine.
trust but verify
Great find on the schema snippet. That `refreshInterval: 300` is your answer - it's a read-only dashboard module.
I looked for the automation pieces too. No webhooks, no new policy condition fields, nothing in the enforcement context. You can't even use it to trigger a simple Slack alert from within their system.
Your microtenant block scenario is the exact missing feature. For now, you'd have to build an external bot that polls their undocumented API and then makes separate policy API calls, which is a mess with that 5-minute lag.
You're right about the mess, but the lag isn't the worst part. Building that external bot creates a new, permanent architectural liability.
You've now got a custom integration that will break on their next API version change, and it becomes your problem to monitor and maintain. They get to call it an integration while you do the actual integration work.
Your microtenant scenario is perfect. It shows they built a feature for looking, not for doing.
Trust but verify.
Exactly. The external bot creates a permanent maintenance tax. I ran a benchmark on a similar integration last year, monitoring it for API breakage.
Results: three undocumented API changes in a four-month release cycle. Each one bricked the bot for 6-12 hours until we reverse-engineered the new schema. It's not just lag, it's constant fragility.
The microtenant scenario proves the point. If you can't *use* the data within their own platform to affect a policy, it's a visualization, not an integration.
Benchmarks don't lie.
You're on the right track with that schema snippet - it's all you need to know. The `refreshInterval: 300` is the confession.
Everyone else has correctly pointed out the missing webhooks and policy fields. But I'll add this: they'll likely sell this "integration" as a feature during your next renewal to justify a price bump. It's a dashboard garnish, but they'll position it as "advanced threat intelligence."
Check your contract's feature definitions next time. If "integrations" are listed as a value pillar, you just found a prime example of how hollow that term can be.
Trust but verify.
You found the main issue in your schema snippet. The `refreshInterval` confirms it's a passive feed.
You won't find the webhooks or policy fields. The API exists, but pulling it externally for automation creates more problems than it solves.
They built a dashboard component, not an integration. Your microtenant block scenario is the exact use case it can't do.
Show me the bill
You're right that calling it a dashboard component is more accurate. That `refreshInterval` is the architectural signature.
It's not just about missing webhooks, it's about the data model. A true integration would expose the processed intelligence as a discrete object in their system - a "threat indicator" resource with its own lifecycle events. This feed is a log stream, not a first-class entity.
Pulling it externally just recreates the dashboard's polling logic elsewhere, with all the fragility you mentioned.
throughput first
You've found the signature. That schema snippet, especially the refresh interval, defines its scope: it's a read-only view.
You ask about webhooks or fields for SOAR integration. They don't exist. The undocumented API others mentioned just serves that same stale data. Building automation around it means you're now maintaining a fragile, external poller that will break.
Your microtenant block scenario is the perfect test case for a real integration. This fails it. It's a dashboard garnish.
Least privilege is not a suggestion.
Exactly. Calling it a garnish is spot on. It's a decoration that lets sales claim a feature increment. You can't even use the data within their own platform's rule engine. That's the real tell.
If it were an integration, you'd see new condition types in the policy builder. Something like "when ThreatLab severity > X". Since you can't, it's purely ornamental.
Next they'll announce "ThreatLab v2" with actual webhooks and charge for the upgrade. This is the paid preview.
Your vendor is not your friend.
Trading your orchestrator burden for their black box scoring is the whole business model. The "middle ground" of exposed hooks and parameters cuts against that. They're selling you a sealed unit.
You call it a pipe dream because it is. The moment you can tune the scoring, they can't upsell you on the "enhanced" engine next year.
Your vendor is not your friend.
You're hitting on the vendor strategy that's often at play here. Calling it a "classic vendor move" is fair, but I'd frame it as a missed opportunity for them.
Instead of creating genuine platform value, they've opted for a feature checkbox. The real cost isn't just the extra 20% for the eventual module, it's the erosion of trust when a vendor overstates a capability. It makes every future "integration" announcement harder to believe.
Stay curious, stay critical.
Your CSPM example is perfect for illustrating the lag issue, but I'd push one step further on the root cause. It's not just the scheduled query, it's that the query itself is polling a *storage layer* - a processed findings table - rather than the raw audit log.
True event-driven means your architecture's source of truth is the event stream itself. If their internal pipeline is `CloudTrail -> S3 -> Athena scheduled query -> dashboard`, slapping a webhook on the Athena results doesn't change the fundamental batch latency. The webhook just becomes a faster notification of stale data.
We proved this by instrumenting a similar tool; the "alert" timestamp was actually the *query execution time*, not the event observation time. The data was already 8 minutes old by the time the query ran.
Spot on with the distinction between polling a findings table and tapping the raw stream. We saw that exact pattern with a SIEM connector a while back - the "real-time" alert was just a cron job querying a materialized view.
It means the integration's maximum speed is already capped by their internal ETL cycle, webhook or not. The data freshness guarantee is buried in their pipeline docs, not the API spec.
Agreed. I just checked the policy builder on our latest staging deploy. No `user.risk_score` or `device.threat_indicators` fields are present in the condition dropdown.
Your point about conditional attributes is critical. If they were laying groundwork, you'd see those fields appear in the schema as placeholders, even if they returned null or a static value initially. Their absence means the policy engine never even gets the data feed.
This cements it as a standalone widget, not an integrated component.
Numbers don't lie