Skip to main content

Nexthink

Visualize Nexthink-managed endpoints, the users and installed applications on them, and the alerts raised by Nexthink monitors. This integration ingests data through pre-created NQL queries via the Nexthink Infinity API, mapping devices to their users, installed software, and alerts so you can monitor your endpoint estate through queries and alerts in JupiterOne.

Installation

info

Before configuring the integration you will need:

  • Nexthink API credentials — an OAuth 2.0 client (Client ID and Client Secret) with the service:integration scope. In your Nexthink tenant, go to Administration → Integrations → API credentials, create a new API client, and note the Client ID and Client Secret. See Nexthink's authentication documentation for more information.

  • Your tenant ID and region — the tenant ID is the subdomain of your Nexthink URL (e.g. acme from acme.api.us.nexthink.cloud). The region is one of us, eu, pac, or meta.

  • Pre-created NQL queries — Nexthink exposes no resource-level REST endpoints; all data is retrieved through pre-created NQL queries that you save in your tenant. Create one query per data type you want to ingest before running the integration (see NQL query setup below).

To install the Nexthink integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Nexthink. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Nexthink account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • Your Nexthink Client ID and Client Secret used to authenticate with the Nexthink Infinity API.

  • Your Tenant ID and Region.

  • The NQL Query IDs for each data type you want to ingest (see below). Each query ID is optional — leave one blank to skip ingesting that data type.

NQL query setup

Because Nexthink has no resource-level REST endpoints, the integration retrieves data by running NQL queries that you pre-create in your tenant under Administration → NQL API queries. Each query is assigned an ID that must start with # and contain only lowercase letters, digits, and underscores (e.g. #j1_devices). Copy each ID into the matching field in the integration configuration.

The recommended queries below select the fields the integration maps. You can adjust them as long as the listed fields are present.

Devices — suggested ID #j1_devices

devices
| list device.uid, device.name, device.collector.uid,
device.operating_system.platform, device.operating_system.name,
device.operating_system.build, device.hardware.manufacturer,
device.hardware.model, device.hardware.chassis_serial_number,
device.hardware.machine_serial_number, device.hardware.type,
device.license_type, device.last_seen, device.first_seen,
device.entity, device.sid, device.connectivity.last_local_ip

Users — suggested ID #j1_users

users
| list user.uid, user.name, user.upn, user.sid, user.type,
user.last_seen, user.first_seen, user.entity,
user.ad.email_address, user.ad.full_name, user.ad.department

The user.ad.* fields (email, full name, department) are only populated if you have the Entra ID (Azure AD) connector configured in Nexthink.

Packages — suggested ID #j1_packages

package.installed_packages
| list device.uid, package.uid, package.name,
package.version, package.publisher, package.type, package.platform

Alerts — suggested ID #j1_alerts

alerts
| list alert.uid, alert.status, alert.trigger_time,
alert.recovery_time, alert.trigger_value, alert.duration,
monitor.name, monitor.nql_id, monitor.priority,
monitor.type, monitor.origin,
device.uid, user.uid

Click Create once all values are provided to finalize the integration.

note

Nexthink controls data volume through the NQL query itself. Large tenants may return very large result sets, so add where filters or a | limit clause to your queries to bound the volume. The asynchronous export also enforces a license-based maximum number of results; when that maximum is reached the results are truncated and the integration logs a warning so the incomplete ingestion is visible.

Next steps

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.