Skip to main content
This guide walks you through connecting your NinjaOne tenant to Clarion. Once connected, Clarion turns NinjaOne’s triggered conditions into issues your agents can triage, and gives those agents read-only lookups across every managed device.
Estimated time: 5 minutes. You will need NinjaOne system administrator access to create the API client app.

​
Prerequisites

  • Access to your NinjaOne instance as a system administrator
  • A Clarion workspace with the NinjaOne integration open

​
Step 1 — Create an API client app in NinjaOne

  1. In NinjaOne, go to Administration → Apps → API.
  2. Open the Client app IDs tab and click Add.
  3. Set Application platform to API Services (machine to machine).
  4. Under Allowed grant types, select Client Credentials.
  5. Under Scopes, select Monitoring.
  6. Save, then copy the Client ID and Client Secret.
Copy the client secret immediately — NinjaOne shows it only once. If you lose it, create a new client app rather than reusing an old one.
Monitoring is read-only and is all Clarion needs. Add Management as well only if you want agents to be able to run scripts and control Windows services — see Device actions below. Clarion never asks for Control, so it cannot start remote sessions either way. Reads and device actions use separate tokens, so adding Management does not change how anything is read, and leaving it off cannot break reads.

​
Step 2 — Connect in Clarion

  1. In Clarion, open the NinjaOne integration from your workspace settings.
  2. Choose your Region. This is the NinjaOne instance you sign in to — for example app.ninjarmm.com for the United States or eu.ninjarmm.com for Europe. Credentials issued in one region will not work against another.
  3. Paste the Client ID and Client Secret.
  4. Click Connect.
Clarion verifies the credentials against NinjaOne before saving them, so a mistyped secret or the wrong region is reported straight away rather than failing quietly later.

​
Step 3 — Add a NinjaOne monitor

The integration on its own gives your agents device lookups. To turn NinjaOne’s triggered conditions into Clarion issues, add a NinjaOne monitor:
  1. Open the agent you want to receive NinjaOne conditions.
  2. Add a NinjaOne monitor.
  3. Optionally narrow what gets ingested:
    • Severity filter — leave everything selected to ingest every severity. Unchecked severities are dropped before an issue is created.
    • Organizations — a comma-separated list of NinjaOne organization IDs. Leave it empty to cover the whole tenant.
Only triggered conditions become issues. The rest of NinjaOne’s activity log — job progress, policy edits, condition resets — is not turned into issues, though your agents can still read it per device.

​
Step 4 — Choose how conditions reach Clarion

Under Ingestion on the integration page you can pick one of two delivery methods. Polling (default). Clarion checks NinjaOne every minute for new triggered conditions. Nothing to configure, and it works on any tenant. Webhook. NinjaOne pushes each triggered condition to Clarion the moment it fires, which removes the polling delay. Turning the switch on registers the webhook in NinjaOne for you.
NinjaOne supports one webhook destination per API client app. Enabling the webhook for a second monitor repoints NinjaOne at that monitor rather than adding a second delivery.Two things can stop the webhook from being registered:
  • The API client app was not created by a system administrator.
  • The same client app already has a PSA channel configured, such as ConnectWise or Autotask.
In either case, either create a separate API client app for Clarion, or stay on polling. Polling delivers the same conditions with the same filters — only the delay differs.
Switching back to polling deregisters the webhook in NinjaOne automatically.

​
Step 5 (optional) — Device actions

By default agents can only read from NinjaOne. Device actions lets them also change something on a machine: run a script from your automation library, start/stop/restart a Windows service, or start a patch scan or apply. To enable it:
  1. In NinjaOne, edit your API client app under Administration → Apps → API and add the Management scope.
  2. In Clarion, open the NinjaOne integration and turn on Allow scripts and service control under Device actions.
Clarion checks that NinjaOne actually issues a Management token before storing the setting, so a client app still limited to Monitoring is rejected there and then rather than failing later during an investigation.
This lets an agent execute code from your script library on a customer’s endpoint. Every such call still requires a person to approve that specific call, and each one is recorded against the issue — but the scripts themselves are yours, and the agent can run any of them on any device inside this workspace’s organization scope.It also covers patch apply, which installs patches and can reboot a machine. Read the approval prompt before accepting one against a server.Review what is in your automation library before turning this on, and leave it off for workspaces that only need investigation.
NinjaOne accepts these without reporting what they did, so agents confirm the outcome afterwards by reading the device’s activity log — a submitted action is never reported as a completed one. Turning the switch back off takes effect immediately and never calls NinjaOne, so it works even when NinjaOne is unreachable.

​
What your agents can do

With NinjaOne connected, agents triaging any issue — not only NinjaOne ones — can look up:
  • Devices — search by hostname, or list with a NinjaOne device filter
  • Device detail — OS, organization and location, approval status, and last check-in
  • System — manufacturer, model, serial, memory, OS build, last boot, pending reboot, CPUs, and your custom fields
  • Health — NinjaOne’s own health rollup for a device
  • Antivirus — installed product, its reported state, definition freshness, and detected threats
  • Patching — applicable OS and software patches and their install state
  • Software — installed applications and versions
  • Services — Windows service state and start type, filterable by service name
  • Storage — disks, volumes, free space, and SMART status
  • Network — interfaces and the last logged-on user
  • Users and access — which end users are entitled to a device, and who last logged on
  • Tickets — service and access requests from your NinjaOne ticketing boards, with their comment history
  • Conditions — what is currently firing, on one device or across the tenant
  • Fleet reports — any of NinjaOne’s inventory reports run across every device in scope, which is how an agent tells a single failing host from an estate-wide problem
  • Jobs and activity — what is running on a device now, and what ran recently
  • Vulnerability scan imports — which third-party vulnerability feeds this tenant imports, and whether the last import succeeded. These are import pipelines rather than per-device findings, which NinjaOne’s API does not expose; a workspace restricted to specific organizations sees none of them, because a scan group names no organization.
All of the above are read-only. If you enabled Device actions, agents can additionally run a script, control a Windows service, and start a patch scan or apply — each behind a human approval.

​
Troubleshooting

“NinjaOne rejected these credentials.” The client ID or secret is wrong, or the region does not match the instance you sign in to. Check the region first — it is the most common cause. “These credentials were accepted but lack the monitoring scope.” Edit the client app in Administration → Apps → API and add the Monitoring scope. “This NinjaOne API client app does not grant the management scope.” You tried to enable Device actions with a client app limited to Monitoring. Add the Management scope to the client app in Administration → Apps → API, then try again. Reads are unaffected in the meantime. No issues appearing. Confirm a NinjaOne monitor exists and is attached to an agent, that the condition you expect is actually firing in NinjaOne, and that its severity is not excluded by the monitor’s severity filter. Conditions from the wrong customers. Set the monitor’s Organizations filter to the organization IDs this workspace should cover.