ExtraHop REST API Guide
Introduction to the ExtraHop REST API
The ExtraHop REST API enables you to automate administration and configuration tasks on your ExtraHop system. You can send requests to the ExtraHop API through a Representational State Transfer (REST) interface, which is accessed through resource URIs and standard HTTP methods.
When a REST API request is sent over HTTPS to an ExtraHop system, that request is authenticated and then authorized through an API key. After authentication, the request is submitted to the ExtraHop system and the operation completes.
Each ExtraHop system provides access to the built-in ExtraHop REST API Explorer, which enables you to view all of the available system resources, methods, properties, and parameters. The REST API Explorer also enables you to send API calls directly to your ExtraHop system.
Note: | This guide is intended for an audience that has a basic familiarity with software development and the ExtraHop system. |
ExtraHop API requirements
Before you can begin writing scripts for the ExtraHop REST API or performing operations through the REST API Explorer, you must meet the following requirements:
- Your ExtraHop system must be configured to allow API key generation for the type of user you are (remote or local).
- You must generate a valid API key.
- You must have a user account on the ExtraHop system with appropriate privileges set for the type of tasks you want to perform.
Access and authenticate to the ExtraHop REST API
Administrators, or users with unlimited privileges, control whether users can generate API keys. For example, you can prevent remote users from generating keys or you can disable API key generation entirely. When this functionality is enabled, API keys are generated by users and can be viewed only by the user who generated the key.
Note: | Administrators set up user accounts and assign privileges, but then users generate their own API keys. Users can delete API keys for their own account, and users with unlimited privileges can delete API keys for any user. For more information, see Users and user groups. |
After you generate an API key, you must append the key to your request headers. The following example shows a request that retrieves metadata about the firmware running on the ExtraHop system:
curl -i -X GET --header "Accept: application/json" \ --header "Authorization: ExtraHop apikey=2bc07e55971d4c9a88d0bb4d29ecbb29" \ "https://<hostname-or-IP-of-your-ExtraHop-system>/api/v1/extrahop"
Privilege levels
User privilege levels determine which ExtraHop system and administration tasks the user can perform through the ExtraHop REST API.
You can view the privilege levels for users through the granted_roles and effective_roles properties. The granted_roles property shows you which privilege levels are explicitly granted to the user. The effective_roles property shows you all privilege levels for a user, including those received outside of the granted role, such as through a user group.
The granted_roles and effective_roles properties are returned by the following operations:
- GET /users
- GET /users/{username}
The granted_roles and effective_roles properties support the following privilege levels. Note that the type of tasks for each ExtraHop system vary by the available resources listed in the REST API Explorer.
Privilege level | Actions allowed |
---|---|
"system": "full" |
|
"write": "full" |
|
"write": "limited" |
|
"write": "personal" |
|
"metrics": "full" |
|
"metrics": "restricted" |
|
"packets": "full" |
This is an add-on privilege that can be granted to a user with one of the following privilege levels:
|
"packets": "full_with_keys" |
This is an add-on privilege that can be granted to a user with one of the following privilege levels:
|
"detections": "full" |
This is an add-on privilege that can be granted to a user with one of the following privilege levels:
|
"detections": "none" |
This is an add-on privilege that can be granted to a user with one of the following privilege levels:
|
Manage API key access
Users with unlimited privileges can configure whether users can generate API keys for the ExtraHop system. You can allow only local users to generate keys, or you can also disable API key generation entirely.
- Log in to the Administration settings on the ExtraHop system through https://<extrahop-hostname-or-IP-address>/admin.
- In the Access Settings section, click API Access.
-
In the Manage API Access section, select one of the
following options:
- Allow all users to generate an API key: Local and remote users can generate API keys.
- Only local users can generate an API key: Remote users cannot generate API keys.
- No users can generate an API key: No API keys can be generated by any user.
- Click Save Settings.
Generate an API key
You must generate an API key before you can perform operations through the ExtraHop REST API. Keys can be viewed only by the user who generated the key or by system administrators with unlimited privileges. After you generate an API key, add the key to your request headers or the ExtraHop REST API Explorer.
Before you begin
Make sure the ExtraHop system is configured to allow API key generation.- In the Access Settings section, click API Access.
- In the Generate an API Key section, type a description for the new key, and then click Generate.
- Scroll down to the API Keys section, and copy the API key that matches your description.
Configure cross-origin resource sharing (CORS)
Cross-origin resource sharing (CORS) allows you to access the ExtraHop REST API across domain-boundaries and from specified web pages without requiring the request to travel through a proxy server.
- In the Access Settings section, click API Access.
-
In the CORS Settings section, specify one of the following
access configurations.
- To add a specific URL, type an origin URL in the text box, and then
click the plus (+) icon or press ENTER.
The URL must include a scheme, such as HTTP or HTTPS, and the exact domain name. You cannot append a path; however, you can provide a port number.
- To allow access from any URL, select the Allow API requests
from any Origin checkbox.
Note: Allowing REST API access from any origin is less secure than providing a list of explicit origins.
- To add a specific URL, type an origin URL in the text box, and then
click the plus (+) icon or press ENTER.
- Click Save Settings and then click Done.
Set up an SSL certificate
Before making requests to an ExtraHop system with a self-signed certificate, you must set up an SSL certificate for each user who will access the ExtraHop system from a particular computer.
In each of the following examples, replace {HOST} with the hostname of your ExtraHop system.
Note: | The SSL certificate applies only to the user performing the command. Each user must run the command with their login credentials to set up the SSL certificate. |
Learn about the REST API Explorer
The REST API Explorer is a web-based tool that enables you to view detailed information about the ExtraHop REST API resources, methods, parameters, properties, and error codes. Code samples are available in Python, cURL, and Ruby for each resource. You also can perform operations directly through the tool.
Open the REST API Explorer
You can open the REST API Explorer from the Administration settings or through the following URL:
https://<extrahop-hostname-or-ip-address>/api/v1/explore/
View operation information
From the REST API Explorer, you can click any operation to view configuration information for the resource.
The following table provides information about the sections available for resources in the REST API Explorer. Section availability varies by HTTP method. Not all methods have all of the sections listed in the table.
Section | Description |
---|---|
Body Parameters | Provides all of the fields for the request body and supported values for each field. |
Parameters | Provides information about the available query parameters. |
Responses | Provides information about the possible HTTP status codes for the resource. If you click Send Request, this section also includes the response from the server and the cURL, Python, and Ruby syntax required to send the specified request. |
Identify objects on the ExtraHop system
Objects on the ExtraHop system can be identified by any unique value, such as the IP address, MAC address, name, or system ID. However, to perform API operations on a specific object, you must locate the object ID. You can easily locate the object ID through the following methods in the REST API Explorer.
- The object ID is provided in the headers returned from a POST request. For example, if you
send a POST request to create a page, the response headers display a location URL.
The following request returned the location for the newly created page as /api/v1/pages/221 and the ID for the page as 221.
{ "date": "Wed, 25 Nov 2015 17:39:06 GMT", "via": "1.1 localhost", "server": "Apache", "content-type": "text/plain; charset=utf-8", "location": "/api/v1/pages/221", "cache-control": "private, max-age=0", "connection": "Keep-Alive", "keep-alive": "timeout=45, max=89", "content-length": "0" }
- The object ID is provided for all objects returned from a GET request. For example, if you
perform a GET request on all devices, the response body contains information for
each device, including the ID.
The following response body displays an entry for a single device, with an ID of 10212:
{ "mod_time": 1448474346504, "node_id": null, "id": 10212, "extrahop_id": "test0001", "description": null, "user_mod_time": 1448474253809, "discover_time": 1448474250000, "vlanid": 0, "parent_id": 9352, "macaddr": "00:05:G3:FF:FC:28", "vendor": "Cisco", "is_l3": true, "ipaddr4": "10.10.10.5", "ipaddr6": null, "device_class": "node", "default_name": "Cisco5", "custom_name": null, "cdp_name": "", "dhcp_name": "", "netbios_name": "", "dns_name": "", "custom_type": "", "analysis_level": 1 },
- The object ID is provided in the URL for most objects. For example, in the ExtraHop system,
click on Assets, and then Devices.
Select any device and view the URL. In the following example, the URL for the device
page shows
Oid=10180.
https://10.10.10.205/extrahop/#/Devices?details=true&device Oid=10180&from=6&interval_type=HR&until=0&view=l2stats
To perform specific requests for that device, add 10180 to the id field in the REST API Explorer or to the body parameter in your request.
The URL for dashboards displays a short_code, which appears after /Dashboard. When you add the short_code to the REST API Explorer or to your request, you must prepend a tilde to the short code.
In the following example, kmC9Y is the short_code. To perform requests for this dashboard, add ~kmC9Y as the value for the short_code field.
https://10.10.10.205/extrahop/#/Dashboard/kmC9Y/?from=6&interval_ type=HR&until=0
You can also find the short_code and dashboard ID in the Dashboard Properties for any dashboard, which can be accessed from the command menu
. Some API operations, such as DELETE, require the dashboard ID.
ExtraHop API resources
You can perform operations on the following resources through the ExtraHop REST API. You also can view more detailed information about these resources, such as available HTTP methods, query parameters, and object properties in the REST API Explorer.
Activity Map
An activity map is a dynamic visual representation of the L4-L7 protocol activity between devices in your network. Create a 2D or 3D layout of device connections in real-time to learn about the traffic flow and relationships between devices.
Here are some important considerations about activity maps:
- You can only create activity maps for devices in Standard Analysis and Advanced Analysis. Discovery Mode devices are not included in activity maps. For more information, see Analysis levels.
- If you create an activity map for a device, activity group, or device group with no protocol activity in the selected time interval, the map appears without any data. Change the time interval or your origin selection and try again.
- You can create an activity map in a Command appliance or in Reveal(x) 360 to view device connections across all of your sensors.
To learn about configuring and navigating activity maps, see Activity maps.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /activitymaps | Retrieve all activity maps. |
POST /activitymaps | Create a new activity map. |
POST /activitymaps/query | Perform a network topology query, which returns activity map data in flat file content. |
DELETE /activitymaps/{id} | Delete a specific activity map. |
GET /activitymaps/{id} | Retrieve a specific activity map. |
PATCH /activitymaps/{id} | Update a specific activity map. |
POST /activitymaps/{id}/query | Perform a topology query for a specific activity map, which returns activity map data in flat file content. |
GET /activitymaps/{id}/sharing | Retrieve the users and their sharing permissions for a specific activity map. |
PATCH /activitymaps/{id}/sharing | Update the users and their sharing permissions for a specific activity map. |
PUT /activitymaps/{id}/sharing | Replace the users and their sharing permissions for a specific activity map. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Alert
Alerts are system notifications that are generated upon specified alert criteria. Default alerts are available in the system, or you can create a custom alert.
Note: | Machine learning detections require a connection to ExtraHop Cloud Services. |
The following table displays all of the operations you can perform this resource:
Operation | Description |
---|---|
GET /alerts | Retrieve all alerts. |
POST /alerts | Create a new alert with specified values. |
DELETE /alerts{id} | Delete a specific alert. |
GET /alerts{id} | Retrieve a specific alert. |
PATCH /alerts{id} | Apply updates to a specific alert. |
GET /alerts{id}/applications | Retrieve all applications that have a specific alert assigned. |
POST /alerts{id}/applications | Assign and unassign a specific alert to applications. |
DELETE /alerts{id}/applications/{child-id} | Unassign an application from a specific alert. |
POST /alerts{id}/applications/{child-id} | Assign an application to a specific alert. |
GET /alerts/{id}/devicegroups | Retrieve all device groups that have a specific alert assigned. |
POST /alerts/{id}/devicegroups | Assign and unassign a specific alert to device groups. |
DELETE /alerts/{id}/devicegroups/{child-id} | Unassign a device group from a specific alert. |
POST /alerts/{id}/devicegroups/{child-id} | Assign a device group to a specific alert. |
GET /alerts/{id}/devices | Retrieve all devices that have a specific alert assigned. |
POST /alerts/{id}/devices | Assign and unassign a specific alert to devices. |
DELETE /alerts/{id}/devices/{child-id} | Unassign a device from a specific alert. |
POST /alerts/{id}/devices/{child-id} | Assign a device to a specific alert. |
GET /alerts/{id}/emailgroups | Retrieve all email groups that have a specific alert assigned. |
POST /alerts/{id}/emailgroups | Assign and unassign a specific alert to email groups. |
DELETE /alerts/{id}/emailgroups/{child-id} | Unassign a email group from a specific alert. |
POST /alerts/{id}/emailgroups/{child-id} | Assign a email group to a specific alert. |
GET /alerts/{id}/exclusionintervals | Retrieve all exclustion intervals that have a specific alert assigned. |
POST /alerts/{id}/exclusionintervals | Assign and unassign a specific alert to exclustion intervals. |
DELETE /alerts/{id}/exclusionintervals/{child-id} | Unassign an exclusion interval from a specific alert. |
POST /alerts/{id}/exclusionintervals/{child-id} | Assign an exclusion interval to a specific alert. |
GET /alerts/{id}/networks | Retrieve all networks that have a specific alert assigned. |
POST /alerts/{id}/networks | Assign and unassign a specific alert to networks. |
DELETE /alerts/{id}/networks/{child-id} | Unassign a network from a specific alert. |
POST /alerts/{id}/networks/{child-id} | Assign a network to a specific alert. |
GET /alerts/{id}/stats | Retrieve all additional statistics for a specific alert. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Alert severity levels
The severity level you specify for an alert is displayed on the Alerts page, email notifications, and SNMP traps.
The following severity levels are supported. Severity levels 0-2 require immediate attention.
Value | Name | Description |
---|---|---|
0 | Emergency | System functionality is unavailable. |
1 | Alert | Immediate action is required. |
2 | Critical | Critical conditions are occurring. |
3 | Error | Error conditions are occurring. |
4 | Warning | Warning conditions are occurring. |
5 | Notice | Normal operations are occurring with significant conditions, such as a restart. |
6 | Info | Normal operations are occurring with process updates. |
7 | Debug | Debug-level messages are available. |
Analysis Priority
The ExtraHop system analyzes and classifies traffic for every device it discovers. Your license reserves capacity for the ExtraHop system to collect metrics for high-value devices. This capacity is associated with two analysis levels: Advanced Analysis and Standard Analysis.
You can specify which devices receive Advanced Analysis and Standard Analysis levels by configuring analysis priority rules. Analysis priorities help inform the ExtraHop system about which devices are important in your environment. A third analysis level, Discovery Mode, is available for devices that are not in Advanced or Standard Analysis.
Note: | By default, each sensor (Discover appliance) manages its own analysis priorities. If the sensor is connected to a Command appliance or to Reveal(x) 360, you can centrally manage these shared system settings from one of those systems. |
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /analysispriority/config/{sensor_id} | Retrieve the analysis priority rules for a specific sensor. |
PUT /analysispriority/config/{sensor_id} | Replace the analysis priority rules for a specific sensor. |
GET /analysispriority/{sensor_id}/manager | Retrieve the system that is configured to manage the analysis priority rules for the sensor. |
PATCH /analysispriority/{sensor_id}/manager | Update the system that manages analysis priority rules for a specific sensor. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
APIKey
An API key enables a user to perform operations through the ExtraHop REST API.
You can generate the initial API key for the setup user account through the REST API. All other API keys are generated through the API Access page in the Administration settings.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /apikeys | Retrieve all API keys. |
POST /apikeys | Create the initial API key for the setup user account. |
GET /apikeys/{keyid} | Retrieve information about a specific API key. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Appliance
The ExtraHop system consists of a network of connected appliances that perform tasks such as monitoring traffic, analyzing data, storing data, and identifying detections.
You can retrieve information about ExtraHop appliances connected to the local appliance and establish new connections to remote ExtraHop appliances.
Note: | You can only establish a connection to a remote ExtraHop appliance that is licensed for the same edition as the local ExtraHop appliance. |
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /appliances | Retrieve all remote ExtraHop appliances connected to the local appliance. |
POST /appliances | Establish a new connection to a remote ExtraHop appliance. |
GET /appliances/{id} | Retrieve a specific remote ExtraHop appliance connected to the local appliance. |
GET /appliances/{id}/productkey | Retrieve the product key of the specified appliance. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Application
Applications are user-defined groups that collect metrics identified through triggers across multiple types of traffic. The default All Activity application contains all collected metrics.
The following table displays all of the operations you can perform on the application resource:
Operation | Description |
---|---|
GET /applications | Retrieve all applications that were active within a specific timeframe. |
POST /applications | Create a new application. |
GET /applications/{id} | Retreive a specific application. |
PATCH /applications/{id} | Update a specific application. |
GET /applications/{id}/activity | Retrieve all activity for a specific application. |
GET /applications/{id}/alerts | Retrieve all alerts that are assigned to a specific application. |
POST /applications/{id}/alerts | Assign and unassign alerts to a specific application. |
DELETE /applications/{id}/alerts/{child-id} | Unassign an alert from a specific application. |
POST /applications/{id}/alerts/{child-id} | Assign an alert to a specific application. |
GET /applications/{id}/dashboards | Retrieve all dashboards related to a specific application. |
GET /applications/{id}/pages | Retrieve all pages that are assigned to a specific application. |
POST /applications/{id}/pages | Assign and unassign pages to a specific application. |
DELETE /applications/{id}/pages/{child-id} | Unassign a page from a specific application. |
POST /applications/{id}/pages/{child-id} | Assign a page to a specific application. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Audit log
The audit log displays a record of all recorded system administration and configuration activity, such as the time of the activity, the user who performed the activity, the operation, operation details, and system component..
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /auditlog | Retrieve all audit log messages. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Auth
You can configure secure, single sign-on (SSO) authentication to the ExtraHop system through one or more security assertion markup language (SAML) identity providers.
When a user logs in to an ExtraHop system that is configured as a service provider (SP) for SAML SSO authentication, the ExtraHop system requests authorization from the appropriate identity provider (IdP). The identity provider authenticates the user's credentials and then returns the authorization for the user to the ExtraHop system. The user is then able to access the ExtraHop system.
Operation | Description |
---|---|
GET /auth/identityproviders | Retrieve all identity providers. |
POST /auth/identityproviders | Add an identity provider for remote authentication. |
DELETE /auth/identityproviders/{id} | Delete a specific identity provider. |
GET /auth/identityproviders/{id} | Retrieve a specific identity provider. |
PATCH /auth/identityproviders/{id} | Update an existing identity provider. |
GET /auth/identityproviders/{id}/privileges | Retrieve the privilege settings for a specific identity provider. |
PATCH /auth/identityproviders/{id}/privileges | Update the privilege settings for a specific identity provider. |
GET /auth/samlsp | Retrieve SAML security provider (SP) metadata for this ExtraHop system. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Bundle
Bundles are JSON-formatted documents that contain information about selected system configuration, such as triggers, dashboards, applications, or alerts.
You can create a bundle and then transfer those configurations to another ExtraHop system, or save the bundle as a backup. Bundles can also be downloaded from ExtraHop Solution Bundles and applied through the REST API. For more information, see Bundles.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /bundles | Retrieve metadata about all bundles on the ExtraHop system. |
POST /bundles | Upload a new bundle to the ExtraHop system. |
DELETE /bundles/{id} | Delete a specific bundle. |
GET /bundles/{id} | Retrieve a specific bundle export. |
POST /bundles/{id}/apply | Apply a saved bundle to the ExtraHop system. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Cloud
This resource enables you to connect your on-premises sensors to Reveal(x) 360 For more information, see Connect to Reveal(x) 360 from self-managed sensors.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
POST /cloud/connect | Connect the ExtraHop system to Reveal(x) 360. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Custom device
You can create a custom device by defining a set of rules.
For example, you can create a custom device that has an IP address on a specified VLAN. By default, all IP addresses outside of the locally-monitored broadcast domains are aggregated behind a router. To identify devices that are behind that router, you can create a custom device, and then collect metrics from the device. For more information, see Create custom devices through the REST API.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /customdevices | Retrieve all custom devices. |
POST /customdevices | Create a custom device. |
DELETE /customdevices/{id} | Delete a specific custom device. |
GET /customdevices/{id} | Retrieve a specific custom device. |
PATCH /customdevices/{id} | Update a specific custom device. |
GET /customdevices/{id}/criteria | Retrieve all criteria fro the specific custom device. |
POST /customdevices/{id}/criteria | Create a new criterion for a specific custom device. |
DELETE /customdevices/{id}/criteria/{child-id} | Delete a criterion for a specific custom device. |
GET /customdevices/{id}/criteria/{child-id} | Retrieve a single custom device criterion. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Customization
The Customization resource enables you to manage backups files on the ExtraHop system. You must have unlimited privileges to perform operations on this resource.
Backup files contain both customizations and systems resources. Customizations are user-defined objects, such as alerts, dashboards, triggers, and custom metrics. System resources are items such as bundles, local users and groups, and the SSL certificate. For more information, see Back up and restore a Discover or Command appliance.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /customizations | Retrieve all backup files. |
POST /customizations | Create a backup file. |
GET /customizations/status | Retrieve status details for the most recent backup attempt. |
DELETE /customizations/{id} | Delete a specific backup file. |
GET /customizations/{id} | Retrieve a specific backup file. |
POST /customizations/{id}/apply | Restore only customizations from a specific backup file. |
POST /customizations/{id}/download | Download a specific backup file. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Dashboards
Dashboards are built-in or customized views of your ExtraHop metrics information. For more information, see Dashboards.
The following table displays all of the operations you can perform on this resource:
Operation | Description | ||
---|---|---|---|
GET /dashboards | Retrieve all dashboards. | ||
DELETE /dashboards/{id} | Delete a specific dashboard. | ||
GET /dashboards/{id} | Retrieve a specific dashboard. | ||
PATCH /dashboards/{id} | Update ownership of a specific dashboard. | ||
GET /dashboards/{id}/reports | Retrieve scheduled reports that contain a specific dashboard.
|
||
GET /dashboards/{id}/sharing | Retrieve the users and their sharing permissions for a specific dashboard. | ||
PATCH /dashboards/{id}/sharing | Update the users and their sharing permissions for a specific dashboard. | ||
PUT /dashboards/{id}/sharing | Replace the users and their sharing permissions for a specific dashboard. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Device
Devices are objects on your network that have been identified and classified by your ExtraHop system. For more information, see Devices.
The following table displays all of the operations you can perform on this resource:
Operation | Description | ||
---|---|---|---|
GET /devices | Retrieve all devices that were active within a specific time period. For more
information, see Extract the device list through the REST API.
|
||
POST /devices/search | Retrieve all devices that match specific criteria. For more information, see Search for a device through the REST API.
|
||
GET /devices/{id} | Retrieve a specific device. | ||
PATCH /devices/{id} | Update a specific device. | ||
GET /devices/{id}/activity | Retrieve all activity for a device. | ||
GET /devices/{id}/alerts | Retrieve all alerts that are assigned to a specific device. | ||
POST /devices/{id}/alerts | Assign and unassign a specific device to alerts. | ||
DELETE /devices/{id}/alerts/{child-id} | Unassign an alert from a specific device. | ||
POST /devices/{id}/alerts/{child-id} | Assign an alert to a specific device. | ||
GET /devices/{id}/dashboards | Retrieve all dashboards related to a specific device. | ||
GET /devices/{id}/devicegroups | Retrieve all device groups that are assigned to a specific device. | ||
POST /devices/{id}/devicegroups | Assign and unassign a specific device to device groups. | ||
DELETE /devices/{id}/devicegroups/{child-id} | Unassign a device group from a specific device. | ||
POST /devices/{id}/devicegroups/{child-id} | Assign a device group to a specific device. | ||
GET /devices/{id}/dnsnames | Retrieve all DNS names that are associated with a specific device. | ||
GET /devices/{id}/ipaddrs | Retrieve all IP addresses that were associated with a specific device within a given time period. | ||
GET /devices/{id}/software | Retrieve a list of software running on the specified device. | ||
GET /devices/{id}/tags | Retrieve all tags that are assigned to a specific device. | ||
POST /devices/{id}/tags | Assign and unassign a specific device to tags. | ||
DELETE /devices/{id}/tags/{child-id} | Unassign a tag from a specific device. | ||
POST /devices/{id}/tags/{child-id} | Assign a tag to a specific device. | ||
GET /devices/{id}/triggers | Retrieve all triggers that are assigned to a specific device. | ||
POST /devices/{id}/triggers | Assign and unassign a specific device to triggers. | ||
DELETE /devices/{id}/triggers/{child-id} | Unassign a trigger from a specific device. | ||
POST /devices/{id}/triggers/{child-id} | Assign a trigger to a specific device. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Operand values for device search
The POST /devices/search operation enables you to search for devices by criteria specified in filter objects. Each object should contain a unique value for the operand field that is valid for the specified field value.
activity
To search by metric activity, specify the field value as activity and the operand value as a metric_category. You can find metric_category values in the REST API Parameters section of the Metric Catalog.

The following example returns results for devices that match all metric activity classified for a DHCP client, such as the number of DHCP requests sent.
{ "filter": { "field": "activity", "operand": "dhcp_client", "operator": "=" } }
Tip: | Programmatically retrieve a list of all metric activity for a device through the GET /devices/{id}/activity operation. The stat_name value matches the metric_category value in the metric_catalog, after the final dot. |
In the following example response, the stat_name value is extrahop.device.dhcp_client. Remove the text before the final dot to identify the metric_catalog value of dhcp_client.
{ "id": 198606, "from_time": 1581537120000, "until_time": 1581542520000, "mod_time": 1581542533963, "device_id": 30096, "stat_name": "extrahop.device.dhcp_client" }
discover_time
To search by a time range, specify the field value as discover_time and an operand value with from and until parameters, where the values are dates, expressed in milliseconds since the epoch.
The following example returns results for all device activity that occurred between 1:00 PM to 3:00 PM on August 21, 2019.
{ "filter": { "field": "discover_time", "operand": { "from": "1566392400000", "until": "1566399600000" }, "operator": "=" } }
discovery_id
To search by the unique ID for the device, specify the field value as discovery_id and the operand value as the discovery ID.
{ "filter": { "field": "discovery_id", "operand": "c12vf90qpg290000", "operator": "=" } }
ipaddr
To search by IP address, specify the field value as ipaddr and the operand value as an IP address or CIDR block.
{ "filter": { "field": "ipaddr", "operand": "192.168.12.0/28", "operator": "=" } }
node
To search by the unique ID of a sensor (Discover appliance), specify the field value as node and the operand value as the sensor UUID.
{ "filter": { "field": "node", "operand": "qqvsplfa-zxsk-32l0-19g1-076vfr42pw31", "operator": "=" } }
macaddr
To search by the MAC address of a device, specify the field value as macaddr and the operand value as the device MAC address. The following example returns results for devices with a MAC address of C1:1C:N2:0Q:PJ:10 or C1:1C:N2:0Q:PJ:11.
{ "filter": { "operator": "or", "rules": [ { "field": "macaddr", "operand": "C1:1C:N2:0Q:PJ:10", "operator": "=" }, { "field": "macaddr", "operand": "C1:1C:N2:0Q:PJ:11", "operator": "=" } ] } }
name
To search by the device display name, specify the field value as name and the operand value as the device name or as a regex string.
{ "filter": { "field": "name", "operand": "VMware B2CEB6", "operator": "=" } }
role
To search by the device role, specify the field value as role and the operand value as the device role.
{ "filter": { "field": "role", "operand": "voip_phone", "operator": "=" } }
software
To search by the software running on the device, specify the field value as software and the operand value as the ID associated with that software on the ExtraHop system or as a regex string.
{ "filter": { "field": "software", "operand": "windows_10", "operator": "=" } }
Tip: | Programmatically retrieve a list of all software IDs associated with a
device through the GET /devices/{id}/software operation. In the following example response, the id value for the software is windows_10. [ { "software_type": "OS", "name": "Windows", "version": "10", "description": null, "id": "windows_10" } ] |
tag
To search by a device tag, specify the field value as tag and the operand value as the tag name or as a regex string.
{ "filter": { "field": "tag", "operand": "Custom Tag", "operator": "=" } }
Tip: | Programmatically retrieve a list of all device tags through the
GET /devices/{id}/tags operation. In the following example response, the name value for the tag is Custom Tag. [ { "mod_time": 1521577040934, "id": 19, "name": "Custom Tag" } ] |
vlan
To search by the ID of a VLAN, specify the field value as vlan and the operand value as the ID of the VLAN.
{ "filter": { "field": "vlan", "operand": "0", "operator": "=" } }
Search with regular expressions (regex)
For certain field values, the string can be in regex syntax. Specify the operand value as an object that has a value parameter with the regex syntax you want to match and an is_regex parameter that is set to true. The following example returns results for all DNS names that end with com.
{ "filter": { "field": "dns_name", "operand": { "value": ".*?com", "is_regex": true }, "operator": "=" } }
An operand field with regex syntax is valid for the following field values:
- cdp_name
- custom_name
- dns_name
- dhcp_name
- model
- name
- netbios_name
- software
- tag
- vendor
Supported time units
For most parameters, the default unit for time measurement is milliseconds. However, the following parameters return or accept alternative time units such as minutes and hours:
- Device
- active_from
- active_until
- Device group
- active_from
- active_until
- Metrics
- from
- until
- Record Log
- from
- until
- context_ttl
The following table displays supported time units:
Time unit | Unit suffix |
---|---|
Year | y |
Month | M |
Week | w |
Day | d |
Hour | h |
Minute | m |
Second | s |
Millisecond | ms |
To specify a time unit other than milliseconds for a parameter, append the unit suffix to the value. For example, to request devices active in the last 30 minutes, specify the following parameter value:
GET /api/v1/devices?active_from=-30m
The following example specifies a search for HTTP records created between 1 and 2 hours ago:
{ "from": "-2h", "until": "-1h", "types": ["~http"] }
Device group
Device groups can be either static or dynamic.
A static device group is user-defined; you create a device group and then manually identify and assign each device to that group. A dynamic device group is defined and automatically managed by a set of configured rules.
For example, you can create a device group and then set a rule to classify all devices within a certain IP address range to be added to that group automatically. For more information, see Device Groups.
The following table displays all of the operations you can perform on this resource:
Operation | Description | ||
---|---|---|---|
GET /devicegroups | Retrieve all device groups that were active within a specific time period. | ||
POST /devicegroups | Create a new device group. | ||
DELETE /devicegroups/{id} | Delete a device group. | ||
GET /devicegroups/{id} | Retrieve a specific device group. | ||
PATCH /devicegroups/{id} | Update a specific device group. | ||
GET /devicegroups/{id}/alerts | Retrieve all alerts that are assigned to a specific device group. | ||
POST /devicegroups/{id}/alerts | Assign and unassign a specific device group to alerts. | ||
DELETE /devicegroups/{id}/alerts/{child-id} | Unassign an alert from a specific device group. | ||
POST /devicegroups/{id}/alerts/{child-id} | Assign an alert to a specific device group. | ||
GET /devicegroups/{id}/dashboards | Retrieve all dashboards related to a specific device group. | ||
GET /devicegroups/{id}/devices | Retrieve all devices in the device group that are active within a specific time
window.
|
||
POST /devicegroups/{id}/devices | Assign and unassign a devices to a specific static device group. | ||
DELETE /devicegroups/{id}/devices/{child-id} | Unassign a device from a specific static device group. | ||
POST /devicegroups/{id}/devices/{child-id} | Assign a device to a specific static device group. | ||
GET /devicegroups/{id}/pages | Retrieve all pages that are assigned to a specific device group. | ||
POST /devicegroups/{id}/pages | Assign and unassign a specific device to pages group. | ||
DELETE /devicegroups/{id}/pages/{child-id} | Unassign a page from a specific device group. | ||
POST /devicegroups/{id}/pages/{child-id} | Assign a page to a specific device group. | ||
GET /devicegroups/{id}/triggers | Retrieve all triggers that are assigned to a specific device group. | ||
POST /devicegroups/{id}/triggers | Assign and unassign a specific device group to triggers. | ||
DELETE /devicegroups/{id}/triggers/{child-id} | Unassign a trigger from a specific device group. | ||
POST /devicegroups/{id}/triggers/{child-id} | Assign a trigger to a specific device group. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Supported time units
For most parameters, the default unit for time measurement is milliseconds. However, the following parameters return or accept alternative time units such as minutes and hours:
- Device
- active_from
- active_until
- Device group
- active_from
- active_until
- Metrics
- from
- until
- Record Log
- from
- until
- context_ttl
The following table displays supported time units:
Time unit | Unit suffix |
---|---|
Year | y |
Month | M |
Week | w |
Day | d |
Hour | h |
Minute | m |
Second | s |
Millisecond | ms |
To specify a time unit other than milliseconds for a parameter, append the unit suffix to the value. For example, to request devices active in the last 30 minutes, specify the following parameter value:
GET /api/v1/devices?active_from=-30m
The following example specifies a search for HTTP records created between 1 and 2 hours ago:
{ "from": "-2h", "until": "-1h", "types": ["~http"] }
Operand values for device groups
The POST /devicegroups operation enables you to create device groups according to criteria specified in filter objects. Each object should contain a unique value for the operand field that is valid for the specified field value.
activity
To select devices by metric activity, specify the field value as activity and the operand value as a metric_category. You can find metric_category values in the REST API Parameters section of the Metric Catalog.

The following example selects devices with metric activity classified for a DHCP client, such as the number of DHCP requests sent.
{ "filter": { "field": "activity", "operand": "dhcp_client", "operator": "=" } }
Tip: | Programmatically retrieve a list of all metric activity for a device through the GET /devices/{id}/activity operation. The stat_name value matches the metric_category value in the metric_catalog, after the final dot. |
In the following example response, the stat_name value is extrahop.device.dhcp_client. Remove the text before the final dot to identify the metric_catalog value of dhcp_client.
{ "id": 198606, "from_time": 1581537120000, "until_time": 1581542520000, "mod_time": 1581542533963, "device_id": 30096, "stat_name": "extrahop.device.dhcp_client" }
discover_time
To select devices by a time range, specify the field value as discover_time and an operand value with from and until parameters, where the values are dates, expressed in milliseconds since the epoch.
The following example selects devices with activity that occurred between 1:00 PM to 3:00 PM on August 21, 2019.
{ "filter": { "field": "discover_time", "operand": { "from": "1566392400000", "until": "1566399600000" }, "operator": "=" } }
discovery_id
To select devices by unique device ID, specify the field value as discovery_id and the operand value as the discovery ID.
{ "filter": { "field": "discovery_id", "operand": "c12vf90qpg290000", "operator": "=" } }
ipaddr
To select devices by IP address, specify the field value as ipaddr and the operand value as an IP address or CIDR block.
{ "filter": { "field": "ipaddr", "operand": "192.168.12.0/28", "operator": "=" } }
node
To select devices by the unique ID of a Discover appliance, specify the field value as node and the operand value as the appliance UUID.
{ "filter": { "field": "node", "operand": "qqvsplfa-zxsk-32l0-19g1-076vfr42pw31", "operator": "=" } }
macaddr
To select devices by MAC address, specify the field value as macaddr and the operand value as the device MAC address. The following example returns results for devices with a MAC address of C1:1C:N2:0Q:PJ:10 or C1:1C:N2:0Q:PJ:11.
{ "filter": { "operator": "or", "rules": [ { "field": "macaddr", "operand": "C1:1C:N2:0Q:PJ:10", "operator": "=" }, { "field": "macaddr", "operand": "C1:1C:N2:0Q:PJ:11", "operator": "=" } ] } }
name
To select devices by display name, specify the field value as name and the operand value as the device name or as a regex string.
{ "filter": { "field": "name", "operand": "VMware B2CEB6", "operator": "=" } }
role
To select devices by role, specify the field value as role and the operand value as the device role.
{ "filter": { "field": "role", "operand": "voip_phone", "operator": "=" } }
software
To select devices by the software running on the device, specify the field value as software and the operand value as the ID associated with that software on the ExtraHop system or as a regex string.
{ "filter": { "field": "software", "operand": "windows_10", "operator": "=" } }
Tip: | Programmatically retrieve a list of all software IDs associated with a
device through the GET /devices/{id}/software operation. In the following example response, the id value for the software is windows_10. [ { "software_type": "OS", "name": "Windows", "version": "10", "description": null, "id": "windows_10" } ] |
tag
To select devices by tag, specify the field value as tag and the operand value as the tag name or as a regex string.
{ "filter": { "field": "tag", "operand": "Custom Tag", "operator": "=" } }
Tip: | Programmatically retrieve a list of all device tags through the
GET /devices/{id}/tags operation. In the following example response, the name value for the tag is Custom Tag. [ { "mod_time": 1521577040934, "id": 19, "name": "Custom Tag" } ] |
vlan
To select devices by the ID of a VLAN, specify the field value as vlan and the operand value as the ID of the VLAN.
{ "filter": { "field": "vlan", "operand": "0", "operator": "=" } }
Search with regular expressions (regex)
For certain field values, the string can be in regex syntax. Specify the operand value as an object that has a value parameter with the regex syntax you want to match and an is_regex parameter that is set to true. The following example selects devices with DNS names that end with com.
{ "filter": { "field": "dns_name", "operand": { "value": ".*?com", "is_regex": true }, "operator": "=" } }
An operand field with regex syntax is valid for the following field values:
- cdp_name
- custom_name
- dns_name
- dhcp_name
- model
- name
- netbios_name
- software
- tag
- vendor
Detections
The Detections class enables you to retrieve detections that have been identified by the ExtraHop system.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /detections | Retrieve all detections. |
GET /detections/formats | Retrieve all detection formats. |
POST /detections/formats | Create a new detection format. |
DELETE /detections/formats/{id} | Delete a specific detection format. |
PATCH /detections/formats | Update a specific detection format. |
POST /detections/search | Retrieve detections that match the specified search criteria. |
PATCH /detections/tickets | Update a ticket associated with detections. |
GET /detections/{id} | Retrieve a specific detection. |
PATCH /detections/{id} | Update a detection. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Email group
You can add individual or group email addresses to an email group and assign them to a system alert. When that alert is triggered, the system sends an email to all of the addresses in the email group.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /emailgroups | Retrieve all email groups. |
POST /emailgroups | Create a new email group. |
DELETE /emailgroups/{id} | Delete a email group by a unique identifier. |
GET /emailgroups/{id} | Retrieve a specific email group by a unique identifier. |
PATCH /emailgroups/{id} | Apply updates to a specific email group. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Exclusion intervals
An exclusion interval can be created to set a time period to suppress an alert.
For example, if you do not want to be notified about alerts after hours or on the weekends, an exclusion interval can create a rule to suppress the alert during that time period. For more information, see Alerts.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /exclusionintervals | Retrieve all exclusion intervals. |
POST /exclusionintervals | Create a new exclusion interval. |
DELETE /exclusionintervals/{id} | Delete a specific exclusion interval. |
GET /exclusionintervals/{id} | Retrieve a specific exclusion interval. |
PATCH /exclusionintervals/{id} | Apply updates to a specific exclusion interval. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
ExtraHop
This resource provides metadata about the ExtraHop system.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /extrahop | Retrieve metadata about the firmware running on the ExtraHop system. |
GET /extrahop/cluster | Retrieve Explore cluster configuration settings. |
PATCH /extrahop/cluster | Update Explore cluster configuration settings. |
PUT /extrahop/detections/access | Update detections access control settings. |
GET /extrahop/edition | Retrieve the edition of the ExtraHop system. |
POST /extrahop/firmware | Upload a new firmware image to the ExtraHop system. For more information, see Upgrade ExtraHop firmware through the REST API. |
POST /extrahop/firmware/latest/upgrade | Upgrade the ExtraHop system to the most recently uploaded firmware image. |
GET /extrahop/idrac | Retrieve the iDRAC IP address of the ExtraHop system. |
GET /extrahop/platform | Retrieve the platform name of the ExtraHop system. |
GET /extrahop/processes | Retrieve a list of processes running on the ExtraHop system. |
POST /extrahop/processes/{process}/restart | Restart a process running on the ExtraHop system. |
GET /extrahop/services | Retrieve settings for all services. |
PATCH /extrahop/services | Update the settings for services. |
POST /extrahop/restart | Restart the ExtraHop system. |
POST /extrahop/sslcert | Regenerate the SSL certificate on the ExtraHop system. For more information, see Create a trusted SSL certificate through the REST API |
PUT /extrahop/sslcert | Replace the SSL certificate on the ExtraHop system. |
POST /extrahop/sslcert/signingrequest | Create an SSL certificate signing request. For more information, see Create a trusted SSL certificate through the REST API. |
GET /extrahop/ticketing | Retrieve the ticketing integration status. |
PATCH /extrahop/ticketing | Enable or disable ticketing integration. |
GET /extrahop/version | Retrieve the version of the firmware running on the ExtraHop system. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
License
This resource enables you to retrieve and set product keys or to retrieve and set a license.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /license | Retrieve the license applied to this ExtraHop system. |
PUT /license | Apply and register a new license to the ExtraHop system. |
GET /license/productkey | Retrieve the product key to this ExtraHop system. |
PUT /license/productkey | Apply the specified product key to the ExtraHop system and register the license. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Metrics
Metrics information is collected about every object identified by the ExtraHop system.
Note that metrics are retrieved through the POST method, which creates a query to collect the requested information through the API. For more information, see Extract metrics through the REST API.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
POST /metrics | Perform a metric query. |
GET /metrics/next/{xid} | If a previous metric query requested activity group metrics from a Command appliance, the GET /metrics/next/{xid} operation retrieves metrics for the activity group on a connected sensor (Discover appliance). Each time a request is sent to GET /metrics/next/{xid}, the operation returns metrics from a different sensor. After all metrics have been retrieved, the operation returns null. |
POST /metrics/total | Perform a metric query for total values. |
POST /metrics/totalbyobject | Perform a metric query for total values that are grouped by object. |
For example, if you want to see all HTTP responses that occurred on the network in the last 30 minutes, enter the following request schema into the POST /metrics operation:
{ "cycle": "auto", "from": -1800000, "metric_category": "http", "metric_specs": [ { "name": "rsp" } ], "object_ids": [ 0 ], "object_type": "application", "until": 0 }
The response body returns a list of HTTP responses and the time of each event, similar to the following output:
{ "stats": [ { "oid": 0, "time": 1494539640000, "duration": 30000, "values": [ 354 ] }, { "oid": 0, "time": 1494539640000, "duration": 30000, "values": [ 354 ] }, { "oid": 0, "time": 1494539640000, "duration": 30000, "values": [ 354 ] }, ], "cycle": "30sec", "node_id": 0, "clock": 1494541440000, "from": 1494539640000, "until": 1494541440000 }
Enter the same request schema into the POST /metrics/total operation to retrieve a count of all HTTP responses that occurred on the network in the last 30 seconds. The response body is similar to the following output:
{ "stats": [ { "oid": -1, "time": 1494541380000, "duration": 1800000, "values": [ 33357 ] } ], "cycle": "30sec", "node_id": 0, "clock": 1494541440000, "from": 1494539640000, "until": 1494541440000 }
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Supported time units
For most parameters, the default unit for time measurement is milliseconds. However, the following parameters return or accept alternative time units such as minutes and hours:
- Device
- active_from
- active_until
- Device group
- active_from
- active_until
- Metrics
- from
- until
- Record Log
- from
- until
- context_ttl
The following table displays supported time units:
Time unit | Unit suffix |
---|---|
Year | y |
Month | M |
Week | w |
Day | d |
Hour | h |
Minute | m |
Second | s |
Millisecond | ms |
To specify a time unit other than milliseconds for a parameter, append the unit suffix to the value. For example, to request devices active in the last 30 minutes, specify the following parameter value:
GET /api/v1/devices?active_from=-30m
The following example specifies a search for HTTP records created between 1 and 2 hours ago:
{ "from": "-2h", "until": "-1h", "types": ["~http"] }
Network
Networks are correlated to the network interface card that receives input from all of the objects identified by the ExtraHop system.
On an ExtraHop Command appliance, each connected sensor (Discover appliance) is identified as a network capture. For more information, see Networks.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /networks | Retrieve all networks. |
GET /networks/{id} | Retreive a specific network by ID. |
PATCH /networks/{id} | Update a specific network by ID. |
GET /networks/{id}/alerts | Retrieve all alerts that are assigned to a specific network. |
POST /networks/{id}/alerts | Assign and unassign alerts to a specific network. |
DELETE /networks/{id}/alerts/{child-id} | Unassign an alert from a specific network. |
POST /networks/{id}/alerts/{child-id} | Assign an alert to a specific network. |
GET /networks/{id}/pages | Retrieve all pages that are assigned to a specific network. |
POST /networks/{id}/pages | Assign and unassign pages to a specific network. |
DELETE /networks/{id}/pages/{child-id} | Unassign a page from a specific network. |
POST /networks/{id}/pages/{child-id} | Assign a page to a specific network. |
GET /networks/{id}/vlans | Retrieve all VLANS assigned to a specific network. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Network locality entry
You can manage a list that specifies the network locality of IP addresses.
For example, you can create an entry in the network locality list that specifies that an IP address or CIDR block is internal or external.
The following table displays all of the operations you can perform on this resource:
Operation | Description | ||
---|---|---|---|
GET /networklocalities | Retrieve all network locality entries. | ||
POST /networklocalities | Create a network locality entry. | ||
DELETE /networklocalities/{id} | Delete a network locality entry.
|
||
GET /networklocalities/{id} | Retrieve a specific network locality entry. | ||
PATCH /networklocalities/{id} | Apply updates to a specific network locality entry.
|
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Node
A node is a sensor (Discover appliance) that is connected to a Command appliance.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /nodes | Retrieve all sensors connected to this Command appliance. |
GET /nodes/{id} | Retrieve a specific sensor that is connected to this Command appliance. |
PATCH /nodes/{id} | Update a specific sensor that is connected to this Command appliance. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Observations
An observation associates the IP address of a device on the ExtraHop system with an IP address outside of your network. For example, you can track the activity of a VPN user by associating the IP address of the VPN client on your internal network with the external IP address assigned to the user on the public internet.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
POST /observations/associatedipaddrs | Add an observation to create an association between device IP addresses. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Open Data Stream
An open data stream (ODS) is a channel through which you can send specified metric data to an external, third-party system. For example, you might want to store or analyze metric data with a remote tool, such as Splunk, MongoDB, or Amazon Web Services (AWS).
Sending data through an open data stream is a two-step procedure. First, you configure a connection to the target system that will receive the data. Second, you write a trigger that specifies what data to send to the target system and when to send it. For more information, see Open Data Streams.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /odstargets | Retrieve all Open Data Stream targets. |
GET /odstargets/http | Retrieve all HTTP Open Data Stream targets. |
POST /odstargets/http | Create a new HTTP Open Data Stream target. |
DELETE /odstargets/http/{name} | Delete an HTTP Open Data Stream target. |
GET /odstargets/http/{name} | Retrieve a specific HTTP Open Data Stream target. |
GET /odstargets/kafka | Retrieve all Kafka Open Data Stream targets. |
POST /odstargets/kafka | Create a new Kafka Open Data Stream target. |
DELETE /odstargets/kafka/{name} | Delete a Kafka Open Data Stream target. |
GET /odstargets/kafka/{name} | Retrieve a specific Kafka Open Data Stream target. |
GET /odstargets/mongodb | Retrieve all MongoDB Open Data Stream targets. |
POST /odstargets/mongodb | Create a new MongoDB Open Data Stream target. |
DELETE /odstargets/mongodb/{name} | Delete a MongoDB Open Data Stream target. |
GET /odstargets/mongodb/{name} | Retrieve a specific MongoDB Open Data Stream target. |
GET /odstargets/raw | Retrieve all Raw Open Data Stream targets. |
POST /odstargets/raw | Create a new Raw Open Data Stream target. |
DELETE /odstargets/raw/{name} | Delete a Raw Open Data Stream target. |
GET /odstargets/raw/{name} | Retrieve a specific Raw Open Data Stream target. |
GET /odstargets/syslog | Retrieve all Syslog Open Data Stream targets. |
POST /odstargets/syslog | Create a new Syslog Open Data Stream target. |
DELETE /odstargets/syslog/{name} | Delete a Syslog Open Data Stream target. |
GET /odstargets/syslog/{name} | Retrieve a specific Syslog Open Data Stream target. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Packet capture
You can retrieve and delete packets stored on the ExtraHop system.
Note: | For ExtraHop Reveal(x), this resource is not supported and has been replaced by the Packet Search resource. |
You must write a trigger to identify the information you want to generate. For example, you can write a trigger to collect all of the packets going to a particular device that is generating a high volume of errors. Then, you can download or delete that information. For more information, see Packets.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /packetcaptures | Retrieve metadata about all packet captures stored on this ExtraHop system. |
DELETE /packetcaptures/{id} | Permanently remove a specific packet capture from the ExtraHop system. |
GET /packetcaptures/{id} | Download a specific packet capture in PCAP format. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Packet Search
You can search for and download packets stored on the ExtraHop system. The downloaded packets can then be analyzed through a third-party tool, such as Wireshark.
Note: | This resource can only retrieve packets stored on ExtraHop Trace appliances. To retrieve packets stored on a Discover appliance, see the Packet Capture resource. |
For more information about Packets, see Packets.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /packets/search | Search for packets by specifying parameters in a URL. |
POST /packets/search | Search for packets by specifying parameters in a JSON string. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Filter packets with Berkeley Packet Filter syntax
Search for packets with the Berkeley Packet Filter (BPF) syntax alone, or in combination with the built-in filters.
Berkeley Packet Filters are a raw interface to data link layers and are a powerful tool for intrusion detection analysis. The BPF syntax enables users to write filters that quickly drill down on specific packets to see the essential information.
The ExtraHop system constructs a synthetic packet header from the packet index data and then runs the BPF syntax queries against the packet header to ensure that queries are much faster than scanning the full packet payload. Note that ExtraHop supports only a subset of the BPF syntax. See Supported BPF syntax.
The BPF syntax consists of one or more primitives preceded by one or more qualifiers. Primitives usually consist of an ID (name or number) preceded by one or more qualifiers. There are three different kinds of qualifiers:
- type
- Qualifiers that indicate what type the ID name or number refers to. For example, host, net, port, and portrange. If there is no qualifier, host is assumed.
- dir
- Qualifiers that specify a particular transfer direction to and or from an ID. Possible directions are src, dst, src and dst, and src or dst. For example, dst net 128.3.
- proto
- Qualifiers that restrict the match to the particular protocol. Possible protocols are ether, ip, ip6, tcp, and udp.
Supported BPF syntax
The ExtraHop system supports the following subset of the BPF syntax for filtering packets.
Note: |
|
Primitive | Examples | Description |
---|---|---|
[src|dst] host <host ip> | host 203.0.113.50 dst host 198.51.100.200 |
Matches a host as the IP source, destination, or either. These host expressions can be specified in conjunction with other protocols like ip, arp, rarp or ip6. |
ether [src|dst] host <MAC> | ether host 00:00:5E:00:53:00 ether dst host 00:00:5E:00:53:00 |
Matches a host as the Ethernet source, destination, or either. |
vlan <ID> | vlan 100 | Matches a VLAN. Valid ID numbers are 0-4095. VLAN priority
bits are zero. If the original packet had more than one VLAN tag, the synthetic packet the BPF matches against will only have the innermost VLAN tag. |
[src|dst] portrange <p1>-<p2>
or [tcp|udp] [src|dst] portrange <p1>-<p2> |
src portrange 80-88 tcp dst portrange 1501-1549 |
Matches packets to or from a port in the given range. Protocols can be applied to a port range to filter specific packets within the range. |
[ip|ip6][src|dst] proto <protocol> | proto 1 src 10.4.9.40 and proto ICMP ip6 and src fe80::aebc:32ff:fe84:70b7 and proto 47 ip and src 10.4.9.40 and proto 0x0006 |
Matches IPv4 or IPv6 protocols other than TCP and UDP. The protocol can be a number or name. |
[ip|ip6][tcp|udp] [src|dst] port <port> | udp and src port 2005 ip6 and tcp and src port 80 |
Matches IPv4 or IPv6 packets on a specific port. |
[src|dst] net <network> | dst net 192.168.1.0 src net 10 net 192.168.1.0/24 |
Matches packets to or from a source or destination or either, that reside in a
network. An IPv4 network number can be specified as one of the following values:
|
[ip|ip6] tcp tcpflags & (tcp-[ack|fin|syn|rst|push|urg|) | tcp[tcpflags] & (tcp-ack) !=0 tcp[13] & 16 !=0 ip6 and (ip6[40+13] & (tcp-syn) != 0) |
Matches all packets with the specified TCP flag |
Fragmented IPv4 packets (ip_offset != 0) | ip[6:2] & 0x3fff != 0x0000 | Matches all packets with fragments. |
Page
Pages provide a template for creating a customized view of built-in metrics or metrics collected from triggers.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /pages | Retrieve all pages. |
POST /pages | Create a page. |
DELETE /pages/{id} | Delete a single page. |
GET /pages/{id} | Retrieve a single page. |
PATCH /pages/{id} | Update a single page. |
GET /pages/{id}/applications | Retrieve all applications that have a specific page assigned. |
POST /pages/{id}/applications | Assign and unassign a specific page to applications. |
DELETE /pages/{id}/applications/{child-id} | Unassign an application from a specific page. |
POST /pages/{id}/applications/{child-id} | Assign an application to a specific page. |
GET /pages/{id}/devicegroups | Retrieve all device groups that are assigned to a specific page. |
POST /pages/{id}/devicegroups | Assign and unassign a specific page to device groups. |
DELETE /pages/{id}/devicegroups/{child-id} | Unassign a device group from a specific page. |
POST /pages/{id}/devicegroups/{child-id} | Assign a device group to a specific page. |
GET /pages/{id}/devices | Retrieve all devices that have a specific page assigned. |
POST /pages/{id}/devices | Assign and unassign a specific page to devices. |
DELETE /pages/{id}/devices/{child-id} | Unassign a device from a specific page. |
POST /pages/{id}/devices/{child-id} | Assign a device to a specific page. |
GET /pages/{id}/networks | Retrieve all networks that have a specific page assigned. |
POST /pages/{id}/networks | Assign and unassign a specific page to networks. |
DELETE /pages/{id}/networks/{child-id} | Unassign a network from a specific page. |
POST /pages/{id}/networks/{child-id} | Assign a network to a specific page. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Pairing
This resource enables you to generate a token required to connect a sensor (Discover appliance) to a Command appliance or Reveal(x) 360.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
POST /pairing/token | Generate a token required to connect the sensor to a Command appliance or Reveal(x) 360. |
Record Log
Records are structured flow and transaction information about events on your network.
After you connect the ExtraHop system to a record store, you can generate and send record information to the recordstore, and you can query records to retrieve information about any object on your network. For more information, see Query for records through the REST API.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /records/cursor/{cursor} | Deprecated. Replaced by POST /records/cursor. |
POST /records/cursor | Retrieve records starting at a specified cursor. |
POST /records/search | Perform a record log query. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Operand values in record queries
The operand field in the POST /records/search method specifies the value that a record query attempts to match. You can specify either the value only or both the data type and the value. If you specify only the value, the query will refer to the record format associated with the field parameter to determine the data type of the value.
The following example explicitly specifies the data type and value of the operand:
{ "from": -1000, "filter": { "field" : "senderAddr", "operator": "=", "operand" : { "type" : "ipaddr4", "value": "1.2.3.4" } } }
The following example specifies only the value of the operand:
{ "from": -1000, "filter": { "field" : "senderAddr", "operator": "=", "operand" : "1.2.3.4" } }
You can explicitly specify the following data types in the operand field:
- ipaddr4
- ipaddr6
- device
Note: You must specify the discovery ID of the device in the value field. You can find the discovery ID of a device through the GET /devices method. - application
- string
- number
- boolean
The operand field supports CIDR notation when filtering by IP addresses; the operator field must be set to "=" or "!=".
{ "filter": { "operator": "and", "rules": [ { "field": "method", "operand": "SMB2_READ", "operator": "=" }, { "field": "reqL2Bytes", "operand": "100", "operator": ">" } ] }, "types": [ "~cifs" ], "from": "-30m" }
Supported time units
For most parameters, the default unit for time measurement is milliseconds. However, the following parameters return or accept alternative time units such as minutes and hours:
- Device
- active_from
- active_until
- Device group
- active_from
- active_until
- Metrics
- from
- until
- Record Log
- from
- until
- context_ttl
The following table displays supported time units:
Time unit | Unit suffix |
---|---|
Year | y |
Month | M |
Week | w |
Day | d |
Hour | h |
Minute | m |
Second | s |
Millisecond | ms |
To specify a time unit other than milliseconds for a parameter, append the unit suffix to the value. For example, to request devices active in the last 30 minutes, specify the following parameter value:
GET /api/v1/devices?active_from=-30m
The following example specifies a search for HTTP records created between 1 and 2 hours ago:
{ "from": "-2h", "until": "-1h", "types": ["~http"] }
Report
A report is a PDF file of a dashboard that you can schedule for email delivery to one or more recipients. You can specify how often the report email is delivered and the time interval for dashboard data included in the PDF file.
Important: | You can only schedule reports from an ExtraHop Command appliance. |
Here are some important considerations about scheduled reports:
- You can only create a report for dashboards that you own or have been shared with you. Your ability to create a report is determined by your user privileges. Contact your ExtraHop administrator for help.
- Each report can only link to one dashboard.
- If you created a report for a dashboard that was later deleted or became inaccessible to you, the scheduled email will continue to be sent to recipients. However, the email will not include the PDF file and will instead notify recipients that the dashboard is unavailable to the report owner.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /reports | Retrieve all reports. |
POST /reports | Create a report. |
DELETE /reports/{id} | Delete a specific report. |
GET /reports/{id} | Retrieve a specific report. |
PATCH /reports/{id} | Update a specific report. |
GET /reports/{id}/contents | Retrieve the contents of a specific report. |
PUT /reports/{id}/contents | Replace the contents of a specific report. |
POST /reports/{id}/emailgroups | Change the email group assigned to a specific scheduled report. |
GET /reports/{id}/emailgroups | Retrieve a list of email groups assigned to a specific scheduled report. |
DELETE /reports/{id}emailgroups/{group-id} | Remove an email group from a specific scheduled report. |
POST /reports/{id}emailgroups/{group-id} | Add an email group to a specific scheduled report. |
POST /reports/{id}/queue | Immediately generate and send a specific report. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Running config
The running configuration file is a JSON document that contains core system configuration information for the ExtraHop system.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /runningconfig | Retrieve the current running configuration file. |
PUT /runningconfig | Replace the current running configuration file. Configuration file changes are not automatically saved. |
POST /runningconfig/save | Save the current changes to the running configuration file. |
GET /runningconfig/saved | Retrieve the saved running configuration file. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Software
You can view a list of software that the ExtraHop system has observed on your network.
Operation | Description |
---|---|
GET /software | Retrieve software observed by the ExtraHop system. |
GET /software/{id} | Retrieve software observed by the ExtraHop system by ID. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
SSL decrypt key
This resource enables you to add a decryption key for your network traffic.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /ssldecryptkeys | Retrieve all SSL decryption keys. |
POST /ssldecryptkeys | Create a new SSL decryption key. |
DELETE /ssldecryptkeys/{id} | Remove an SSL key from the ExtraHop system. |
GET /ssldecryptkeys/{id} | Retrieve an SSL PEM and metadata. |
PATCH /ssldecryptkeys/{id} | Update an existing SSL decryption key. |
GET /ssldecryptkeys/{id}/protocols | Retrieve all protocols assigned to an SSL decryption key. |
POST /ssldecryptkeys/{id}/protocols | Create a new protocol for an SSL decryption key. |
DELETE /ssldecryptkeys/{id}/protocols/{child-id} | Delete a protocol from an SSL decryption key. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Support pack
A support pack is a file that contains configuration adjustments provided by ExtraHop Support.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /supportpacks | Retrieve metadata about all support packs. |
POST /supportpacks/execute | Run a new support pack. |
GET /supportpacks/queue/{id} | Check on the status of an in-progress, running support pack. |
GET /supportpacks/{filename} | Downlolad an existing support pack by filename. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Tag
Device tags enable you to associate a device or group of devices by some characteristic.
For example, you might tag all of your HTTP servers or tag all of the devices that are in a common subnet. For more information, see Tag a device through the REST API.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /tags | Retrieve all tags. |
POST /tags | Create a a new tag. |
DELETE /tags/{id} | Delete a specific tag. |
GET /tags/{id} | Retrieve a specific tag. |
PATCH /tags/{id} | Apply updates to a specific tag. |
GET /tags/{id}/devices | Retrieve all devices that are assigned to a specific tag. |
POST /tags/{id}/devices | Assign and unassign a specific tag to devices. |
DELETE /tags/{id}/devices/{child-id} | Unassign a device from a specific tag. |
POST /tags/{id}/devices/{child-id} | Assign a device to a specific tag. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Threat Collection
The Threat Collection resource enables you to upload Structured Threat Information eXpression (STIX) files to threat collections in your Reveal(x) system. STIX files must be obtained from a TAXII server or threat intelligence platform in TAR or TAR.GZ format, and then uploaded to your Reveal(x) system.
Note: | This topic applies only to ExtraHop Reveal(x) Premium and Ultra. |
For information about uploading STIX files through the ExtraHop Web UI, see Upload STIX files through the REST API.
The following table displays all of the operations you can perform on this resource:
Operation | Description | ||
---|---|---|---|
GET /threatcollections | Retrieve all threat collections. | ||
DELETE /threatcollections/{id} | Delete a threat collection. | ||
PUT /threatcollections/{id} | Upload a new threat collection. ExtraHop currently supports STIX versions 1.0 -
1.2.
|
||
GET /threatcollections/{id}/observables | Retrieve the number of STIX observables loaded from a threat collection, such as IP address, hostname, or URI. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Trigger
Triggers are custom scripts that perform an action upon a pre-defined event.
For example, you can write a trigger to record a custom metric every time an HTTP request occurs, or classify traffic for a particular server as an Application server. For more information, see the Trigger API Reference. For supplemental implementation notes about advanced options, see Advanced trigger options.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /triggers | Retrieve all triggers. |
POST /triggers | Create a new trigger. |
POST triggers/externaldata | Sends data to the Trigger API by running the EXTERNAL_DATA event. You can access the data through the ExternalData trigger class. |
DELETE /triggers/{id} | Delete a specific identifier. |
GET /triggers/{id} | Retrieve a specific trigger by unique identifier. |
PATCH /triggers/{id} | Update an existing trigger. |
GET /triggers/{id}/devicegroups | Retrieve all device groups that are assigned to a specific trigger. |
POST /triggers/{id}/devicegroups | Assign and unassign a specific trigger to device groups. |
DELETE /triggers/{id}/devicegroups/{child-id} | Unassign a device group from a specific trigger. |
POST /triggers/{id}/devicegroups/{child-id} | Assign a device group to a specific trigger. |
GET /triggers/{id}/devices | Retrieve all devices that are assigned to a specific trigger. |
POST /triggers/{id}/devices | Assign and unassign a specific trigger to devices. |
DELETE /triggers/{id}/devices/{child-id} | Unassign a device from a specific trigger. |
POST /triggers/{id}/devices/{child-id} | Assign a device to a specific trigger. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Advanced trigger options
Advanced trigger options are configuration options that you can set depending on the system events associated with the trigger. For example, you can configure the number of payload bytes to buffer on HTTP request events.
Advanced options are contained in the hints object of the trigger resource as shown in the following example:
"hints": { "flowClientPortMin": null, "flowClientBytes": 16384, "flowClientPortMax": null, "flowServerBytes": 16384, "flowPayloadTurn": true, "flowServerPortMin": 135, "flowServerPortMax": 49155 }
The following table describes available advanced options and applicable events:
Option | Description | Applicable events |
---|---|---|
"snaplen": number | Specifies the number of bytes to capture per packet, up to a maximum of 65535.
The capture starts with the first byte in the packet. Specify this option only if
the trigger script captures packets. A value of 0 configures the trigger to capture the maximum number of bytes for each packet. |
All events except:
|
"payloadBytes": number | Specifies the minimum number of payload bytes to buffer. |
|
"clipboardBytes": number | Specifies the number of bytes to buffer on a Citrix clipboard transfer. |
|
"cycle": [30sec, 5min, 1hr, 24hr] | Specifies the length of the metric cycle, expressed in seconds. |
|
"metricTypes": string | Specifies the metric type by the raw metric name such as extrahop.device.http_server. |
|
"flowPayloadTurn": boolean | Enables packet capture on each flow turn. Per-turn analysis continuously analyzes communication between two endpoints to extract a single payload data point from the flow. If this option is enabled, any values specified for the flowClientString and flowServerString options are ignored. |
|
"flowClientPortMin": number | Specifies the minimum port number of the client
port range. Valid values are 0 to 65535. A value of 0 specifies matching of any port. |
|
"flowClientPortMax": number | Specifies the maximum port number of the client
port range. Valid values are 0 to 65535. Any value specified for this option is ignored if the value of the flowClientPortMin option is 0. |
|
"flowClientBytes": number | Specifies the number of client bytes to
buffer. The value of this option cannot be set to 0 if the value of the flowServerBytes option is also set to 0. |
|
"flowClientString": string | Specifies the format string of client data to
process. Any value specified for this option is ignored if the flowPayloadTurn option is enabled. |
|
"flowServerPortMin": number | Specifies the minimum port number of the server port range. Valid values are 0 to 65535. A value of 0 specifies matching of any port. |
|
"flowServerPortMax": number | Specifies the maximum port number of the server port range. Valid values are 0 to 65535. Any value specified for this option is ignored if the value of the flowServerPortMin option is 0. |
|
"flowServerBytes": number | Specifies the number of server bytes to buffer. The value of this option cannot be set to 0 if the value of the flowClientBytes option is also set to 0. |
|
"flowServerString": string | Specifies the format string of server data to process. Returns the entire
packet upon a string match. Any value specified for this option is ignored if the flowPayloadTurn option is enabled. |
|
"flowUdpAll": boolean | Enables capture of all UDP datagrams. |
|
"fireClassifyOnExpiration": boolean | Enables running the event upon expiration in order to accumulate metrics for flows that were not classified before expiring. |
|
User
The user resource enables you to create and manage the list of users who have access to the ExtraHop system and the privilege levels for those users.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /users | Retrieve all users. |
POST /users | Create a new user. |
DELETE /users/{username} | Delete a specific user. |
GET /users/{username} | Retrieve a specific user. |
PATCH /users/{username} | Update settings for a specific user. |
GET /users/{username}/apikeys | Retrieve all API keys for a specific user. |
GET /users/{username}/apikeys/{keyid} | Retrieve information about a specific API key and user. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
User group
The user group resource enables you to manage and update groups of users and their dashboard sharing associations.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /usergroups | Retrieve all user groups. |
POST /usergroups | Create a new user group. |
POST /usergroups/refresh | Query LDAP for the most recent user memberships for all remote user groups. |
DELETE /usergroups/{id} | Delete a specific user group. |
GET /usergroups/{id} | Retrieve a specific user group. |
PATCH /usergroups/{id} | Update a specific user group. |
DELETE /usergroups/{id}/associations | Delete all dashboard sharing associations with a specific user group. |
GET /usergroups/{id}/members | Retrieve all members of a specific user group. |
PATCH /usergroups/{id}/members | Assign or unassign users from a user group. |
PUT /usergroups/{id}/members | Replace user group assignments. |
POST /usergroups/{id}/refresh | Query LDAP for the most recent user membership of a specific remote user group. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
VLAN
Virtual LANs are logical groupings of traffic or devices on the network.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
GET /vlans | Retrieve all VLANs |
GET /vlans/{id} | Retrieve a specific VLAN. |
PATCH /vlans/{id} | Update a specific VLAN. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
Whitelist (Watchlist)
To guarantee that an asset, such as an important server, database, or laptop, is guaranteed Advanced Analysis, you can add that device to the whitelist, which is referred to as the watchlist in the Web UI.
Tip: | If you want to add several devices to the whitelist, consider creating a device group and then prioritizing that group for Advanced Analysis. |
Here are important considerations about the whitelist:
- The whitelist only applies to Advanced Analysis.
- The whitelist can contain as many devices as allowed by the Advanced Analysis capacity, which is determined by your license.
- A device stays on the whitelist whether it is inactive or active. A device has to be active for the ExtraHop system to collect Advanced Analysis metrics.
For more information about Advanced Analysis, see Analysis levels.
The following table displays all of the operations you can perform on this resource:
Operation | Description |
---|---|
DELETE /whitelist/device/{id} | Remove a device from the whitelist. |
POST /whitelist/device/{id} | Add a device to the whitelist. |
GET /whitelist/devices | Retrieve all devices that are in the whitelist. |
POST /whitelist/devices | Add or remove devices from the whitelist. |
Implementation information and instructions for each operation are documented in the REST API Explorer. You can click on any operation in the REST API Explorer to view implementation information such as parameters, response class and messages, and JSON model and schema.
ExtraHop REST API examples
The following examples demonstrate common REST API operations.
Upgrade ExtraHop firmware through the REST API
You can automate upgrades to the firmware on your ExtraHop system through the ExtraHop REST API. This guide includes methods for both the cURL command and a Python script.
While the firmware upgrade process is similar across all ExtraHop appliances, some appliances have additional considerations or steps that you must address before you install the firmware in your environment. If you need assistance with your upgrade, contact ExtraHop Support.
All appliances must meet the following requirements:
- The firmware version must be compatible with your appliance model.
- The firmware version on your appliance must be supported by the upgrade version.
- Command appliances must be running firmware that is greater than or equal to their connected appliances.
- Discover appliances must be running firmware that is greater than or equal to Explore and Trace appliances.
If your deployment only includes a Discover appliance, proceed to the cURL or Python upgrade instructions.
If your deployment includes additional appliance types, you must address the following dependencies before proceeding with the upgrade instructions.
If your deployment includes... | Pre-upgrade tasks | Upgrade order |
---|---|---|
Command appliances | Reserve a maintenance window of an hour for Command appliances managing 50,000 devices or more. |
|
Explore appliances | See Upgrading Explore appliances. | |
Trace appliances | None |
Upgrade ExtraHop firmware with cURL
You can upgrade the firmware on an ExtraHop system through the cURL command.
Before you begin
- The cURL tool must be installed on your machine.
- The system firmware .tar file must be downloaded on your machine.
Python script example
The following example Python script upgrades multiple ExtraHop systems by reading URLs, API keys, and firmware file paths from a CSV file.
Each row of the CSV file must contain the following columns in the specified order:
System HTTPS URL | API key | Firmware file path |
The script includes the following configuration variable that you must replace with information from your environment:
SYSTEM_LIST: The relative file path of the CSV file.
Note: | The script does not automatically disable record ingest for Explore appliances. You must manually disable record ingest before running the script for an Explore appliance. |
#!/usr/bin/python3 import os import requests import csv SYSTEM_LIST = 'systems.csv' # Retrieve URLs, API keys, and firmware file paths systems = [] with open(SYSTEM_LIST, 'rt', encoding='ascii') as f: reader = csv.reader(f) for row in reader: system = { 'host': row[0], 'api_key': row[1], 'firmware': row[2] } systems.append(system) # Function that uploads firmware to system def uploadFirmware(host, api_key, firmware): headers = { 'Authorization': 'ExtraHop apikey=%s' % api_key, 'Content-Type': 'application/vnd.extrahop.firmware' } url = host + 'api/v1/extrahop/firmware' file_path = os.path.join(firmware) data = open(file_path, 'rb') r = requests.post(url, data=data, headers=headers) if r.status_code == 201: print('Uploaded firmware to ' + host) return True else: print('Failed to upload firmware to ' + host) print(r.text) return False # Function that upgrades firmware on system def upgradeFirmware(host, api_key): headers = {'Authorization': 'ExtraHop apikey=%s' % api_key} url = host + 'api/v1/extrahop/firmware/latest/upgrade' r = requests.post(url, headers=headers) print(r.status_code) if r.status_code == 202: print('Upgraded firmware on ' + host) return True else: print('Failed to upgrade firmware on ' + host) print(r.text) return False # Upgrade firmware for each system for system in systems: host = system['host'] api_key = system['api_key'] firmware = system['firmware'] upload_success = uploadFirmware(host, api_key, firmware) if upload_success: upgradeFirmware(host, api_key)
Note: | If the script returns an error message that the SSL
certificate verification failed, make sure that a trusted certificate has
been added to your ExtraHop system. Alternatively, you can add the
verify=False option to bypass certificate verification. However, this
method is not secure and is not recommended. The following code sends an HTTP GET
request without certificate
verification:requests.get(url, headers=headers, verify=False) |
Upgrading Explore appliances
Pre-upgrade tasks
Before upgrading an Explore appliance, you must halt record ingest. You can halt record ingest for all of the nodes in a cluster from a single node.
Note: | The message Could not determine ingest status on some nodes and Error might appear on the Cluster Data Management page in the Administration settings of the upgraded nodes until all nodes in the cluster are upgraded. These errors are expected and can be ignored. |
- Open a terminal application.
- Run the following command, where YOUR_KEY is the API for your
user account, and HOSTNAME is the hostname of your Explore
appliance:
curl -X PATCH "https://HOST/api/v1/extrahop/cluster" -H "accept: application/json" -H "Authorization: ExtraHop apikey=YOUR_KEY" -H "Content-Type: application/json" -d "{ \"ingest_enabled\": false}"
Post-upgrade tasks
After you have upgraded all of the nodes in the Explore cluster, enable record ingest.
- Open a terminal application.
- Run the following command, where YOUR_KEY is the API for your
user account, and HOSTNAME is the hostname of your Explore
appliance:
curl -X PATCH "https://HOST/api/v1/extrahop/cluster" -H "accept: application/json" -H "Authorization: ExtraHop apikey=YOUR_KEY" -H "Content-Type: application/json" -d "{ \"ingest_enabled\": false}"
Change a dashboard owner through the REST API
Dashboards are owned by the logged in user that created them. If a user is no longer with your company, you might need to change the owner of the dashboard to maintain that dashboard.
To transfer ownership of a dashboard, you need the dashboard ID and the username of the dashboard owner. You can only view the username of the owner of a dashboard through the REST API.
Before you begin
- You must log in to the ExtraHop system with an account that has unlimited privileges to generate an API key.
- You must have a valid API key to make changes through the REST API and complete the procedures below. (See Generate an API key.)
- Familiarize yourself with the ExtraHop REST API Guide to learn how to navigate the ExtraHop REST API Explorer.
Change the dashboard owner
Tip: | After you click Send Request, the REST API Explorer provides scripts for the operation in Curl, Python 2.7, or Ruby. |
Python script example
The following example script searches for all dashboards owned by the user account marksmith on an ExtraHop system with the hostname extrahop.example.com and then changes the owner for all of those dashboards to the user account paulanderson.
#!/usr/bin/python3 import http.client import json HOST = 'extrahop.example.com' APIKEY = '123456789abcdefghijklmnop' headers = {'Accept': 'application/json', 'Authorization': 'ExtraHop apikey=%s' % APIKEY} conn = http.client.HTTPSConnection(HOST) conn.request('GET', '/api/v1/dashboards', headers=headers) resp = conn.getresponse() parsed_resp = json.loads(resp.read()) for dashboard in parsed_resp: if dashboard['owner'] == 'marksmith': print('Dashboard {id} owned by marksmith.' ' Switching ownership...'.format(id=dashboard['id'])) config = {'owner': 'paulanderson'} conn.request('PATCH', '/api/v1/dashboards/{id}'.format( id=dashboard['id']), json.dumps(config), headers=headers) resp = conn.getresponse() resp.read()
Note: | If the script returns an error message that the SSL
certificate verification failed, make sure that a trusted certificate has
been added to your ExtraHop system. Alternatively, you can add the context
option and send the request over TLSv1.2 to bypass certificate verification. However,
this method is not secure and is not recommended. The following code creates an HTTP
connection over
TLSv1.2:conn = httplib.HTTPSConnection(HOST, context=ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)) |
Extract the device list through the REST API
The ExtraHop REST API enables you to extract the list of devices discovered by the ExtraHop system. By extracting the list with a REST API script, you can export the list in a format that can be read by third-party applications, such as a configuration management database (CMDB). In this topic, we show methods for extracting a list through both the cURL command and a Python script.
Before you begin
- You must log in to the ExtraHop system with an account that has full write privileges to generate an API key.
- You must have a valid API key to retrieve devices through the REST API and complete the procedures below. (See Generate an API key.)
Retrieve the device list with the cURL command
The device list includes all device metadata, such as MAC addresses and device IDs. However, you can filter the list of devices with a JSON parser to extract the specific information you want to export. In this example, the device list is retrieved and then filtered with the jq parser to only extract the display name of each device.
Before you begin
- The cURL tool must be installed on your machine.
- The jq parser must be installed on your machine. For more information, see https://stedolan.github.io/jq/.
curl -s -X GET --header "Accept: application/json" --header "Authorization: ExtraHop apikey=YOUR_KEY" "https://HOSTNAME/api/v1/devices?active_from=1&active_until=0&limit=MAX_DEVICES" | jq -r '.[] | .display_name'
Note: | If the command returns no results, make sure that a trusted certificate has been added to your ExtraHop system. Alternatively, you can add the --insecure option to retrieve the device list from an ExtraHop system without a trusted certificate; however, this method is not secure and is not recommended. |
Tip: | You can append the select(.analysis ==
"LEVEL") option to filter results by analysis level. For
example, the following command limits the results to include only devices
that are selected for advanced
analysis:curl -s -X GET --header "Accept: application/json" --header "Authorization: ExtraHop apikey=YOUR_KEY" "https://HOSTNAME/api/v1/devices?active_from=1&active_until=0&limit=10000000000" | jq -r '.[] | select(.analysis == "advanced") | .display_name' |
Tip: | You can append the select(.critical ==
BOOLEAN) option to filter results by the critical field. For
example, the following command limits the results to include only devices
that are identified as critical by the ExtraHop
system:curl -s -X GET --header "Accept: application/json" --header "Authorization: ExtraHop apikey=YOUR_KEY" "https://HOSTNAME/api/v1/devices?active_from=1&active_until=0&limit=10000000000" | jq -r '.[] | select(.critical == true) | .display_name' |
Tip: | You can append the select(.cloud_instance_name !=
null) option to filter results by the cloud instance name
field. For example, the following command limits the results to include only
devices with a cloud instance
name:curl -s -X GET --header "Accept: application/json" --header "Authorization: ExtraHop apikey=YOUR_KEY" "https://HOSTNAME/api/v1/devices?active_from=1&active_until=0&limit=10000000000" | jq -r '.[] | select(.cloud_instance_name != null) | .cloud_instance_name' |
Python script example
The following example Python script extracts the device list, including all device metadata, and writes the list to a CSV file in the same directory as the script. The script includes the following configuration variables that you must replace with information from your environment:
HOST: The IP address or hostname of the ExtraHop system
APIKEY: The API key
FILENAME: The file that output will be written to
LIMIT: The maximum number of devices to retrieve with each GET request
SAVEL2: Retrieves L2 parent devices. This variable is valid only if you have enabled the ExtraHop system to discover devices by IP address.
ADVANCED_ONLY: Retrieves only devices that are currently under advanced analysis
CRITICAL_ONLY: Retrieves only devices that have been identified as critical by the ExtraHop system
#!/usr/bin/python3 import http.client import json import csv import datetime import ssl import sys HOST = 'extrahop.example.com' APIKEY = '123456789abcdefghijklmnop' FILENAME = 'devices.csv' LIMIT = 1000 SAVEL2 = False ADVANCED_ONLY = False CRITICAL_ONLY = False headers = {} headers['Accept'] = 'application/json' headers['Authorization'] = 'ExtraHop apikey='+APIKEY def getDevices(offset): conn = http.client.HTTPSConnection(HOST) conn.request('GET', '/api/v1/devices?limit=%d&offset=%d&search_type=any'%(LIMIT,offset), headers=headers) resp = conn.getresponse() if resp.status == 200: devices = json.loads(resp.read()) conn.close() return devices else: print("Error retrieving Device list") print(resp.status, resp.reason) resp.read() dTable = None conn.close() sys.exit() continue_search = True offset = 0 dTable = [] while (continue_search): new_devices = getDevices(offset) offset += LIMIT dTable += new_devices if (len(new_devices) > 0): continue_search = True else: continue_search = False if (dTable != None): print (" - Saving %d devices in CSV file" % len(dTable)) with open(FILENAME, 'w') as csvfile: csvwriter = csv.writer(csvfile,dialect='excel') csvwriter.writerow(list(dTable[0].keys())) w = 0 s = 0 for d in dTable: if ADVANCED_ONLY == False or (ADVANCED_ONLY == True and d['analysis'] == 'advanced'): if CRITICAL_ONLY == False or (CRITICAL_ONLY == True and d['critical'] == True): if d['is_l3'] | SAVEL2: w += 1 d['mod_time'] = datetime.datetime.fromtimestamp(d['mod_time']/1000.0) d['user_mod_time'] = datetime.datetime.fromtimestamp(d['user_mod_time']/1000.0) d['discover_time'] = datetime.datetime.fromtimestamp(d['discover_time']/1000.0) csvwriter.writerow(list(d.values())) else: s += 1 else: s += 1 else: s += 1 print(" - Wrote %d devices, skipped %d devices " % (w,s))
Note: | If the script returns an error message that the SSL
certificate verification failed, make sure that a trusted certificate has
been added to your ExtraHop system. Alternatively, you can add the context
option and send the request over TLSv1.2 to bypass certificate verification. However,
this method is not secure and is not recommended. The following code creates an HTTP
connection over
TLSv1.2:conn = httplib.HTTPSConnection(HOST, context=ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)) |
Create a trusted SSL certificate through the REST API
By default, ExtraHop systems include a self-signed SSL certificate. However, you can improve security for your system by adding a trusted certificate signed by a certification authority (CA). You can create the certificate signing request to send to your CA through the ExtraHop REST API. After you receive the signed certificate, you can also add it to your ExtraHop system through the REST API.
Before you begin
- You must log in to the ExtraHop system with an account that has unlimited privileges to generate an API key.
- You must have a valid API key to make changes through the REST API and complete the procedures below. (See Generate an API key.)
- Familiarize yourself with the ExtraHop REST API Guide to learn how to navigate the ExtraHop REST API Explorer.
Note: | You can also perform the procedures in this topic through the Administration settings. For more information, see the following topics: |
Create an SSL certificate signing request
To create a signed SSL certificate, you must send a certificate signing request to a trusted CA.
Next steps
Send the signing request to your CA to create your signed SSL certificate.Important: | The signing request contains escape sequences that represent line
breaks (\n). Replace each instance of \n with a line break before sending the
request to your CA. You can modify the PEM request manually in a text editor or
automatically through a JSON parsing utility, as shown in the following example
command:echo '<json_output>' | python -c 'import sys, json; print json.load(sys.stdin)["pem"]' Replace the <json_output> variable with the entire JSON string returned in the Response Body section. |
Create custom devices through the REST API
You can create custom devices through the REST API that track network traffic across multiple IP addresses and ports. For example, you might want to add a custom device for each branch office. If you create the devices through a script, you can read the list of devices from a CSV file. In this topic, we will demonstrate methods for both the REST API and the ExtraHop REST API Explorer.
Before you begin
- You must log in to the ExtraHop system with an account that has unlimited privileges to generate an API key.
- You must have a valid API key to make changes through the REST API and complete the procedures below. (See Generate an API key.)
- Familiarize yourself with the ExtraHop REST API Guide to learn how to navigate the ExtraHop REST API Explorer.
Create a custom device
You can create a custom device and associate the custom device with a list of IP addresses or CIDR blocks through the POST /customdevices operation.
Python script example
This example python script creates custom devices by reading criteria from a CSV file. Each row of the CSV file must contain the following columns in the specified order:
Name | ID | Description | IP address or CIDR block |
Note: | The script does not accept a header row in the CSV file. There is no limit to the number of columns in the table; each column after the first four specifies an additional IP address for the device. The first four columns are required for each row. |
For example, the following CSV list contains criteria for offices in France, Holland, and California:
France,francehq,The location of our office in France,192.168.0.103,192.168.0.105,192.168.0.101 Holland,hollandhq,The location of our office in Holland,192.168.0.102 California,californiahq,The location of our office in California,192.168.0.104,192.168.0.103
The script includes the following configuration variables that you must replace with information from your environment:
HOST: The IP address or hostname of the ExtraHop system
APIKEY: The API key
CSV_FILE: The path of the CSV file relative to the location of the script file
#!/usr/bin/python3 import json import http.client import csv import os.path HOST = 'extrahop.example.com' APIKEY = '123456789abcdefghijklmnop' CSV_FILE = 'device_list.csv' headers = {'Content-Type': 'application/json', 'Accept': 'application/json', 'Authorization': 'ExtraHop apikey=%s' % APIKEY} def readCSV(): devices = [] with open(CSV_FILE, 'rt', encoding='ascii') as f: reader = csv.reader(f) for row in reader: device = {} ips = [] device['name'] = row.pop(0) device['extrahop_id'] = row.pop(0) device['description'] = row.pop(0) for ip in row: ips.append({"ipaddr": ip}) device['criteria'] = ips devices.append(device) return devices def createDevice(device): conn = http.client.HTTPSConnection(HOST) conn.request('POST', '/api/v1/customdevices', body=json.dumps(device), headers=headers) resp = conn.getresponse() if resp.status != 201: print ("Could not create device: " + device['name']) print (" " + json.loads(resp.read())['error_message']) else: print ("Created custom device: " + device['name']) device_id = os.path.basename(resp.getheader('location')) devices = readCSV() for device in devices: createDevice(device)
Note: | If the script returns an error message that the SSL
certificate verification failed, make sure that a trusted certificate has
been added to your ExtraHop system. Alternatively, you can add the context
option and send the request over TLSv1.2 to bypass certificate verification. However,
this method is not secure and is not recommended. The following code creates an HTTP
connection over
TLSv1.2:conn = httplib.HTTPSConnection(HOST, context=ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)) |
Create and assign a device tag through the REST API
The following Python script creates a device tag and then assigns that tag to all of the devices in a specified subnet.
#!/usr/bin/env python import httplib import urllib import json import sys # Configuration Options: host = "{HOST}" apikey = "{API KEY}" tag_name = "MyTestTag" subnet = "10.20.0.[0-9]+" batch_limit = 100 headers = {'Accept': 'application/json', 'Authorization': "ExtraHop apikey=%s" % apikey} conn = httplib.HTTPSConnection(host) def execute_req(method, path, expected_code, failure_message, body=None): """ Returns the body of a successful request, otherwise prints error and terminates """ conn.request(method, "/api/v1" + path, headers=headers, body=body) resp = conn.getresponse() if resp.status is not expected_code: print(failure_message) print(resp.read()) sys.exit(1) return resp def execute_get(path, expected_code, failure_message): resp = execute_req("GET", path, expected_code, failure_message) return json.loads(resp.read()) def execute_create(path, body, expected_code, failure_message): """Returns ID of newly created resource""" resp = execute_req("POST", path, expected_code, failure_message, body) resp.read() # drain the response return int(resp.getheader("location").split("/")[-1]) # First, search for the specified tag, by name resp = execute_get("/tags", 200, "Unable to retrieve tags from ExtraHop") tags = [tag for tag in resp if tag["name"] == tag_name] if not tags: # tag is not found, create it body = json.dumps({"name": tag_name}) tag_id = execute_create('/tags', body, 201, "Unable to create tag") else: tag_id = tags[0]["id"] query_params = {'limit': batch_limit, 'search_type': 'ip address', 'value': subnet} query_string = urllib.urlencode(query_params) # Paginate device results, building up a list of all devices to assign device_ids = [] offset = 0 while True: path = "/devices?" + query_string + ("&offset=%d" % offset) resp = execute_get(path, 200, "Unable to retrieve devices") if not resp: break device_ids += [device["id"] for device in resp] offset += batch_limit # Perform the assignments resp = execute_req("POST", "/tags/%d/devices" % tag_id, 204, "Unable to perform assignments", body=json.dumps({"assign": device_ids})) resp.read() # drain the response # Check that assignments were successful resp = execute_get("/tags/%d/devices" % tag_id, 200, "Unable to retrieve tag assignments") assigned_device_ids = [device["id"] for device in resp] successful = set(device_ids).issubset(set(assigned_device_ids)) if successful: print("%d devices assigned to tag" % len(device_ids)) else: print("Unable to assign all devices to tag")
Query for metrics about a specific device through the REST API
The following Python script queries for metrics from an HTTP client device with the ID 9363 and prints the response.
import httplib headers = {'Content-Type': 'application/json', 'Accept': 'application/json', 'Authorization': 'ExtraHop apikey={API KEY}' body = r"""{ "cycle": "auto", "from": -1800000, "until": 0, "metric_category": "http_client", "metric_specs": [ { "name": "req" } ], "object_ids": [ 9363 ], "object_type": "device" }""" conn = httplib.HTTPSConnection('{HOST}') conn.request('POST', '/api/v1/metrics', headers=headers, body=body) resp = conn.getresponse() print resp.status, resp.reason print resp.read()
The following response shows entries for the device with ID 9363:
{ "date": "Thu, 19 Nov 2015 23:20:07 GMT", "via": "1.1 localhost", "server": "Apache", "vary": "Accept-Encoding", "content-type": "application/json; charset=utf-8", "cache-control": "private, max-age=0", "connection": "Keep-Alive", "content-encoding": "gzip", "keep-alive": "timeout=45, max=44", "content-length": "277" } { "stats": [ { "oid": 9363, "time": 1447973460000, "duration": 30000, "values": [ 2 ] }, { "oid": 9363, "time": 1447973490000, "duration": 30000, "values": [ 0 ] }, { "oid": 9363, "time": 1447973520000, "duration": 30000, "values": [ 1 ] }, { "oid": 9363, "time": 1447973550000, "duration": 30000, "values": [ 2 ] }
Create, retrieve, and delete an object through the REST API
This example shows how you can create and successfully retrieve information about a device tag. Then, after the device tags are deleted, the example shows how an attempt to retrieve information subsequently fails.
The following example shows how to create a device tag called my_test_tag.
curl -i -X POST --header "Content-Type: application/json" \ --header "Accept: application/json" \ --header "Authorization: ExtraHop apikey={API KEY}" \ -d "{ \"name\": \"my_test_tag\" }" "https://{HOST}/api/v1/tags"
A 201 status returns upon success with the following response headers, which display that the tag was created, and provides the device tag location and ID of /api/v1/tags/1.
{ "date": "Wed, 18 Nov 2015 20:24:13 GMT", "via": "1.1 localhost", "server": "Apache", "content-type": "text/plain; charset=utf-8", "location": "/api/v1/tags/1", "cache-control": "private, max-age=0", "connection": "Keep-Alive", "keep-alive": "timeout=45, max=88", "content-length": "0" }
Next, the ID (1) is added to the following GET request, which returns a 200 status upon success and the JSON representation of the retrieved tag:
curl -i -X GET --header "Accept: application/json" \ --header "Authorization: ExtraHop apikey={API KEY}" \ "https://{HOST}/api/v1/tags/1" { "mod_time": 1447878253953, "id": 1, "name": "my_test_tag" }
Next, the following example shows a DELETE request to remove the device tag from the system, which returns a 204 status upon success:
curl -i -X DELETE --header "Accept: application/json" \ --header "Authorization: ExtraHop apikey={API KEY}" \ "https://{HOST}/api/v1/tags/1"
Finally, when another GET request is sent for that deleted device tag, the operation fails, and a 404 status is returned upon failure, indicating that the tag is no longer available.
curl -i -X GET --header "Accept: application/json" \ --header "Authorization: ExtraHop apikey={API KEY}" \ "https://{HOST}/api/v1/tags/1"
Query the record log
The following request body queries the record log to retrieve 100 HTTP records where the method is GET and the status code is 404.
{ "filter": { "operator": "and", "rules": [ { "field": "method", "operand": "GET", "operator": "=" }, { "field": "statusCode", "operand": "404", "operator": "=" } ] }, "from": -900000, "limit": 100, "types": [ "~http" ] }
Thank you for your feedback. Can we contact you to ask follow up questions?