NinjaOne
Straight answer first: don't sync users from NinjaOne. Use the public API for reporting instead — here's why, and how.
Why not user sync
NinjaOne is an RMM — its world is devices, not people. The user/contact data it holds is thin (often just whoever's logged into a monitored endpoint), which makes it an unreliable source of truth for who should actually be enrolled in security awareness training. Syncing from a thin source just means you inherit its gaps.
Chinron already has direct, purpose-built directory sync for this: Microsoft 365, Google Workspace, and Zoho — set these up per client under Admin Settings → Directory instead of routing user data through Ninja. See Import Your Staff for the walkthrough.
Where the API does help
Reporting. If you're building out a Ninja-centric client dashboard (via Ninja's scripting/webhooks, or a middleware layer like Rewst/n8n sitting alongside your RMM stack), pull:
GET /clients/{clientId}/reports/training-summary— completion rate and overdue countGET /clients/{clientId}/reports/phishing-summary— simulation click/report ratesGET /clients/{clientId}/reports/risk-score— per-user and org-average human-risk score
These are read-only and gated on the reports:read scope, so a key used purely for reporting can't create or modify anything. See the interactive docs for full response shapes.
If you still want to try it
User creation and update endpoints work the same way for any RMM/PSA — see the ConnectWise guide for the general middleware pattern. Just weigh it against directory sync's data quality before committing to it.