Claroty xDome | D3 Docs

LAST UPDATED: AUG 31, 2026

Overview

Claroty xDome is an industrial cybersecurity platform that provides comprehensive visibility, threat detection, and vulnerability management for OT, IoT, and IIoT environments. It continuously monitors network assets, detects anomalies and threats, and delivers risk-based vulnerability prioritization across industrial and healthcare networks.

Claroty xDome is available for use in:

D3 ASOC	V18.0.7+
Category	Network Security
Deployment Options	Option I, Option II, Option III, Option IV

Connection

Gather the following information to connect D3 to Claroty xDome.

Parameter	Description	Example
Server URL	The base URL of the Claroty xDome API instance. The API URL follows the format https://{tenant}-api.claroty.com. This URL is different from the dashboard URL.	https://demo-api.claroty.com
API Token	The Bearer token used to authenticate API requests. Generate an API token from the Claroty xDome portal under Admin Settings > User Management by creating an API User.	********
API Version	Specifies the Claroty xDome API version. The default version is v1. Supported versions: v1.	v1

Permission Requirements

Each endpoint in the Claroty xDome API requires a certain permission scope. The following are required scopes for the commands in this integration:

Command	Required Permissions
Test Connection	API user with read access to alerts
List Devices	API user with read access to devices
List Alerts	API user with read access to alerts
List Vulnerabilities	API user with read access to vulnerabilities
Fetch Event	API user with read access to alerts
Get Alert Devices	API user with read access to alerts and devices
Resolve Alerts	API user with write access to alerts
Get Device Communication Map	API user with read access to devices
Get Vulnerability Devices	API user with read access to vulnerabilities and devices
List OT Activity Events	API user with read access to OT activity events

Configuring Claroty xDome to Work with D3

Complete the following steps in the vendor environment before configuring the D3 connection:

Log in to the Claroty xDome portal as an administrator.
Navigate to Admin Settings > User Management.
Click + Add User and select API User as the user type.
Enter a username and description for the API user.
Assign the appropriate site permissions and role.
After you create the user, click Generate Token next to the user in the list.
Select a Token Expiration date from the dropdown.
Click Generate and immediately copy the token. The token cannot be viewed again after this step.
The API base URL follows the pattern: https://{tenant}-api.claroty.com where {tenant} is your organization identifier. This is different from the dashboard URL (https://{tenant}.dashboard.claroty.com).

Configuring D3 to Work with Claroty xDome

Log in to D3.
See Adding a Connection for instructions on how to find the integration within D3 and fill out the generic integration connection parameters.
System: This section contains the parameters defined specifically for the integration. These parameters must be configured to create the integration connection.
1. Configure the integration-specific parameters as documented in the Connection parameter table above.
Test the connection.
1. Click on the Test Connection button to verify credentials and connectivity. A success alert displays Passed with a green checkmark. If the connection fails, review the parameters and retry.
2. Click OK to close the alert window.
3. Click + Add to create and add the configured connection.

Commands

Claroty xDome includes the following executable commands for users to set up schedules or create playbook workflows. With the Test Command function, users can execute these commands independently for playbook troubleshooting.

Integration API Note

For more information about the Claroty xDome API, refer to the Claroty xDome API reference provided with the tenant. The specification is also served by the tenant API host configured in the Server URL connection parameter.

READER NOTE
Certain permissions are required for each command. Refer to the Permission Requirements and Configuring Claroty xDome to Work with D3 sections for details.

Note for Time-related parameters

The input format of time-related parameters may vary based on user account settings, which may cause the sample data in commands to differ from what is displayed. To adjust the time format, follow these steps:

Navigate to Configuration > Application Settings. Select Date/Time Format.
Choose the desired date and time format, then click on the Save button.

The selected time format will now be visible when configuring Date/Time command input parameters.

List Devices

Retrieves a list of devices from the Claroty xDome platform, including the device category, type, IP and MAC addresses, manufacturer, model, operating system, hostnames, switch and access point connectivity, risk score, and site.

Input

Input Parameter	Required/Optional	Description	Example
Device Category	Optional	Filters the devices by category. Valid values are OT, IoT, or IT. By default, devices of all categories are returned.	`OT`
Risk Score	Optional	Filters the devices by risk score level. Valid values are Critical, High, Medium, Low, or Very Low. By default, devices of all risk score levels are returned.	`Critical`
Site Name	Optional	Filters the devices by the name of the site within the organization the device is associated with. By default, devices from all sites are returned.	`Houston_Line_1`
Filters	Optional	Additional filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields include: device_category, risk_score, site_name, device_type, ip_list, purdue_level, manufacturer. Any other device field the command returns can also be used. By default, all devices matching the other parameters are returned.	{"field": "ip_list", "operation": "in_subnet", "value": ["10.26.0.0/16"]}
Limit	Optional	The maximum number of devices returned in a single request. By default, the value is 100. When the value is negative, all devices matching the selected filtering conditions from the Offset position onward are returned.	`2`
Offset	Optional	The number of records to skip before returning results. By default, the value is 0. A negative value is treated as 0.	`0`
Fields	Optional	The device fields returned for each device. When specified, this list replaces the default set, except that uid, asset_id, device_type, and ip_list are always included because the key fields are built from them. Use it to narrow the response, or to request a per-tenant field that is not part of the documented schema, such as a custom attribute named custom_attribute_<api name> or a device purpose named device_purpose_<api name>. By default, the full requestable device schema is returned.	["uid", "asset_id", "device_name", "os_version", "end_of_life_state"]

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

The error tab contains the details responded from D3 or third-party API calls, including Failure Indicator, Status Code, and Message. This can help locate the root cause of a command failure.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	List Devices failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
List Devices failed.
Status Code: 400
Message: The Filters parameter must be a JSON object.

List Alerts

Retrieves a list of alerts from the Claroty xDome platform. Filtering by alert category, status, detection time, and other criteria is supported.

Input

Input Parameter	Required/Optional	Description	Example
Alert IDs	Optional	The IDs of the alerts for which to retrieve details. When this parameter is specified, all other filter parameters are ignored. By default, the alerts are not filtered by ID.	["1", "2"]
Start Time	Optional	The start of the alert detection time range, in UTC format (yyyy-MM-dd HH:mm:ss). When the value is empty, the alerts are not filtered by a start time. Ignored when Alert IDs are specified.	2026-04-01 00:00:00
End Time	Optional	The end of the alert detection time range, in UTC format (yyyy-MM-dd HH:mm:ss). When the value is empty, the alerts are not filtered by an end time. Ignored when Alert IDs are specified.	2026-04-08 23:59:59
Category	Optional	Filters the alerts by category. Valid values are Risk, Threat, Custom, Segmentation, Policy Deviation, OT Activity, and Device Changes. By default, alerts of all categories are returned.	["Risk", "Threat"]
Status	Optional	Filters the alerts by resolution status. Valid values are Resolved or Unresolved. By default, alerts of both statuses are returned.	Unresolved
Filters	Optional	Additional filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields include: alert_name, alert_type_name, updated_time, devices_count, unresolved_devices_count. This parameter is ignored when Alert IDs is specified. By default, all alerts matching the other parameters are returned.	{"field": "alert_type_name", "operation": "in", "value": ["Device End-of-Life"]}
Limit	Optional	The maximum number of alerts returned in a single request. By default, the value is 100. When the value is -1, all alerts matching the selected filtering conditions from the Offset position onward are returned.	2
Offset	Optional	The number of records to skip before returning results. By default, the value is 0.	0

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	List Alerts failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
List Alerts failed.
Status Code: 400
Message: The Filters parameter must be a JSON object.

List Vulnerabilities

Retrieves a list of vulnerabilities from the Claroty xDome platform, including CVE IDs, CVSS scores, EPSS scores, affected device counts, and known exploit indicators.

Input

Input Parameter	Required/Optional	Description	Example
Is Known Exploited	Optional	Filters the vulnerabilities by known exploited status. Valid values are True or False. By default, vulnerabilities of both statuses are returned.	True
Vulnerability Type	Optional	Filters the vulnerabilities by type. Valid values are Platform, Application, Clinical, IoT, and OT. By default, vulnerabilities of all types are returned.	`Platform`
Filters	Optional	Additional filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields include: name, vulnerability_type, cve_ids, cvss_v2_score, cvss_v3_score, affected_devices_count, is_known_exploited, published_date, adjusted_vulnerability_score_level, epss_score. By default, all vulnerabilities matching the other parameters are returned.	{"field": "affected_devices_count", "operation": "greater", "value": 0}
Limit	Optional	The maximum number of vulnerabilities returned in a single request. By default, the value is 100. When the value is -1, all vulnerabilities matching the selected filtering conditions from the Offset position onward are returned.	`2`
Offset	Optional	The number of records to skip before returning results. By default, the value is 0.	`0`

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	List Vulnerabilities failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
List Vulnerabilities failed.
Status Code: 400
Message: The Filters parameter must be a JSON object.

Fetch Event

Return Event(s) from the Claroty xDome platform based on specified criteria(s). Ingests alerts as events in descending order of detection time. Ingestion volume is controlled by the Start Time window and the ingestion schedule interval rather than by the Number of Event(s) Fetched value.

Input

Input Parameter	Required/Optional	Description	Example
Start Time	Optional	The start of the time range for fetching events (in UTC). By default, the value is one hour before the End Time.	`2026-08-01 00:00:00`
End Time	Optional	The end of the time range for fetching events (in UTC). By default, the value is the current time.	`2026-08-19 23:59:59`
Number of Event(s) Fetched	Optional	The maximum number of events to return. By default, the value is empty, and all events in the given time range are returned. A positive value caps the run, and because events are returned in descending order of detection time, the oldest events in the range are dropped.	`100`
Category	Optional	Filters the events by category. Valid values are Risk, Threat, Custom, and Segmentation. By default, events of all categories are returned.	`Threat`
Status	Optional	Filters the events by resolution status. Valid values are Resolved or Unresolved. By default, events of both statuses are returned.	`Unresolved`
Search Condition	Optional	Additional filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields include: alert_name, alert_type_name, updated_time, devices_count, unresolved_devices_count.	`{"field": "alert_name", "operation": "in", "value": ["CCTV-Offline"]}`

Fetch Event Field Mapping

Event and Incident Intake Field Mapping

See Field Mappings.

The Claroty xDome integration includes pre-configured field mappings for the default event source. The pre-configured field mappings are detailed below:

Main Event JSON Path: $.alerts

Field Name	Source Field
Start Time	$.detected_time
Unique Event Key	$.id
Event name	$.alert_name
Description	$.description
Alert type	$.alert_type_name
Status	$.status
Event category	$.category
Techniques	$.mitre_technique_enterprise_names
Alert Class	$.alert_class
Devices Count	$.devices_count
Unresolved Devices Count	$.unresolved_devices_count
OT Devices Count	$.ot_devices_count
IoT Devices Count	$.iot_devices_count
IT Devices Count	$.it_devices_count

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	Fetch Event failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
Fetch Event failed.
Status Code: 422
Message: Input should be a valid dictionary or object to extract fields from

Get Alert Devices

Retrieves the list of devices affected by a specified alert, including device UID, IP address, category, type, risk score, and resolution status.

READER NOTE
Alert ID is a required parameter to run this command.
Run the List Alerts command to obtain the Alert ID. Alert IDs can be found in the raw data at $.alerts[*].id.

Input

Input Parameter	Required/Optional	Description	Example
Alert ID	Required	The ID of the alert for which to retrieve affected devices. Alert ID can be obtained using the List Alerts command.	119
Limit	Optional	The maximum number of devices returned in a single request. By default, the value is 100. When the value is -1, all devices affected by the alert from the Offset position onward are returned.	2
Offset	Optional	The number of records to skip before returning results. By default, the value is 0.	0

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	Get Alert Devices failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
Get Alert Devices failed.
Status Code: 400
Message: invalid literal for int() with base 10: 'ABC123'

Resolve Alerts

Marks selected alerts as resolved or unresolved in the Claroty xDome platform. The status change can apply to all affected devices or be scoped to specific devices.

READER NOTE
Alert IDs and Status are required parameters to run this command.
Run the List Alerts command to obtain the Alert IDs. Alert IDs can be found in the raw data at $.alerts[*].id.
Status accepts Resolved or Unresolved.

Input

Input Parameter	Required/Optional	Description	Example
Alert IDs	Required	The IDs of the alerts to resolve or unresolve. Alert IDs can be obtained using the List Alerts command.	["1", "2"]
Status	Required	The resolution status to set for the specified alerts. Valid values are Resolved or Unresolved.	Resolved
Device UIDs	Optional	The device UIDs to which the status change is scoped. Device UIDs can be obtained using the Get Alert Devices command. By default, the status change applies to all devices associated with the specified alerts.	["01e04355-94f2-4c4a-bbb1-f4a307830d5f", "11986eb6-2323-424e-ac65-e412be65fa85"]

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	Resolve Alerts failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
Resolve Alerts failed.
Status Code: 400
Message: API Version must be in the form v<number>, for example v1. The configured value is 1.

Get Device Communication Map

Retrieves the communication map of a device from the Claroty xDome platform, including the peer device, communication type, protocol, port, direction, data volume, and first and last communication times of each connection. The response covers communications from the past 90 days.

READER NOTE
Either Asset ID or Device UID is required to run this command. When both are provided, Asset ID takes precedence and Device UID is ignored.
Run the List Devices command to obtain either identifier.

Input

Input Parameter	Required/Optional	Description	Example
Asset ID	Optional	The asset ID of the device for which the communication map is retrieved. Either Asset ID or Device UID is required. When both are provided, Asset ID takes precedence and Device UID is ignored. Asset ID can be obtained using the List Devices command.	`BBKWHSA`
Device UID	Optional	The unique identifier of the device for which the communication map is retrieved. Either Asset ID or Device UID is required. When both are provided, Asset ID takes precedence and Device UID is ignored. Device UID can be obtained using the List Devices command.	00023e71-72b6-4824-9063-b63785e7d494
Filters	Optional	Filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields are comm_type, protocol, ip_protocol, port, direction, first_comm, last_comm, comm_device_role, comm_side_b_ip, and side_b_asset_id. All other returned fields are not filterable. By default, all communication records for the device are returned.	{"field": "comm_type", "operation": "in", "value": ["Internet"]}

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	Get Device Communication Map failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
Get Device Communication Map failed.
Status Code: 400
Message: Provide either the Asset ID or the Device UID.

Get Vulnerability Devices

Retrieves the devices affected by a vulnerability from the Claroty xDome platform, including the device identifiers, IP and MAC addresses, category, type, manufacturer, model, site, Purdue level, and risk score.

READER NOTE
Vulnerability ID is a required parameter to run this command.
Run the List Vulnerabilities command to obtain the Vulnerability ID. The value is the Claroty xDome vulnerability identifier, not the CVE identifier.

Input

Input Parameter	Required/Optional	Description	Example
Vulnerability ID	Required	The identifier of the vulnerability for which affected devices are retrieved. The value is the Claroty xDome vulnerability identifier, not the CVE identifier. Vulnerability ID can be obtained using the List Vulnerabilities command.	`ANEHUJVR`
Filters	Optional	Filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields include: risk_score, device_category, device_type, site_name, purdue_level, manufacturer. Any other device field the command returns can also be used. By default, all devices affected by the vulnerability are returned.	{"field": "risk_score", "operation": "in", "value": ["Critical"]}
Limit	Optional	The maximum number of affected devices returned in a single request. By default, the value is 500. When the value is -1, all affected devices from the Offset position onward are returned.	`2`
Offset	Optional	The number of records to skip before returning results. By default, the value is 0.	`0`

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	Get Vulnerability Devices failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
Get Vulnerability Devices failed.
Status Code: 400
Message: Vulnerability ID is required.

List OT Activity Events

Retrieves OT activity events from the Claroty xDome platform, including the event type, source and destination device, IP address, port, protocol, and the user who performed the operation. Results are returned in descending order of detection time.

Input

Input Parameter	Required/Optional	Description	Example
Alert IDs	Optional	Returns only the OT activity events associated with the specified alerts, which resolves an ingested alert to the individual operations behind it. Alert IDs can be obtained using the Fetch Event command. By default, events are returned regardless of the alert they are associated with.	["1000039"]
Start Time	Optional	The start of the time range for retrieving OT activity events, in UTC format (yyyy-MM-dd HH:mm:ss). By default, events are not filtered by a start time.	`2026-08-01 00:00:00`
End Time	Optional	The end of the time range for retrieving OT activity events, in UTC format (yyyy-MM-dd HH:mm:ss). By default, events are not filtered by an end time.	`2026-08-20 23:59:59`
Event Types	Optional	Filters the events by operation type. Common values are Configuration Upload, Configuration Download, File System Change, Mode Change, Online Edit, Monitor Mode, Memory Reset, Firmware Download, Settings Change, and DCS Configuration Change. The API does not restrict this field to a fixed list, so a value specific to the environment is also accepted. By default, events of all types are returned.	["Configuration Upload", "Firmware Download"]
Source Asset ID	Optional	Returns only the events originating from the specified device. Source Asset ID can be obtained using the List Devices command. By default, events from all source devices are returned.	`CJLLKRZ`
Destination Asset ID	Optional	Returns only the events targeting the specified device. Destination Asset ID can be obtained using the List Devices command. By default, events to all destination devices are returned.	`GHNEJDG`
Filters	Optional	Additional filter conditions in JSON format using the xDome filter syntax. Simple filter format: {"field": "<field_name>", "operation": "<op>", "value": "<val>"}. Compound filter format: {"operation": "and\|or\|not", "operands": [{"field": "<field_name>", "operation": "<op>", "value": "<val>"}, {"field": "<field_name>", "operation": "<op>", "value": "<val>"}]}. Supported filter fields include: event_id, event_type, detection_time, related_alert_ids, source_asset_id, source_ip, source_username, dest_asset_id, dest_ip, protocol, mode. On detection_time only the greater_or_equal and less_or_equal operations are accepted. By default, all events matching the other parameters are returned.	{"field": "protocol", "operation": "in", "value": ["CIP"]}
Limit	Optional	The maximum number of OT activity events returned in a single request. By default, the value is 500. When the value is -1, all events matching the selected filtering conditions from the Offset position onward are returned.	`2`
Offset	Optional	The number of records to skip before returning results. By default, the value is 0.	`0`

Output

To view the sample output data for all commands, refer to this article.

Error Handling

If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	List OT Activity Events failed.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: Invalid request — missing required parameter.

Error Sample Data
List OT Activity Events failed.
Status Code: 400
Message: The Filters parameter must be a JSON object.

Test Connection

Performs a health check on the integration connection. A periodic health check can be scheduled by selecting Connection Health Check when editing the integration connection.

Input

N/A

Output

Output Type	Description	Return Data Type
Return Data	Indicates one of the possible command execution states: Successful or Failed. The Failed state can be triggered by any of the following errors: A connection issue with the integration The API returned an error message No response from the API More details about an error can be viewed in the Error tab.	String

Error Handling

If the Return Data displays Failed, an Error tab will appear in the Test Result window.

Parts in Error	Description	Example
Failure Indicator	Indicates the command failure that happened at a specific input and/or API call.	Test Connection failed. Failed to check the connector.
Status Code	The response code issued by the third-party API server or the D3 system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Claroty xDome portal. Refer to the HTTP Status Code Registry for details.	Status Code: 403.
Message	The raw data or captured key error message from the integration API server about the API request failure.	Message: You must have a valid support account to call this API.

Error Sample Data
Test Connection failed. Failed to check the connector.
Status Code: 401
Message: The API returned an error. 401 Client Error: Unauthorized