Security Intelligence APIs Operations Index

Security Intelligence APIs Operations Index

All available Security Intelligence APIs Operations

Application Monitoring
POST
Fetch All Results By Time

Retrieve overall monitored flow counts across all applications, bucketed by time.

The time granularity is automatically determined based on the time interval length:

  • 1 hour or less: 5-minute granularity
  • More than 1 hour, up to 24 hours: 1-hour granularity
  • More than 24 hours: 1-day granularity

Use this endpoint to draw the top-level flow trend chart in the Application Monitoring dashboard. For per-application breakdowns, use POST /monitoring/applications/results-by-app instead.

Filter notes:

  • id: restrict results to a specific application UUID
  • application_type: restrict to CRITICAL or REGULAR applications
  • If time_selection is omitted, defaults to the last 1 hour.
POST
List Application Monitoring Results

Retrieve monitoring results per application over a specified time interval, with pagination and filtering.

Each result contains flow metrics (unique flow count, unprotected flows, additional rule hits, east-west flows, external flows), the application's metadata, and the status of its most recent publish job. Use this endpoint to populate the Application Monitoring table view.

Key filters:

  • has_unprotected_flows: true - surface applications with security exposure (flows not covered by any specific allow rule)
  • application_connectivity_strategies - filter by the connectivity strategy set on the application's security policy
  • connectivity_preferences - filter by the policy's default connectivity preference (ALLOWLIST/DENYLIST)
  • display_name - substring match on application name

Use the id field in each result as the {application-id} path parameter for GET /monitoring/applications/{application-id}/monitoring-config, POST /monitoring/applications/{application-id}/flow-counts, and POST /monitoring/applications/{application-id}/publish-config.
POST
Fetch Application Monitoring Summary

Retrieve a summary count of applications grouped by monitoring status for a specified time interval.

Returns three counters:

  • apps_with_unprotected_flows - applications with flows that bypassed all specific DFW allow rules
  • apps_with_custom_rule_hits - applications where user-configured additional monitoring rules were hit
  • apps_with_no_hits - applications with no flows hitting the default any-any rule and no flows hitting additional monitoring rules

Use this endpoint to populate the summary cards at the top of the Application Monitoring dashboard. To drill into specific applications, follow up with POST /monitoring/applications/results-by-app.
PUT
Put Application Monitoring Config

Create or update the additional monitoring rules configuration for a specific application.

Additional rules let you track flows hitting specific DFW rules (beyond the default unprotected-flow monitoring). Each rule is identified by its site_id and rule_path. The full list of rules in the request body replaces any previously stored rules - this is a full overwrite, not a partial update.

The application_id in the request body must match the {application-id} path parameter. The {application-id} comes from the id field in POST /monitoring/applications/results-by-app results.

To read the current configuration without modifying it, use GET /monitoring/applications/{application-id}/monitoring-config.
GET
Get Application Monitoring Config

Retrieve the current additional monitoring rules configuration for a specific application.

Returns the list of DFW rules the user has configured to monitor for this application, along with standard resource metadata (_revision, _create_time, etc.).

The {application-id} comes from the id field in POST /monitoring/applications/results-by-app results. To modify the configuration, use PUT /monitoring/applications/{application-id}/monitoring-config.
POST
Get Application Flow Counts

Retrieve the ingress, egress, and intra-application unique flow counts for a specific application over a specified time interval.

  • ingress_flow_count - unique flows entering the application from outside
  • egress_flow_count - unique flows leaving the application to outside
  • intra_flow_count - unique flows between workloads within the same application

The {application-id} comes from the id field in POST /monitoring/applications/results-by-app results. If time_selection is omitted, defaults to the last 1 hour.
GET
Get Monitoring Settings

Retrieve monitoring settings for a specific site, including the list of scanner IPs excluded from infra monitoring.

Excluded scanner IPs are filtered out of infra monitoring flow data to prevent security scanners and vulnerability assessment tools from generating noise in monitoring results. Supported formats:

  • Single IP: "192.168.1.1"
  • IP range: "10.0.0.1-10.0.0.5"
  • CIDR: "192.168.1.0/24"

The {site-id} is the UUID of the NSX site (federation member or standalone). To update the exclusion list, use PUT /monitoring/site-settings/{site-id}.
PUT
Update Monitoring Settings

Create or update monitoring settings for a specific site.

If settings already exist for the site they will be fully replaced; otherwise new settings are created. All IP entries are validated before saving - invalid formats will return a 400 error.

Supported IP formats for excluded_scanner_ips:

  • Single IP: "10.10.10.10"
  • IP range: "10.10.12.1-10.10.12.4"
  • CIDR: "10.10.11.0/24"

Side effect: Changes take effect on the next monitoring data collection cycle. Flows where the source IP matches an excluded entry will no longer appear in infra monitoring results. Destination IPs are not checked.
POST
Publish Application Config

Initiate an asynchronous DFW policy publish job for a specific application.

The {application-id} comes from the id field in /monitoring/applications/results-by-app results.

Supported action types:

  • POLICY_CREATE: Create a new DFW security policy scoped to the application group. Optionally set a default connectivity preference and per-application connectivity strategies.
  • POLICY_UPDATE: Replace the default connectivity rule and per-app strategies on an existing policy. This is a full replacement - omitted fields are reset to defaults.
  • RULE_UPDATE: Update the forwarding action of an existing DFW rule. Default rules and auto-plumbed (rules created by segmentation strategy) rules are not supported.

Multiple actions of the same type are allowed in a single request (e.g. update several rules at once).

Polling for completion: The 202 response includes a job_id. Poll GET /monitoring/applications/{application-id}/publish-config/{job-id} until status is COMPLETED or FAILED. The status_url in the response points directly to that endpoint.

Side effects: Each POLICY_CREATE or POLICY_UPDATE action writes a DFW security policy to NSX Manager and triggers NSX realization. Do not call this endpoint in a polling loop.

Returns 409 Conflict if a publish job for this application is already in progress.
GET
Get Application Publish Config Job Status

Retrieve the status and per-action results of an asynchronous publish job for an application.

Poll this endpoint after calling POST /monitoring/applications/{application-id}/publish-config until status is COMPLETED or FAILED. The job_id comes from the id field in the POST /monitoring/applications/{application-id}/publish-config 202 response.

Each entry in results maps back to the corresponding action in the original request via action_index (zero-based position in publish_actions). Check action_status and error_details on any FAILED entry to understand what went wrong.

Typical job completion time is a few seconds; use exponential backoff when polling.
Environment Monitoring
POST
Get Environment Pairs

Returns a paginated list of monitored environment pairs, each representing directional traffic between a source and destination environment. Includes per-pair flow stats and the current protection status.

Use the pair_id from results as the {pair-id} path parameter for POST /monitoring/environment-pairs/{pair-id}/publish-config and GET /monitoring/environment-pairs/{pair-id}/publish-config/{job-id}.

Use the source_environment.id and destination_environment.id as inputs to POST /monitoring/environments/pair-details to drill into flow trend details for a specific pair.

Filter tips:

  • protection_statuses: [ENVIRONMENT_UNPROTECTED] - find pairs with no dedicated security policy
  • src_env_ids / dst_env_ids - focus on a specific environment's outbound or inbound pairs
  • env_ids - include any pair where the environment appears as either source or destination

If time_selection is omitted, defaults to the last 1 hour.
POST
List Environment Monitoring Results

Retrieve the flow trend data points and group membership details for a specific environment pair.

Provides the time-series flow breakdown (category default rule hits, protection rule hits, total flows) plus the NSX groups associated with each environment.

The source_environment_id and destination_environment_id come from the source_environment.id and destination_environment.id fields in POST /monitoring/environments/pair-summary results.

The time granularity is automatically determined:

  • 1 hour or less: 5-minute granularity
  • More than 1 hour, up to 24 hours: 1-hour granularity
  • More than 24 hours: 1-day granularity

If time_selection is omitted, defaults to the last 1 hour.
GET
Get All Environment Category Default Rules

Get the list of environment category default rules created by SSP.

These are the global DFW rules in the Environment category that apply to all environment pairs.
POST
Publish Environment Pair Config

Initiate an asynchronous DFW policy publish job for a specific environment pair.

The {pair-id} is the underscore-separated concatenation of source and destination environment UUIDs (e.g. src-env-uuid_dst-env-uuid). Obtain it from the pair_id field in POST /monitoring/environments/pair-summary results.

Supported action types:

  • POLICY_WITH_PROTECTION_RULE_CREATE: Create a new DFW security policy with an embedded protection rule scoped to the source and destination environment groups.
  • PROTECTION_RULE_UPDATE: Update the action of an existing protection rule in an environment policy.

Polling for completion: The 202 response includes a job_id. Poll GET /monitoring/environment-pairs/{pair-id}/publish-config/{job-id} until status is COMPLETED or FAILED. The status_url in the response points directly to that endpoint.

Side effects: POLICY_WITH_PROTECTION_RULE_CREATE writes a new DFW security policy to NSX Manager and triggers NSX realization. Do not call this endpoint in a polling loop.

Returns 409 Conflict if a publish job for this environment pair is already in progress.
GET
Get Environment Pair Publish Config Job Status

Retrieve the status and per-action results of an asynchronous publish job for an environment pair.

Poll this endpoint after calling POST /monitoring/environment-pairs/{pair-id}/publish-config until status is COMPLETED or FAILED. The job_id comes from the id field in the POST /monitoring/environment-pairs/{pair-id}/publish-config 202 response.

Each entry in results maps back to the corresponding action in the original request via action_index (zero-based position in publish_actions). Check action_status and error_details on any FAILED entry to understand what went wrong.

Typical job completion time is a few seconds; use exponential backoff when polling.
Infrastructure Monitoring
GET
List Infra Service Categories

Returns a paginated list of all infrastructure service categories defined in the system. Each category groups one or more related port/protocol services (e.g., the DNS category contains UDP/53 and TCP/53 services).

How to use this endpoint:

  • The id of each returned category is the service-category-id required by every other endpoint under /monitoring/infra/service-categories/{service-category-id}.
  • Use this endpoint to discover valid service-category-id values before calling /summary, /details, /discovered-servers, or /publish-config.
  • For a richer view that includes monitoring stats (new servers, rules status), use POST /intelligence/monitoring/infra/service-categories/summary instead.
POST
Get Infra Service Categories Summary

Returns a comprehensive dashboard-level view of all infrastructure service categories with monitoring data for the specified time interval. This is the primary entry point for understanding infrastructure security posture at a glance.

Each result includes:

  • detected_new_servers - workloads newly seen talking to this category, not yet in a group.
  • rules_status - whether all expected DFW/IDS rules are published (ALL_RULES_PUBLISHED, SOME_MISSING_RULES, or NO_RULES).
  • leaked_assets_workload_count - workloads with uncovered infrastructure flows.

Chain:

  • Use service-category-id values from the results array to drill into GET /intelligence/monitoring/infra/service-categories/{service-category-id} for full config, POST /intelligence/monitoring/infra/service-categories/{service-category-id}/details for flow statistics, or POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config to apply rules.
  • Use infra_policy_path from the response as input to DFW rule proposals.

Notes:

  • When time_selection is omitted, the time window defaults to the last 30 days.
  • leaked_assets_workload_count is null when no rules are published for a category - a null value does not mean zero leaks.
GET
Get Infra Service Category

Returns the complete configuration for a single infrastructure service category, including its associated NSX groups, rule counts, port/protocol aggregations, and the status of the last publish job.

Useful for checking:

  • num_traffic_rules, num_lockdown_rules, num_ids_rules - current published rule coverage.
  • last_publish_job_status - whether the most recent publish succeeded or failed.
  • infra_groups - the NSX security groups linked to this category.

Chain:

  • Obtain service-category-id from GET /intelligence/monitoring/infra/service-categories or POST /intelligence/monitoring/infra/service-categories/summary.
  • Use GET /intelligence/monitoring/infra/service-categories/{service-category-id}/services to see the individual port/protocol entries that make up this category.

Notes:
GET
List Infra Services

Returns a paginated list of the individual services (port/protocol entries) that belong to the specified infrastructure service category. Each service represents one specific port/protocol combination (e.g., DNS UDP/53, DNS TCP/53).

Chain:

  • The id of each returned service is the service-id required by GET /intelligence/monitoring/infra/service-categories/{service-category-id}/services/{service-id}.
  • Check is_broadcast_service, is_lockdown_allowed, and is_ids_allowed on each service before calling POST /intelligence/monitoring/infra/service-categories/{service-category-id}/proposed-rules, POST /intelligence/monitoring/infra/service-categories/{service-category-id}/ids-proposed-rules, or POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config. Broadcast services do not support discovered servers, group publish, or lockdown rules.

Notes:
GET
Get Infra Service

Returns detailed configuration for a single infrastructure service, including its port/protocol definition, monitoring state, and flags that control which publish actions are valid.

Key flags to check before publishing:

  • is_lockdown_allowed: false - lockdown rule proposals are not supported; omit lockdown_rule_request: true from POST /intelligence/monitoring/infra/service-categories/{service-category-id}/proposed-rules.
  • is_ids_allowed: false - IDS rule proposals are not supported for this service.
  • is_broadcast_service: true - discovered servers, group publish, and lockdown rules are all not applicable for this service.
  • is_monitoring_enabled: false - this service is not being actively monitored for new traffic flows; the discovered-servers list will not be updated.

Chain:

  • Obtain service-id from GET /intelligence/monitoring/infra/service-categories/{service-category-id}/services.

Notes:
POST
Get Discovered Servers For Infra Service Category

Returns a paginated list of workload servers (VMs or IP endpoints) that have been observed communicating with the specified infrastructure service category during the requested time window.

Default behavior:

  • Only returns servers not yet in a published infrastructure group (i.e., newly discovered, ungrouped servers). Set include_all_servers: true to also return servers already in a published group.
  • Servers manually excluded via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/exclusions are suppressed from results unless include_all_servers: true is set.

Chain:

  • The server_id values returned here are used as input to POST /intelligence/monitoring/infra/service-categories/{service-category-id}/exclusions to suppress individual servers from future discovery results.
  • To add servers to an NSX group, pass their server_id values in add_new_members when calling POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config with action type GROUP_PUBLISH.

Notes:

  • When time_selection is omitted, the time window defaults to the last 30 days.
GET
Get Server Exclusions For Infra Service Category

Returns a paginated list of servers that have been excluded from discovery results for the specified infrastructure service category. Excluded servers are hidden from POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers by default.

Chain:

  • Use the server_id values from this response as input to POST /intelligence/monitoring/infra/service-categories/{service-category-id}/remove-exclusions to restore servers back into the discovery list.
  • Servers appear here only after being excluded via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/exclusions.

Notes:

  • site_id is required - exclusions are scoped per site.
  • Returns an empty list (not a 404) if no exclusions exist.
POST
Exclude Servers For Infra Service Category

Adds one or more servers to the exclusion list for the specified infrastructure service category, preventing them from appearing in POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers results.

Side effects:

  • Excluded servers are immediately hidden from future POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers calls (unless the caller sets include_all_servers: true).
  • This operation does not affect existing NSX group membership - servers already in a published group remain there.
  • Exclusions are site-scoped and persist until explicitly removed via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/remove-exclusions.

Inputs:

  • Use server_id values from POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers in server_id_filters.
  • To exclude all currently discovered servers for a site at once, set exclude_all: true with no filter fields.

Chain:

  • To undo this operation, call POST /intelligence/monitoring/infra/service-categories/{service-category-id}/remove-exclusions with the same server IDs. Use GET /intelligence/monitoring/infra/service-categories/{service-category-id}/exclusions to retrieve the list of currently excluded server IDs.
POST
Remove Excluded Servers For Infra Service Category

Removes one or more servers from the exclusion list for the specified infrastructure service category, making them visible again in POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers results.

Side effects:

  • Restored servers will reappear in future POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers calls once removed from the exclusion list.
  • This operation does not modify NSX group membership - it only affects the discovery view.

Inputs:

  • Get the excluded_server_ids to remove by first calling GET /intelligence/monitoring/infra/service-categories/{service-category-id}/exclusions.
  • To clear all exclusions for a site at once, set remove_all: true. When remove_all: true, the excluded_server_ids field is ignored.

Notes:

  • Returns 204 on success with no response body.
POST
Get Infra Service Category Details

Returns comprehensive information for the specified infrastructure service category, including per-service security policy paths, flow counts, and leaked workload statistics. Use this endpoint to understand the current protection state of a category before deciding which rules to create or update.

Key response fields:

  • detected_new_servers - count of ungrouped servers newly seen in the time window. Non-zero values indicate workloads that may need to be added to a published group.
  • all_unique_flows - total unique flows for this category; use to assess overall traffic volume.
  • flows_for_leaked_workloads - flows where the workload side is uncovered by published infrastructure rules. A null value means no rules are published yet, not zero leaks.

Chain:

  • Use POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers to see which specific servers are ungrouped.
  • Use POST /intelligence/monitoring/infra/service-categories/{service-category-id}/proposed-rules or POST /intelligence/monitoring/infra/service-categories/{service-category-id}/ids-proposed-rules to preview rules before applying them via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config.

Notes:

  • When time_selection is omitted, defaults to the last 30 days.
POST
Get Ids Proposed Rules For Service Category

Generates a preview of IDS rules that can be applied to the specified infrastructure service category, grouped by hierarchy. This is a synchronous, read-only operation - it does not create or modify any NSX rules.

When to use:

  • Call this before POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config with action type HIERARCHY_IDS_RULE_CREATE or HIERARCHY_IDS_RULE_UPDATE to review what rules will be created.
  • Only meaningful when is_ids_allowed: true for the services in this category. Check GET /intelligence/monitoring/infra/service-categories/{service-category-id}/services first.

Chain:

  • The ids_policy_path in the response identifies the target IDS policy where rules will be created. Pass this path in IdsRuleUpdateConfig.rule_policy_path when updating existing IDS rules via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config.
  • To apply the proposed rules, use POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config with action type HIERARCHY_IDS_RULE_CREATE.

Notes:

  • Rules are proposed based on the category configuration, not on observed traffic flows.
POST
Get Proposed Infrastructure Rules For Service Category

Generates a preview of DFW (Distributed Firewall) traffic and lockdown rules for the specified infrastructure service category. This is a synchronous, read-only operation - it does not create or modify any NSX rules.

Key behaviors:

  • Rules are configuration-based, not flow-based - they are derived from the category and service definitions, not from observed traffic.
  • Lockdown rules are only proposed for services where is_lockdown_allowed: true. Check GET /intelligence/monitoring/infra/service-categories/{service-category-id}/services to confirm per-service support.

Chain:

  • The dfw_policy_path in the response is the NSX policy path where rules will be created. Pass this in RuleUpdateConfig.rule_policy_path when updating existing rules via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config.
  • To apply the proposed rules, use POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config with action type HIERARCHY_RULE_CREATE (for new rules) or RULE_PUBLISH (for global-scope rules).

Notes:

  • When hierarchy_requests is omitted or empty, the API defaults to proposing traffic rules for the global scope (traffic: true). To suppress traffic rules explicitly, include {"hierarchy": [], "traffic": false} in hierarchy_requests.
  • If the infrastructure global group has not been realized in NSX yet, the API returns 400. In this case, complete the global group publishing operation first via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config with action type GROUP_PUBLISH, then retry.
POST
Publish Infra Service Category

Initiates an asynchronous job to create, update, or delete NSX security rules and/or group memberships for the specified infrastructure service category.

Side effects:

  • This operation directly modifies NSX - security policies, rules, and groups are created or updated on the data plane as soon as the job completes. Do not call this endpoint in a loop or without first reviewing proposed rules via POST /intelligence/monitoring/infra/service-categories/{service-category-id}/proposed-rules or POST /intelligence/monitoring/infra/service-categories/{service-category-id}/ids-proposed-rules.

Polling:

  • Returns an AsyncApiResponse with a job_id (id field). Use this job_id to poll GET /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config/{job-id} until status is COMPLETED or FAILED.

Supported action types and when to use them:

  • GROUP_PUBLISH / HIERARCHY_GROUP_PUBLISH - Add discovered servers to an NSX group. Provide server_id values from POST /intelligence/monitoring/infra/service-categories/{service-category-id}/discovered-servers in add_new_members.
  • RULE_PUBLISH / HIERARCHY_RULE_CREATE - Create new DFW traffic or lockdown rules. Use dfw_policy_path from POST /intelligence/monitoring/infra/service-categories/{service-category-id}/proposed-rules to target the correct policy.
  • RULE_UPDATE / HIERARCHY_RULE_UPDATE - Modify an existing rule's action, disable, or delete it. Requires the revision of the current rule for optimistic concurrency control.
  • HIERARCHY_IDS_RULE_CREATE / HIERARCHY_IDS_RULE_UPDATE - Create or modify IDS rules. Only valid when is_ids_allowed: true for the services in this category.

Multi-action requests:

  • The publish_actions array accepts mixed action types in a single request (e.g., group publish + rule create). Actions are processed in order; if one fails, the remaining actions still run. Check InfraPublishActionResult.action_index to correlate each result back to its position in the request array.

Notes:

  • Returns 202 Accepted immediately; the job runs asynchronously.
GET
Get Infra Service Category Publish Job Status

Retrieves the current status and results of an asynchronous publish job previously initiated by POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config.

How to use:

  • Poll this endpoint after POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config until status is COMPLETED or FAILED.
  • The results array is only populated when the job reaches a terminal state (COMPLETED or FAILED). For partial failures, each action's result is reported independently - check action_status and error_details per entry, and use action_index to match each result back to its position in the original publish_actions request array.

Chain:

  • The job_id is the id field returned in the AsyncApiResponse from POST /intelligence/monitoring/infra/service-categories/{service-category-id}/publish-config.

Notes:
POST
Get Infra Assets Security Info Batch

Returns a paginated list of infrastructure asset groups (segmentation objects) and their associated DFW firewall rules and IDS rules, spanning one or more service categories in a single request. Use this endpoint to build a security coverage dashboard without making one request per category.

When to use:

  • Use service_category_ids (from GET /intelligence/monitoring/infra/service-categories) to target multiple categories at once instead of calling per-category detail endpoints individually.
  • Set global_only: true to return only the non-hierarchical (global) group per category, reducing payload size when hierarchical breakdown is not needed.

Response structure:

  • Each record in results represents one infrastructure asset group and includes its linked DFW traffic/lockdown rules and IDS rules.
  • infra_section_paths lists all infrastructure security policy paths relevant to the queried categories - useful for navigating directly to policies in NSX.

Notes:

  • When service_category_ids is omitted, behavior depends on the caller context. Provide explicit IDs for predictable, scoped results.
  • Invalid or unrecognized IDs in service_category_ids are silently ignored; only matching categories are returned.
  • Returns 500 if none of the specified category IDs exist (e.g., all IDs are invalid).
Security Explorer
POST
Get App Flow Details

Returns a paginated list of unique (deduplicated) flow records for the specified application. Flows are deduplicated by source VM, destination VM, destination port, and protocol -- multiple occurrences within the time window collapse into a single row reflecting the most recently observed state.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • Set use_latest_apps to true to reflect current application membership; false (default) reflects membership at the time each flow was observed.
  • Use app_request_type to filter flows by request type. Multiple values are OR-combined; omitting the field returns all flows.
  • filters accepts up to 300 filter entries.
  • Obtain app-id from the topology graph returned by POST /visualization/topology/apps-flow-topology, where each node represents an application.
  • To export these results as a CSV file, use POST /visualization/flow-exports/applications/{app-id}/flow-details/export.
  • To see the DFW rules associated with this application, use POST /visualization/security-analysis/applications/{app-id}/related-dfw-rules.
POST
Export App Flow Details

Initiates an asynchronous job to generate a downloadable CSV file containing the same unique (deduplicated) flow records as POST /visualization/flow-analysis/applications/{app-id}/flow-details for the specified application.

Notes:

  • Returns 202 Accepted immediately. The export runs asynchronously -- do not call this endpoint in a loop.
  • Poll GET /visualization/flow-exports/exports/{export-id} using the export_id from the response until status is COMPLETED.
  • Once complete, call GET /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • file_name is required (1-255 characters) and sets the name of the generated CSV file.
  • Set expand_external_traffic to true to expand aggregated external traffic rows into individual rows per source and destination IP. Defaults to false.
  • Obtain app-id from the topology graph returned by POST /visualization/topology/apps-flow-topology or from the inventory API for segmentation object.
POST
Get App Related Rules

Returns DFW rules organized by parent security policies for the specified application. Each result entry is a security policy containing its list of related DFW rules.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • When exact_match is true, only policies whose applied-to scope exactly matches the application (single-element applied-to equal to the application's policy path) are returned.
  • When exact_match is false (default), the system resolves all member computes of the application, finds every group those computes belong to, then returns all rules whose applied-to, source, or destination scope intersects with those groups.
  • filters accepts up to 300 filter entries.
  • Obtain app-id from the topology graph returned by POST /visualization/topology/apps-flow-topology, where each node represents an application.
  • To see flow records for this application, use POST /visualization/flow-analysis/applications/{app-id}/flow-details.
POST
Get Group Related Dfw Rules

Returns DFW rules organized by parent security policies for the specified NSX group. Each result entry is a security policy containing its list of related DFW rules.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • relationship_type: CONTAINS (default) returns rules whose applied-to scope either explicitly references the group or is unset (ANY), and whose source or destination scope either explicitly references the group, is unset (ANY), or contains an IP range that covers the group's member compute IPs. This includes globally-scoped rules that apply to all workloads.
  • relationship_type: EFFECTIVE_MEMBERS returns rules affecting individual VMs within the group rather than the group directly.
  • When both policy-level and rule-level applied-to are set, the policy-level applied-to takes precedence.
  • filters accepts up to 300 filter entries.
  • Obtain group-id from the group topology graph returned by POST /visualization/topology/groups-flow-topology, where each node represents a group.
  • The group-id is the NSX realization UUID of the group, not its policy path or display name.
  • To see flow records for this group, use POST /visualization/flow-analysis/groups/{group-id}/flow-details.
POST
Get Group Related Ids Rules

Returns IDS (Intrusion Detection Service) rules organized by parent IDS security policies for the specified NSX group. Each result entry is an IDS security policy containing its list of associated rules.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • relationship_type: CONTAINS (default) returns IDS rules whose applied-to scope directly references the group.
  • relationship_type: EFFECTIVE_MEMBERS returns IDS rules affecting individual VMs within the group rather than the group directly.
  • filters accepts up to 300 filter entries. Supported filter keys: IDS_RELATED_RULE_RULE_ID, IDS_RELATED_RULE_RULE_NAME.
  • Obtain group-id from the group topology graph returned by POST /visualization/topology/groups-flow-topology, where each node represents a group.
  • The group-id is the NSX realization UUID of the group, not its policy path or display name.
  • To see DFW rules for this group, use POST /visualization/security-analysis/groups/{group-id}/related-dfw-rules.
  • To see flow records for this group, use POST /visualization/flow-analysis/groups/{group-id}/flow-details.
POST
Get Computes Related Rule Counts

Returns aggregate DFW and IDS rule counts for each of the specified computes. Each result entry contains the compute ID along with its DFW rule count and IDS rule count.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • compute_ids accepts up to 20 compute IDs per request.
  • To retrieve the full list of DFW rules for a specific compute, use POST /visualization/security-analysis/computes/{compute-id}/related-dfw-rules.
  • To retrieve the full list of IDS rules for a specific compute, use POST /visualization/threat-analysis/computes/{compute-id}/related-ids-rules.
  • To get equivalent rule counts for groups instead of computes, use POST /visualization/security-analysis/groups/related-rule-counts.
POST
Get Groups Related Rule Counts

Returns aggregate DFW and IDS rule counts for each of the specified groups. Each result entry contains the group ID along with its DFW rule count and IDS rule count.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • Either group_ids or group_paths must be provided, but not both. Each list accepts up to 20 entries.
  • relationship_type: CONTAINS (default) counts rules that directly reference the group in their applied-to, source, or destination scope.
  • relationship_type: EFFECTIVE_MEMBERS counts rules affecting individual VMs within the group rather than the group directly.
  • To retrieve the full list of DFW rules for a specific group, use POST /visualization/security-analysis/groups/{group-id}/related-dfw-rules.
  • To retrieve the full list of IDS rules for a specific group, use POST /visualization/threat-analysis/groups/{group-id}/related-ids-rules.
  • To get equivalent rule counts for computes instead of groups, use POST /visualization/security-analysis/computes/related-rule-counts.
POST
Get Apps Flow Topology

Returns a topology graph where applications are nodes and inter-application communication paths are edges. Each edge represents that at least one flow exists between two applications within the time window, with aggregated unique flow counts attached.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • Application membership is determined by the current compute-to-application mapping at query time, not at the time each flow was observed.
  • Use entity_limit to cap the number of application nodes returned (default 500). VMs and IPs that do not belong to any application are aggregated into a special OTHER_VMS_AND_IPS node.
  • filters accepts up to 300 filter entries.
  • The app-id of each application node can be used with POST /visualization/flow-analysis/applications/{app-id}/flow-details to drill into flow records for that application, or with POST /visualization/security-analysis/applications/{app-id}/related-dfw-rules to see its associated DFW rules.
POST
Get Compute Flow Connections

Returns a paginated list of unique (deduplicated) flow records between a specific pair of compute entities. Flows are deduplicated by the 4-tuple of source VM, destination VM, destination port, and protocol -- multiple occurrences within the time window collapse into a single row reflecting the most recently observed state.

Notes:

  • source_id, destination_id, start_time, src_site_id, and dst_site_id are all required.
  • source_id and destination_id are the VM external IDs of the source and destination computes. Obtain them from the nodes returned by POST /visualization/topology/compute-flow-topology.
  • The VM external ID is the vCenter-assigned identifier for the compute, visible as the id field on each compute node in topology responses.
  • src_site_id and dst_site_id scope the query to a specific source and destination site. For intra-site flows, set both to the same site ID.
  • Set bidirectional to true to include flows in both directions between the two computes. Defaults to false (source -> destination only).
  • source_parent_id and destination_parent_id optionally scope results to flows where the compute belongs to a specific parent group.
  • filters accepts up to 300 filter entries.
  • To check whether any flows exist between two computes before fetching full details, use the lightweight POST /visualization/flow-analysis/compute-connections/flow-type endpoint first.
POST
Get Compute Flow Connections Flow Type

A lightweight endpoint that returns two boolean flags indicating whether any traffic exists between two compute entities: exists_active_flows (currently open sessions) and exists_completed_flows (sessions that ended within the time window).

Notes:

  • start_time, src_site_id, dst_site_id, source_id, and destination_id are all required.
  • source_id and destination_id are the VM external IDs. Obtain them from the nodes returned by POST /visualization/topology/compute-flow-topology.
  • src_site_id and dst_site_id scope the query to the source and destination sites. For intra-site flows, set both to the same site ID.
  • Set bidirectional to true to check for flows in both directions. Defaults to false (source -> destination only).
  • Use this endpoint before calling POST /visualization/flow-analysis/compute-connections to avoid fetching full flow details when no flows exist.
POST
Get Computes Flow Topology

Returns a topology graph where computes (VMs and IPs) are nodes and flow connections are edges. Each edge represents that at least one flow exists between two computes within the time window, with aggregated unique flow counts attached.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • filters accepts up to 300 filter entries.
  • Use the id of any compute node in the response with POST /visualization/flow-analysis/computes/{compute-id}/flow-details to drill into flow records for that VM.
  • To see flows between two specific computes, use POST /visualization/flow-analysis/compute-connections. To first check whether any flows exist between them, use the lightweight POST /visualization/flow-analysis/compute-connections/flow-type.
POST
Query Compute Flow Details

Returns a paginated list of unique (deduplicated) compute-level flow records matching the supplied filters. Flows are deduplicated by the 4-tuple of source VM, destination VM, destination port, and protocol -- multiple occurrences within the time window collapse into a single row reflecting the most recently observed state.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • filters accepts up to 300 filter entries.
  • This endpoint queries across all computes. To retrieve flows for a specific VM, use POST /visualization/flow-analysis/computes/{compute-id}/flow-details.
POST
Get Compute Flow Details

Returns a paginated list of unique (deduplicated) flow records incoming to or outgoing from the specified VM. Flows are deduplicated by source VM, destination VM, destination port, and protocol -- multiple occurrences within the time window collapse into a single row reflecting the most recently observed state.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • parent_id optionally scopes the result to flows where the VM belongs to a specific parent group.
  • pinned_parent_id optionally scopes results to the pinned group view.
  • filters accepts up to 300 filter entries.
  • Obtain compute-id from the topology graph returned by POST /visualization/topology/compute-flow-topology, where each node represents a compute.
  • To export these results as a CSV file, use POST /visualization/flow-exports/computes/{compute-id}/flow-details/export.
  • To see the DFW rules associated with this VM, use POST /visualization/security-analysis/computes/{compute-id}/related-dfw-rules.
  • To see the IDS rules associated with this VM, use POST /visualization/threat-analysis/computes/{compute-id}/related-ids-rules.
POST
Export Compute Flow Details

Initiates an asynchronous job to generate a downloadable CSV file containing the same unique (deduplicated) flow records as POST /visualization/flow-analysis/computes/{compute-id}/flow-details for the specified VM.

Notes:

  • Returns 202 Accepted immediately. The export runs asynchronously -- do not call this endpoint in a loop.
  • Poll GET /visualization/flow-exports/exports/{export-id} using the export_id from the response until status is COMPLETED.
  • Once complete, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • file_name is required (1-255 characters) and sets the name of the generated CSV file.
  • Set expand_external_traffic to true to expand aggregated external traffic rows into individual rows per source and destination IP. Defaults to false.
  • Obtain compute-id from the topology graph returned by POST /visualization/topology/compute-flow-topology, where each node represents a compute.
POST
Get Compute Related Ids Rules

Returns IDS (Intrusion Detection Service) rules organized by parent IDS security policies for the specified VM. Each result entry is an IDS security policy containing its list of associated rules.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • filters accepts up to 300 filter entries. Supported filter keys: IDS_RELATED_RULE_RULE_ID, IDS_RELATED_RULE_RULE_NAME.
  • Obtain compute-id from the topology graph returned by POST /visualization/topology/compute-flow-topology, where each node represents a compute.
  • To see the DFW rules associated with this VM, use POST /visualization/security-analysis/computes/{compute-id}/related-dfw-rules.
  • To see the flow records for this VM, use POST /visualization/flow-analysis/computes/{compute-id}/flow-details.
POST
Get Compute Related Rules

Returns Distributed Firewall (DFW) rules organized by parent security policies for the specified VM. Each result entry is a security policy containing its list of related DFW rules.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • The system resolves all groups the VM belongs to, then returns all rules whose applied-to, source, or destination scope intersects with those groups, filtered by rule direction so that the VM appears on the expected side (source for outbound rules, destination for inbound rules).
  • filters accepts up to 300 filter entries.
  • Obtain compute-id from the topology graph returned by POST /visualization/topology/compute-flow-topology, where each node represents a compute.
  • To see the IDS rules associated with this VM, use POST /visualization/threat-analysis/computes/{compute-id}/related-ids-rules.
  • To see the flow records for this VM, use POST /visualization/flow-analysis/computes/{compute-id}/flow-details.
POST
Get Compute Related Info

Returns a paginated list of context data discovered on the specified VM. The info_type field determines what is returned: PROCESS returns processes observed making flows on the VM; USER_LOGIN_INFO returns user login sessions detected on the VM.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • info_type is required. Accepted values: PROCESS, USER_LOGIN_INFO.
  • filters accepts up to 300 filter entries. Supported filter keys for PROCESS: PROCESS_NAME, PROCESS_COMMAND_LINE, PROCESS_USER_NAME, PROCESS_HASH.
  • Obtain compute-id from the topology graph returned by POST /visualization/topology/compute-flow-topology, where each node represents a compute.
  • To see the flow records for this VM, use POST /visualization/flow-analysis/computes/{compute-id}/flow-details.
POST
Get Environment Pair Flow Details

Returns a paginated list of unique (deduplicated) flow records between two environment entities. Flows are deduplicated by the 4-tuple of source VM, destination VM, destination port, and protocol -- multiple occurrences collapse into a single row reflecting the most recently observed state.

Notes:

  • start_time, src_site_id, dst_site_id, src_env_id, and dst_env_id are all required.
  • src_site_id and dst_site_id scope the query to the source and destination sites. For intra-site flows, set both to the same site ID.
  • env_request_type filters flows by direction type.
  • filters accepts up to 300 filter entries.
  • To export these results as a CSV file, use POST /visualization/flow-exports/environments/pair-flow-details/export.
POST
Export Environment Pair Flow Details

Initiates an asynchronous job to generate a downloadable CSV file containing the same unique (deduplicated) flow records as POST /visualization/flow-analysis/environments/pair-flow-details for a pair of environments.

Notes:

  • Returns 202 Accepted immediately. The export runs asynchronously -- do not call this endpoint in a loop.
  • Poll GET /visualization/flow-exports/exports/{export-id} using the export_id from the response until status is COMPLETED.
  • Once complete, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • file_name is required (1-255 characters) and sets the name of the generated CSV file.
  • Set expand_external_traffic to true to expand aggregated external traffic rows into individual rows per source and destination IP. Defaults to false.
POST
Query Flow Export Jobs

Returns a paginated list of all flow export jobs across all entity types, with their current status and metadata.

Notes:

  • Each result entry contains the job ID, status, creation time, entity type, and file name.
  • filters accepts up to 300 filter entries.
  • Use the export_id from the results with GET /visualization/flow-exports/exports/{export-id} to fetch a specific job's details.
  • Once a job reaches COMPLETED status, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
GET
Get Flow Export Job

Returns the full metadata and current status of a single export job identified by export-id.

Notes:

  • Poll this endpoint after calling one of the export-creation endpoints.
  • When status is COMPLETED, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • To cancel a running job, call PUT /visualization/flow-exports/exports/{export-id} with status set to PENDING_CANCEL.
DELETE
Delete Flow Export Job

Marks the specified export job as deleted. The job will no longer appear in the listing returned by POST /visualization/flow-exports/exports.

Notes:

  • Only the enterprise_admin and security_engineer roles can delete export jobs.
PUT
Update Flow Export Job

Updates the specified export job. Currently supports updating the status field only.

Notes:

  • Set status to PENDING_CANCEL to request cancellation of a running job.
  • Only the enterprise_admin and security_engineer roles can update export jobs.
POST
Get Group Flow Connections

Returns a paginated list of flow records between a specific pair of groups. Flows are first deduplicated by the 4-tuple of source VM, destination VM, destination port, and protocol. Each unique flow is then expanded across the cross-product of source and destination group memberships -- only rows where the source group matches source_id and the destination group matches destination_id are returned.

Notes:

  • start_time, src_site_id, dst_site_id, source_id, and destination_id are all required.
  • source_id and destination_id are the NSX group realization UUIDs. Obtain them from POST /visualization/topology/groups-flow-topology.
  • src_site_id and dst_site_id scope the query to the source and destination sites. For intra-site flows, set both to the same site ID.
  • Set bidirectional to true to include flows in both directions. Defaults to false (source -> destination only).
  • filters accepts up to 300 filter entries.
  • To check whether any flows exist between two groups before fetching full details, use the lightweight POST /visualization/flow-analysis/group-connections/flow-type endpoint first.
POST
Get Group Flow Connections Flow Type

A lightweight endpoint that returns two boolean flags indicating whether any traffic exists between two groups: exists_active_flows (currently open sessions) and exists_completed_flows (sessions that ended within the time window).

Notes:

  • start_time, src_site_id, dst_site_id, source_id, and destination_id are all required.
  • source_id and destination_id are the NSX group realization UUIDs. Obtain them from POST /visualization/topology/groups-flow-topology.
  • src_site_id and dst_site_id scope the query to the source and destination sites. For intra-site flows, set both to the same site ID.
  • Set bidirectional to true to check for flows in both directions. Defaults to false (source -> destination only).
  • Use this endpoint before calling POST /visualization/flow-analysis/group-connections to avoid fetching full flow details when no flows exist.
POST
Get Groups Flow Topology

Returns a topology graph where security groups are nodes and inter-group communication paths are edges. Each edge represents that at least one flow was observed between members of two groups within the requested time window.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • Group membership is determined at flow ingestion time -- the groups each compute belonged to when the flow was recorded, not the current membership.
  • Use entity_limit to cap the number of group nodes returned. When the number of groups exceeds this threshold, low-traffic groups are collapsed into an "Other" node.
  • When an "Other" node is present in the response, call POST /visualization/topology/groups-flow-topology/other-members to list the groups it contains.
  • filters accepts up to 300 filter entries.
  • The group-id of each node in the response can be used directly with POST /visualization/flow-analysis/groups/{group-id}/flow-details to drill into flow records for that group, or with POST /visualization/security-analysis/groups/{group-id}/related-dfw-rules to see its associated DFW rules.
  • Each group-id value is the NSX realization UUID of the group.
POST
Fetch Groups Topology Other Members

Returns a paginated list of groups that were collapsed into the "Other" node in a prior POST /visualization/topology/groups-flow-topology response. Use this endpoint to reveal the hidden groups when the topology exceeds the entity_limit threshold.

Notes:

  • topology_token is required. Obtain it from the POST /visualization/topology/groups-flow-topology response that produced the "Other" node.
  • topology_token expires after 1 hour. Only the 10 most recent topology results are stored; an expired or unknown token returns an error.
  • Set connected_group_id to filter results to only "Other" groups that communicate with a specific visible group.
  • start_time is required. Either site_id or site_ids must also be provided.
  • filters accepts up to 300 filter entries.
  • Use the group-id of any returned group to drill into POST /visualization/flow-analysis/groups/{group-id}/flow-details or POST /visualization/security-analysis/groups/{group-id}/related-dfw-rules.
  • Each group-id is the NSX realization UUID of the group.
POST
Get Pinned Group Flow Topology

Returns a topology graph centered on the specified group ("pinned" group), showing every other group it communicates with and the flow connections between them.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • The pinned group is marked with pinned: true in the response nodes.
  • Use entity_limit to cap the number of neighbor group nodes returned.
  • filters accepts up to 300 filter entries.
  • Obtain group-id from the nodes returned by POST /visualization/topology/groups-flow-topology.
  • The group-id is the NSX realization UUID of the group.
  • Use any group-id from the response nodes to call this endpoint recursively and explore neighboring group neighborhoods.
  • To see flow records for the pinned group, use POST /visualization/flow-analysis/groups/{group-id}/flow-details. To see its associated DFW rules, use POST /visualization/security-analysis/groups/{group-id}/related-dfw-rules.
POST
Get Group Flow Details

Returns a paginated list of flow records where at least one endpoint belongs to the specified group. Flows are first deduplicated by the 4-tuple of source VM, destination VM, destination port, and protocol. Each unique flow is then expanded across group memberships -- all rows where the specified group appears as either source or destination are returned.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • parent_id optionally scopes the result to flows where the group belongs to a specific parent group context.
  • pinned_parent_id optionally scopes results to the pinned group view.
  • filters accepts up to 300 filter entries.
  • Obtain group-id from the topology graph returned by POST /visualization/topology/groups-flow-topology, where each node represents a group.
  • To export these results as a CSV file (one row per unique flow, without group expansion), use POST /visualization/flow-exports/groups/{group-id}/flow-details/export.
  • To see the DFW rules associated with this group, use POST /visualization/security-analysis/groups/{group-id}/related-dfw-rules.
  • Example: VM1 belongs to groups G1 and G2; VM2 belongs to groups G2 and G3. A single flow VM1->VM2 on port 443/TCP produces four rows from the cross-product: (G1->G2), (G1->G3), (G2->G2), (G2->G3). Querying for group G2 returns three rows -- (G2->G2), (G2->G3), and (G1->G2) -- because G2 appears as source or destination in each.
POST
Export Group Flow Details

Initiates an asynchronous job to generate a downloadable CSV file containing unique (deduplicated) flow records for the specified group. Unlike POST /visualization/flow-analysis/groups/{group-id}/flow-details, the export produces one row per unique flow without expanding across group memberships.

Notes:

  • Returns 202 Accepted immediately. The export runs asynchronously -- do not call this endpoint in a loop.
  • Poll GET /visualization/flow-exports/exports/{export-id} using the export_id from the response until status is COMPLETED.
  • Once complete, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • file_name is required (1-255 characters) and sets the name of the generated CSV file.
  • group-id is the NSX group realization UUID. Obtain valid IDs from POST /visualization/topology/groups-flow-topology.
  • Set expand_external_traffic to true to expand aggregated external traffic rows into individual rows per source and destination IP. Defaults to false.
POST
Query Workloads Affected

Returns a paginated list of computes (VMs) on which the specified IDS signature was detected within the given time window.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • signature_id is required and identifies the IDS signature to query.
  • filters accepts up to 300 filter entries.
  • To see which IDS signatures were detected on a specific VM, use POST /visualization/threat-analysis/{compute-id}/related-signatures.
  • To see the full event timeline for a signature, use POST /visualization/threat-analysis/{signature-id}/events-history.
POST
Get Compute Related Ids Signatures

Returns a list of unique IDS signatures that were triggered on the specified VM within the given time window. Each entry identifies a unique signature with its metadata.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • compute-id is the VM external ID. Obtain valid IDs from POST /visualization/topology/compute-flow-topology.
  • filters accepts up to 300 filter entries.
  • To see which VMs were affected by a specific signature, use POST /visualization/threat-analysis/workloads-affected.
  • To see the full event timeline for a specific signature, use POST /visualization/threat-analysis/{signature-id}/events-history.
POST
Get Ids Signature Events History

Returns a chronological timeline of intrusion detection events matching the specified IDS signature within the given time window. Each event entry includes timestamp and affected compute information. The response also includes the signature metadata (name, severity, category).

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • signature-id is the IDS signature ID. Obtain valid IDs from POST /visualization/threat-analysis/{compute-id}/related-signatures.
  • A maximum of 5000 results are returned.
  • filters accepts up to 300 filter entries.
  • To see all VMs affected by this signature, use POST /visualization/threat-analysis/workloads-affected.
POST
Get Infra Monitoring Flow Details

Returns a paginated list of unique (deduplicated) flow records associated with a specific infrastructure service (e.g., DNS, NTP, Active Directory). Flows are deduplicated by the 4-tuple of source VM, destination VM, destination port, and protocol.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • service_category_id is required. Obtain valid IDs from the /monitoring/infrastructure/service-categories API.
  • server_ids optionally narrows results to specific discovered servers (up to 300 entries). Omitting this field returns all flows for the service.
  • filters accepts up to 300 filter entries.
  • To export these results as a CSV file, use POST /visualization/flow-exports/infrastructure/monitoring/flow-details/export.
POST
Get Infra Monitoring Leaked Flow Details

Returns a paginated list of unique (deduplicated) flow records for workloads that interact with a specific infrastructure service but are not protected by any published infra rule. These are "leaked" flows -- traffic involving an infra service server that falls outside the coverage of existing infra monitoring rules.

Notes:

  • start_time is required. Either site_id or site_ids must also be provided.
  • service_category_id is required. Obtain valid IDs from the /monitoring/infrastructure/service-categories API.
  • workload_ids scopes results to specific workload VMs (up to 300 entries). A workload is the VM on the opposite side of the flow from the infra service server. If omitted, all uncovered flows from the workload side are returned.
  • filters accepts up to 300 filter entries.
  • To export these results as a CSV file, use POST /visualization/flow-analysis/infrastructure/monitoring/leaked-flow-details/export.
POST
Export Infra Monitoring Leaked Flow Details

Initiates an asynchronous job to generate a downloadable CSV file containing the same unique (deduplicated) flow records as POST /visualization/flow-analysis/infrastructure/monitoring/leaked-flow-details for an infrastructure service.

Notes:

  • Returns 202 Accepted immediately. The export runs asynchronously -- do not call this endpoint in a loop.
  • Poll GET /visualization/flow-exports/exports/{export-id} using the export_id from the response until status is COMPLETED.
  • Once complete, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • file_name is required (1-255 characters) and sets the name of the generated CSV file.
POST
Export Infra Monitoring Flow Details

Initiates an asynchronous job to generate a downloadable CSV file containing the same unique (deduplicated) flow records as POST /visualization/flow-analysis/infrastructure/monitoring/flow-details for an infrastructure service.

Notes:

  • Returns 202 Accepted immediately. The export runs asynchronously -- do not call this endpoint in a loop.
  • Poll GET /visualization/flow-exports/exports/{export-id} using the export_id from the response until status is COMPLETED.
  • Once complete, call POST /visualization/flow-exports/exports/{export-id}/get-download-key to obtain the download URL.
  • file_name is required (1-255 characters) and sets the name of the generated CSV file.
POST
Get Export Job Download Key

Returns a time-limited download URL for the CSV file produced by a completed export job. Notes:

  • Only call this endpoint after confirming that GET /visualization/flow-exports/exports/{export-id} returns status: COMPLETED.
  • The download URL expires after 60 minutes. Call this endpoint again to obtain a fresh URL.