Skip to main content
The NinjaOne integration is Regentra’s RMM-class device-source. One MSP credential per NinjaOne regional tenant feeds two outputs simultaneously:
  • PSA asset sync — every NinjaOne customer organization you map to a PSA company contributes its approved devices to that company’s Asset list in the PSA module. Updated every 4 hours.
  • Compliance evidence sweep — for each mapped customer that has been promoted to a Regentra compliance workspace, five aggregate-only signals refresh every 6 hours: disk encryption posture, antivirus posture, patch SLA, backup activity, and device inventory. Each signal maps to multiple Internal Controls in the CCF catalog.
NinjaOne customers who are NOT compliance-promoted still flow into PSA assets; they just don’t generate evidence signals. This lets an MSP sell compliance to a subset of their book without contaminating the compliance-enabled customers’ evidence with other customers’ device counts.

​
What you give Regentra

A single OAuth scope is required: monitoring (read-only). Regentra deliberately does not request management (write access) or control (remote-control sessions) — both are out of scope for compliance evidence collection.

​
Required permissions in NinjaOne

When you create the API Client: System Administrator role is required to create the API client itself. The client, once created, has no role of its own — it sees whatever the monitoring scope grants on that tenant.

​
Setup

The full step-by-step lives inline on the NinjaOne card in Settings → Integrations. The short version:
1

Pick your region first

NinjaOne hard-partitions OAuth credentials by region (US / US-East 2 / EU / CA / OC). Pick the region that matches the URL you sign into NinjaOne with. A wrong region 401s every later API call — Regentra’s Test Connection catches this before save.
2

Create the API Client in NinjaOne

In NinjaOne → Administration → Apps → API → Client App IDs → Add. Application Platform = API Services. Enable Client Credentials grant type. Enable the Monitoring scope only.
3

Copy the Client ID and Client Secret

NinjaOne reveals the Client Secret exactly once. Copy both values immediately into Regentra’s Client ID and Client Secret fields.
4

Test before Save

Click Test Connection before Save. A green result confirms the region + scopes + credentials are correct against NinjaOne’s regional API and surfaces the number of organizations visible.
5

Save

Save the credentials. Regentra generates an audit log entry on your MSP organization recording the connect event. The integration card shows Connected.

​
Mapping NinjaOne organizations to PSA companies

NinjaOne organizes its customer device fleets under “organizations” inside your account. Each NinjaOne organization binds to exactly one Regentra PSA company — or is explicitly marked “don’t sync” so it stays out of both PSA and compliance. After your first save, click Review organization mappings → on the integration card. Regentra pulls the organization list from NinjaOne and surfaces every customer org with:
  • The current mapping state (Pending review / Mapped / Ignored)
  • A suggested PSA company if Regentra can match by exact name (case-insensitive)
  • Map / Change (opens a panel to bind or create), and Don’t sync
For each row:
  • If Regentra found an exact-name match, a one-click Use <company name> button binds it immediately.
  • Otherwise, click Map to open the panel: Bind to existing PSA company (pick from a dropdown, then Bind) or Or create a new PSA company (type a name, then Create) — creating reuses a PSA company with that name instead of duplicating it if one already exists.
  • Don’t sync records the mapping as IGNORED so re-discovery doesn’t keep prompting you. Devices from that NinjaOne org never flow into Regentra.
The mapping survives credential reconnect — disconnecting and reconnecting NinjaOne doesn’t force you to re-map every customer.

​
PSA asset sync

Devices are filtered to approved before pulling — pending and rejected devices stay in NinjaOne but are skipped by sync. If the sync hits NinjaOne’s 10,000-device-per-org ceiling, the audit log flags the shortfall so you can see it without checking each customer manually.

​
Per-company sync

The PSA Company detail page (when bound to a NinjaOne org) exposes a Sync With NinjaOne button next to the existing Sync With M365 button. It triggers a sync scoped to just that one mapping so a single customer can be refreshed on demand without waiting for the next 4-hour sync.

​
Alert webhook (optional) — real-time PSA tickets

Beyond the polling syncs above, NinjaOne can push device/condition alerts to Regentra in real time and have them land as PSA tickets, instead of waiting on the next scheduled sync.
1

Copy the Webhook URL

After saving your NinjaOne credentials, a Webhook URL appears on the integration card. No separate Webhook Secret is needed — NinjaOne’s Notification Channel dialog only has Name and URL fields, and the random token embedded in the URL itself is the credential.
2

Create a Webhook notification channel in NinjaOne

In NinjaOne, go to Administration → Apps → Notification channels → + Add channel → Webhook (not the Apps → API screen you used for OAuth credentials). Turn Notifications on, give it a name, paste the Webhook URL, and save.
3

Attach the channel to Conditions

The channel won’t fire until you attach it to specific Conditions. Open a Device, NMS Device, or Policy’s Conditions screen and add the channel under that condition’s Channels selector.
4

Verify it's live

Attach the channel to one device’s “Agent Offline” condition, then disconnect that agent for about a minute. The integration card’s “Last received” timestamp should update within a minute, with a matching row in the Activity log.
A triggered condition creates a PSA ticket (idempotent — a redelivery of the same event never creates a duplicate ticket).

​
Compliance evidence sweep

For every NinjaOne organization mapped to a PSA company that has been promoted to a Regentra compliance workspace, the evidence sweep collects five aggregate-only signals every 6 hours. The five signals:

​
What’s included in each signal

Aggregates only. Every signal carries counts, percentages, vendor distributions, and bucket counts — never hostnames, IPs, serial numbers, drive letters, or last-logged-on-user values. The Trust Center reads from the same signals; per-device identifiers would leak customer device inventory if the customer’s Trust Center is public. This is enforced by an automated test that scans every signal’s output against a PII deny list.

​
How customer data stays separated

The evidence sweep runs in two stages so that data always lands in the right place:
  1. A scheduled step reviews your active NinjaOne credentials, finds every mapping whose PSA company has been promoted to a compliance workspace, and queues one job per customer.
  2. A per-customer step securely retrieves your NinjaOne credential, pulls that customer’s data from NinjaOne, and writes signals into that customer’s own compliance workspace — never into your MSP account, and never into a different customer’s workspace. Each customer’s sweep runs independently, so many customers can be processed at the same time without their data mixing.
This behavior is covered by automated tests that verify:
  • Every credential lookup uses your MSP account.
  • Every evidence write lands in the correct customer’s compliance workspace.
  • Every audit log entry lands in the correct customer’s compliance workspace.
  • The MSP account and each customer’s workspace are never conflated.

​
First-sync dry-run

The first compliance sweep after you connect NinjaOne collects signals but suppresses the auto-ticket bridge until that first sweep finishes successfully. This means: a 50-customer MSP turning NinjaOne on doesn’t wake up to 250 HIGH-priority tickets on day one if every customer happens to have failing antivirus or outstanding patches. After the first sweep completes, subsequent sweeps route findings to your PSA queue through the standard bridge.

​
Internal Control mappings

Each Internal Control crosswalks to its framework requirements in the CCF (HIPAA, SOC 2, NIST CSF, ISO 27001, CMMC, PCI DSS, GDPR, FTC Safeguards). One NinjaOne signal evidences the same control across every adopted framework simultaneously.

​
Disconnecting NinjaOne

Disconnect from the integration card. Regentra:
  1. Permanently deletes the stored credentials and marks the connection inactive.
  2. Retires every device record sourced from NinjaOne on your PSA account (records are preserved for historical traceability; they’re simply taken out of the active list).
  3. Writes an audit log entry on every customer compliance workspace that the disconnect affects, so each customer’s auditor sees a NINJAONE_DISCONNECTED event in their trail.
  4. Leaves existing monitoring signals alone — they age out naturally after 7 days. The auditor needs to see “the integration was disconnected with N signals already collected” at the moment of disconnect; wiping them would erase that record.
  5. Leaves existing company mappings alone, so a future reconnect doesn’t force you to re-map every customer.
If you reconnect the credential (same region) using new credentials at NinjaOne’s side, your mappings are preserved and the next scheduled sync resumes evidence collection on every previously mapped customer.

​
Rate limits and pagination

NinjaOne enforces per-tenant rate limits (1500 requests/hour sustained, 200/min burst). Regentra’s sync workers stay comfortably under that cap on every cadence we ship:
  • 4-hour PSA sync: one /organizations list + one /devices-detailed page per mapped customer.
  • 6-hour compliance sweep: six endpoints per customer.
Both syncs watch NinjaOne’s remaining-request count and log a warning if it drops below 100. Discovery requests cap at 5,000 organizations and 10,000 devices per organization; if you exceed either, the sync flags the shortfall so you can see it in the audit log.

​
Troubleshooting

Either the Client ID or Client Secret is wrong, or the region doesn’t match the host where the credentials were issued. Confirm the region in NinjaOne’s URL bar and re-test.
The API client was created at the system level but isn’t attached to any customer organization. In NinjaOne, edit the API client and confirm it’s tenant-scoped or has org assignments — the monitoring scope needs visibility on at least one customer org to be useful.
The page reads the region from your saved credential. If you haven’t saved a credential, save one first; the page will then auto-detect the region and load the mapping list.
Hit Refresh from NinjaOne at the top of the mappings page. If the customer still doesn’t appear, confirm in NinjaOne that the customer org exists and the API client has visibility (the monitoring scope honors tenant-level permission scoping).
The compliance sweep only runs for customers whose PSA company has been promoted to a Regentra compliance workspace. Confirm the customer’s PSA company has a linked compliance workspace (Compliance → Clients → [customer]). If the customer hasn’t purchased compliance, NinjaOne data flows into PSA assets only.
By design. The first sweep after connect is a dry run: signals land in the compliance workspaces but the auto-ticket bridge is suppressed so you can review findings before they hit your PSA queue. After the first successful sweep, subsequent runs route findings to your queue normally.

​
What this integration does NOT do

  • No remote control sessions. Regentra never requests the control scope, even if NinjaOne offers it.
  • No write-back to NinjaOne. Regentra never requests the management scope. Future read-write features (e.g., setting a regentra_compliance custom field per device) would require an explicit opt-in toggle in the integration card.
  • No per-event device telemetry in the compliance evidence. The activity log is sampled only as aggregates for the backup-activity signal; individual device events are not persisted as evidence. (The optional alert webhook above is a separate path, feeding PSA tickets rather than compliance evidence.)