> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cantina.security/llms.txt
> Use this file to discover all available pages before exploring further.

# NinjaOne

> Connect NinjaOne to Clarion to triage RMM conditions, let agents look up device health, patching, software and access during an investigation, and optionally run scripts or restart services with human approval.

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.

<Note>
  **Estimated time:** 5 minutes. You will need **NinjaOne system administrator** access to create the app.
</Note>

## Prerequisites

* Access to your NinjaOne instance as a **system administrator**
* A **Clarion workspace** with the NinjaOne integration open
* For the OAuth method, a NinjaOne technician account the connection will run as

***

## Step 1 — Choose an authentication method

Clarion connects to NinjaOne one of two ways. Pick before you create the app, because the **Application platform** you choose in NinjaOne decides which grant types the app can use — and a machine-to-machine app cannot run scripts no matter what it is granted.

| | API services (machine to machine) | Web (PHP, Java, .Net Core, etc.) |
| - | - | - |
| Who is involved | Nobody — it is an application | A NinjaOne technician authorizes once |
| Runs as | An application | That technician |
| Reads (devices, patching, conditions…) | Yes | Yes |
| Service control, patch jobs | Yes | Yes |
| **Run a script** | **No** — NinjaOne refuses | Yes |
| Keeps working if that person leaves | n/a | No — authorize again as someone else |

**API services** is the default and what every existing connection uses. Choose **Web application** if you want agents to run scripts from your automation library.

<Note>
  NinjaOne checks a script run against a technician's device and script-category permissions, and an application has none, so it answers `user_context_required`. Adding scopes does not change this: NinjaOne's machine-to-machine documentation says Management covers running scripts, but the API enforces a user context regardless.
</Note>

***

## Step 2 — Create the 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** first — NinjaOne pre-fills the rest from it:

   | Method | Application platform | Allowed grant types | Redirect URIs |
   | - | - | - | - |
   | API services | **API Services (machine to machine)** | **Client credentials** | not used |
   | Web application | **Web (PHP, Java, .Net Core, etc.)** | **Authorization code**, **Client credentials** and **Refresh token** | the **Callback URL** Clarion shows |

4. Under **Scopes**, select **Monitoring** and **Management**. Management is only needed for [device actions](#step-6-optional-device-actions), but it costs nothing to grant now and adding it later means editing the app. Clarion never asks for **Control**, so it cannot start remote sessions either way.

5. Under **Allowed grant types**, select the ones for your method from the table above.

6. On the Web platform, **Redirect URIs** is required: paste the **Callback URL** from Clarion's connect form exactly as shown.

7. Save, then copy the **Client ID** and **Client Secret**.

<Warning>
  Copy the client secret immediately — NinjaOne shows it only once. If you lose it, create a new app rather than reusing an old one.
</Warning>

***

## Step 3 — Connect in Clarion

1. In Clarion, open the **NinjaOne integration** from your workspace settings.
2. Choose the **Authentication** method you created the app for.
3. 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.
4. Paste the **Client ID** and **Client Secret**.
5. **API services:** click **Connect**. Clarion verifies the credentials against NinjaOne before saving them, so a mistyped secret or the wrong region is reported straight away.
   **Web application:** click **Authorize with NinjaOne** and sign in as the technician the connection should run as. The connection is not live until that finishes.

You can change methods later from the connected view — it is the same form, and your organization scope, ingestion mode and device-action setting are kept.

***

## Step 4 — 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 5 — 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.

<Warning>
  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.
</Warning>

Switching back to polling deregisters the webhook in NinjaOne automatically.

***

## Step 6 (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. Make sure your NinjaOne app has the **Management** scope (**Administration → Apps → API**).
2. In Clarion, open the NinjaOne integration and turn on **Allow scripts, service control and patch jobs** under **Device actions**.

Clarion checks that the app actually grants Management before storing the setting, so an app still limited to Monitoring is rejected there and then rather than failing later during an investigation.

Running **scripts** additionally requires the **Web application (OAuth)** method from Step 1 — service control and patch jobs work either way. On that method, the technician who authorized needs permission for the automation categories of the scripts your agents run; if a script belongs to several categories, they need all of them.

<Warning>
  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.
</Warning>

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.

***

## Step 7 (optional) — The ClarionBot script

Device actions let an agent run a script that is **already** in your automation library. ClarionBot is the other half: one library entry that lets an agent run a PowerShell command it composed for the investigation — read a log file, check a registry value, run a diagnostic cmdlet — and get the output back in the same call.

It is one script, created once per NinjaOne tenant. Clarion looks it up by name every time it runs, so the ID NinjaOne assigns it can differ between your environments and nothing has to be configured in Clarion.

It builds on the two steps above and needs both: **Device actions** turned on ([Step 6](#step-6-optional-device-actions)), and the **Web application (OAuth)** method ([Step 1](#step-1-choose-an-authentication-method)), because NinjaOne refuses every script run that is not made on behalf of a technician.

<Warning>
  This lets an agent run PowerShell it wrote itself, as LocalSystem, on any Windows device inside this workspace's organization scope. That is a wider capability than the rest of Device actions: the other tools run scripts *you* reviewed and put in the library.

  Every call still requires a person to approve that specific command, and the approval shows the exact command before you accept it — read it. Leave this script uncreated for workspaces where reviewed scripts are enough.
</Warning>

### Create the script

1. In NinjaOne, go to **Administration → Library → Automation**.

2. Click **Add → New Script**.

3. Paste this as the script body:

   ```powershell theme={null}
   Param(
       [Parameter(Mandatory=$true)]
       [string]$code
   )

   $bytes = [System.Convert]::FromBase64String($code)
   $DecodedCommand = [System.Text.Encoding]::UTF8.GetString($bytes)

   # Execute Script Content
   iex $DecodedCommand

   Write-Host "Ephemeral Agent started"
   ```

4. Set the script's properties:

   | Field | Value |
   | - | - |
   | Name | **ClarionBot** |
   | Language | **PowerShell** |
   | Operating System | **Windows** |
   | Architecture | **All** |
   | Run As | **System** |

   The name has to be exactly `ClarionBot` — that is what Clarion resolves. Capitalisation and surrounding spaces do not matter, but a second script by the same name does: Clarion refuses to guess between them.

5. Before leaving the script, add the **script variable** the parameter needs:
   1. Click **+ Add** next to **Script Variables**.
   2. Select the **String/Text** type.
   3. Enter `Code` as the variable name.
   4. Click **Add**.

6. Save the script.

You do not need to note the script ID, and you do not need to configure anything on the endpoints. Running as System needs nothing beyond the NinjaOne agent already being installed, and no credential has to exist in NinjaOne's credential store.

### Check it works

Ask an agent to run `whoami` on a Windows device and approve the call. A working setup answers `nt authority\system` followed by `Ephemeral Agent started`.

***

## 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 control a Windows service and start a patch scan or apply — and, on the OAuth method, run a script — each behind a human approval. With the [ClarionBot script](#step-7-optional-the-clarionbot-script) in your library they can also run a PowerShell command they composed for the investigation and read its output.

***

## 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 app in **Administration → Apps → API** and add the Monitoring scope.

**"This NinjaOne app does not grant the management scope."** You tried to enable Device actions with an app limited to Monitoring. Add the Management scope in **Administration → Apps → API**, then connect again. Reads are unaffected in the meantime.

**"NinjaOne refused this action because it has to run as a NinjaOne user."** The workspace is on the **API services** method, which has no user behind it. Reconnect with the **Web application (OAuth)** method. Adding scopes will not fix this — NinjaOne's machine-to-machine documentation says Management covers running scripts, but the API enforces a user context regardless.

**"NinjaOne no longer accepts Clarion's authorization."** On the OAuth method: the grant was revoked, the app was deleted, or its secret was rotated. Reconnect and authorize again. Reads stop too, since everything runs under that grant.

**"NinjaOne did not return a refresh token."** The Web app is missing the **Refresh Token** grant type. Add it in **Administration → Apps → API** and authorize again.

**"This NinjaOne tenant has no automation script named ClarionBot."** The wrapper script has not been created, or it is named something else. See [Step 7](#step-7-optional-the-clarionbot-script). Clarion matches the name ignoring case and surrounding spaces, but nothing else — `Clarion Bot` and `ClarionBot-v2` will not resolve.

**"This NinjaOne tenant has N automation scripts named ClarionBot."** Two library entries share the name, and picking one would be a guess. Rename or delete the duplicates so exactly one remains.

**"Unable to retrieved credential information."** NinjaOne reports this on a run when it is asked to use a credential role the tenant has not defined. Clarion always runs ClarionBot as System and never names a role, so this points at a different automation — check what else ran on the device around the same time.

**A run returns `running` rather than output.** The command is still executing on the device; it is not a failure and re-running it would execute it twice. The agent can read the device's activity log afterwards to pick up the result. Raise the wait if the commands you expect routinely take longer.

**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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.