Skip to main content

About NinjaOne

NinjaOne (formerly NinjaRMM) is a remote monitoring and management (RMM) platform for managing endpoints, patching, alerts, and IT documentation. Serval connects to your NinjaOne tenant using an OAuth 2.0 client credentials app that you create in the NinjaOne admin console, and gives Serval workflows typed access to the full NinjaOne Public API v2 - more than 300 endpoints. The integration is region-aware: you pick your NinjaOne cloud instance (US, US2, EU, CA, or Oceania) when you connect, and all traffic goes to that instance. There are no prebuilt installable workflows; this is a pure API integration with four built-in health checks. Authentication: OAuth 2.0 client credentials, via an “API Services (machine-to-machine)” client app created in NinjaOne. Data sync: On-demand only. There is no background or scheduled sync - workflow runs call the NinjaOne API live using your stored credentials, and four built-in health checks verify the connection.

What the NinjaOne integration enables

CapabilityDescription
Device managementList, search, and inspect managed devices; reboot devices, set owners, approve or reject devices, schedule maintenance, and decommission devices.
Patch managementScan for and apply OS and third-party software patches on a device, and report on patch installs.
Scripting and automationList automation scripts, look up per-device scripting options, run scripts on a device, and configure and control Windows services.
Alerts and activitiesList and reset alerts, and read activity logs globally or per device.
Organizations and locationsCreate and manage organizations, locations, and policies; generate agent installers; read org-level devices, end users, and custom fields.
Reporting queriesFleet-wide reports covering antivirus status and threats, device health, software inventory, OS and software patches, logged-on users, disks, volumes, processors, RAID, network interfaces, backup usage, and Windows services.
TicketingCreate and update NinjaOne tickets, add comments, read log entries, and manage ticket forms, boards, statuses, and attributes.
Knowledge base and IT documentationManage knowledge base articles and folders, document templates, organization documents, and checklists.
Custom fieldsRead and update custom fields at the device, organization, and location level, including bulk operations and attachment handling.
Users and rolesList users, end users, and technicians; manage user roles and role membership.
ITAM and software licensesManage unmanaged devices, asset relationships, tags, software products, and software license records with assignments.
Backup, billing, vulnerabilities, and webhooksRead backup jobs and integrity checks, manage billing entities such as invoices, products, and agreements, manage vulnerability scan groups, and configure the account webhook.
Anything defined in the NinjaOne API can be accessed through Serval.

Get your credentials

Serval authenticates with a machine-to-machine API client app in NinjaOne. You will need the app’s Client ID, its Client Secret, and the region your NinjaOne tenant is hosted in. NinjaOne’s official guide is How to Set Up API OAuth Token; the short version follows.
1

Open the API settings

In NinjaOne, go to Administration > Apps > API.
2

Add a client app

Open the Client App IDs tab and click Add.
3

Choose the machine-to-machine platform

Set Application platform to API Services (machine-to-machine). No redirect URI is needed for this platform type.
4

Name the app

Give the app a recognizable name (for example “Serval”). The name appears in NinjaOne’s OAuth token management area.
5

Select scopes

Select the Monitoring and Management scopes. Serval requests exactly these two scopes, so both must be allowed on the app. The Control scope is not requested by Serval and can be left off.
6

Set the grant type

Ensure Client Credentials is the allowed grant type.
7

Save and copy the credentials

Click Save, then copy the generated Client ID and Client Secret.
8

Note your region

Check which NinjaOne cloud instance hosts your tenant - it is the domain in your browser: app.ninjarmm.com, us2.ninjarmm.com, eu.ninjarmm.com, ca.ninjarmm.com, or oc.ninjarmm.com. You will pick the matching API Region in Serval.
The Client Secret is shown only once, when the app is created. If you lose it, regenerate it in NinjaOne.
For more detail on scopes and grant types, see NinjaOne’s API OAuth Token Configuration reference.

Connect in Serval

All three fields on the connect form are required - each label ends with an asterisk.
1

Open the NinjaOne connection form in Serval

Start a new NinjaOne connection from Serval’s integrations area.
2

Select the API Region

API Region is a dropdown, pre-filled with “US (app.ninjarmm.com)”. The options are “US (app.ninjarmm.com)”, “US2 (us2.ninjarmm.com)”, “EU (eu.ninjarmm.com)”, “CA (ca.ninjarmm.com)”, and “Oceania (oc.ninjarmm.com)”. The text beneath the field reads “Select the NinjaOne region your tenant is hosted in” - pick the one matching the domain you noted in NinjaOne.
3

Enter the Client ID

Client ID is a plain text field described as “Your NinjaOne API application Client ID”. Paste the Client ID from your NinjaOne client app.
4

Enter the Client Secret

Client Secret is a password field described as “Your NinjaOne API application Client Secret”. Paste the complete Client Secret you copied when creating the app.
5

Connect

Click Connect NinjaOne (the button reads Submit if you are using the configure dialog). Serval then automatically runs the connection’s health checks - any checks you have disabled are skipped - see the next section.
When you edit an existing NinjaOne connection, the saved Client Secret appears masked: a row of bullet characters with the last 4 characters visible. Use the edit control next to it (the pencil icon on the connection settings page, or the Replace button in the configure dialog) to enter a new value. Any time you save changes to the connection - including unrelated edits or a credential rotation - re-enter the complete Client Secret, and confirm the API Region and Client ID are still correct before saving. Do not clear pre-filled fields you intend to keep, and do not assume the masked value carries over on its own.

Verifying the connection

Serval runs four health checks automatically after a successful connect (skipping any you have disabled), and you can re-run them on demand from the connection’s health check section.
  • Test NinjaOne Connection - verifies the stored credentials can authenticate against the NinjaOne API. Success: “Successfully authenticated with NinjaOne”. Failure: “Unable to connect to NinjaOne. Please verify your Client ID, Client Secret, API region, and OAuth scopes are correct.”
  • List NinjaOne Organizations - confirms the integration can list organizations (requires the “monitoring” scope). Success: “Successfully listed organizations from NinjaOne (sample size: [number])”. Failure: “Unable to list organizations from NinjaOne. Please verify the API credentials have the ‘monitoring’ scope.”
  • List NinjaOne Devices - confirms the integration can list managed devices (requires the “monitoring” scope). Success: “Successfully listed devices from NinjaOne (sample size: [number])”. Failure: “Unable to list devices from NinjaOne. Please verify the API credentials have the ‘monitoring’ scope.”
  • List NinjaOne Users - confirms the integration can list users (requires the “monitoring” scope). Success: “Successfully listed users from NinjaOne (sample size: [number])”. Failure: “Unable to list users from NinjaOne. Please verify the API credentials have the ‘monitoring’ scope.”
All four health checks are read operations, so they exercise only the Monitoring scope. Write actions in workflows (creating tickets, applying patches, updating custom fields) also rely on the Management scope, which Serval requests at connect time - if reads work but writes are denied, check the app’s scopes in NinjaOne.

Gotchas and troubleshooting

The selected region is used for both sign-in and all API traffic, and Serval only talks to the five official NinjaOne hosts (app.ninjarmm.com, us2.ninjarmm.com, eu.ninjarmm.com, ca.ninjarmm.com, and oc.ninjarmm.com). If the region does not match the cloud instance hosting your tenant, authentication fails and the “Test NinjaOne Connection” health check reports it. The region also becomes the connection’s instance label in Serval, so picking the right one keeps the connection easy to identify.
The connect form only asks for API Region, Client ID, and Client Secret. Serval always requests the Monitoring and Management scopes, so your NinjaOne client app must allow both or the connection fails to authenticate. The Control scope (used by NinjaOne for remote-access features) is never requested by Serval, and none of the API operations Serval exposes require it.
Whenever you save changes to an existing NinjaOne connection, replace the masked Client Secret with the full secret again, even if you are only changing something else. Also verify the API Region and Client ID before saving, and never clear a pre-filled field you mean to keep. If a connection stops working right after an edit, re-enter the complete credentials and save again.
Serval uses the OAuth client credentials grant only. NinjaOne client apps created with the Authorization Code or Implicit grant platforms will not work, and no redirect URI is involved. Remember that NinjaOne shows the Client Secret only once at creation time - if it was not saved, regenerate it.
Every health check is a read that needs only the Monitoring scope - none of them exercise writes. If ticket creation, patch deployment, or custom field updates fail in workflows while all four checks are green, confirm the NinjaOne client app still allows the Management scope under Administration > Apps > API, then re-save the connection in Serval (re-entering the complete Client Secret) so it authenticates fresh.

Need help? Contact support@serval.com for assistance with your NinjaOne integration.