NinjaOne RMM

NinjaOne is MSP-shaped: organizations (customers) contain locations, groups, and devices. Policies and automation scripts drive patch and monitoring behavior. Activities, alerts, and jobs surface audit and operational state.

Every API call uses Bearer auth on the same regional host as the console (app, us2, eu, oc, ca subdomain before .ninjarmm.com); the bearer is minted per datacenter.

Hierarchy

• Organization — MSP customer tenant root.
• Location — site under an organization.
• Group — device grouping for policies (not the same as organizations).
• Device — managed endpoint (workstation, server, network gear).
• Policy — monitoring/patch template by node class.
• Device role template — chassis taxonomy (WINDOWS_SERVER, etc.); distinct from node roles (assignment roles) and technician RBAC.
• Activity / alert / job — audit stream, open conditions, and background work.

Operational order

1. List organizations (optionally detailed) to discover customer ids.
2. Scope locations and devices with organization_id when working one customer.
3. Pull groups, policies, and automation scripts before planning changes.
4. For one endpoint's live inventory, use device reads with an aspect; for fleet-wide exports, use query reports.
5. Management actions (reboot, patch apply, script run, decommission) require the management scope — confirm intent before destructive actions.

Device reads vs query reports

Per-device aspect (requires device_id): summary (default record), software, os_patches, software_patches, os_patch_installs, software_patch_installs, disks, volumes, processors, network_interfaces, windows_services, last_logged_on_user, custom_fields, policy_overrides, dashboard_url.

Fleet query reports (tenant-wide export families): antivirus_status, antivirus_threats, backup_usage, computer_systems, custom_fields, custom_fields_detailed, device_health, disks, logged_on_users, network_interfaces, operating_systems, os_patch_installs, os_patches, policy_overrides, processors, raid_controllers, raid_drives, scoped_custom_fields, scoped_custom_fields_detailed, software, software_patch_installs, software_patches, volumes, windows_services.

Use aspects for one machine's current slice; use query reports when you need the same column set across the fleet.

Device management actions

All reboot, OS and software patch scanning, patch application, script execution, maintenance windows, service control, policy-override reset, and decommission paths go through the single device action tool with an action enum: reboot, run_script, os_patch_scan, os_patch_apply, software_patch_scan, software_patch_apply, schedule_maintenance, cancel_maintenance, decommission, windows_service_control, windows_service_configure, reset_policy_overrides. reboot, patch apply, and decommission are destructive — confirm before calling.

Writes and upserts

Create vs update is selected by optional id on upsert tools; supply the upstream JSON body object documented in NinjaOne's API reference. Organization-scoped writes (locations, policy mappings, custom field values) need organization_id.

Licence gates

• Ticketing metadata and ticket CRUD return HTTP 403 when the tenant lacks the ticketing module — surface that honestly.
• Billing endpoints are not exposed here.

Gotchas

• Datacenter host: API calls and token minting must all target the same subdomain as the NinjaOne console.
• Pagination: activities returns lastActivityId — pass it as after. Most lists return bare arrays; empty fleets are valid.
• Scopes: monitoring covers reads; management is required for device actions and most writes.
• Role naming: device role templates (chassis types) differ from node roles (assignments) and technician user roles.