NinjaRMM integration: patch data that feeds client compliance
Your RMM already knows which devices are patched. Graften takes that data, attributes it to the right client and uses it as real evidence in health scores and reports.
Set-up
- In Graften, add NinjaRMM under Integrations with its client id and client secret. Credentials are encrypted at rest and never shown again.
- Run Test Connection, which calls Ninja's API and reports a real pass or fail.
- Open Client Mappings and map each Ninja organisation to a Graften client.
- Run Sync Now from the client's patch view.
Why mapping matters
An MSP's Ninja tenant holds all of its clients as organisations. Graften only attributes devices to a client through the mapping. An organisation with no mapping is skipped, never guessed, so one client cannot end up with another client's devices.
Multi-site clients
A client with several Ninja organisations, for example one per site, can have all of them mapped and every one is synced. If one organisation fails, the others still import, the sync is reported as partial, and the patch history snapshot is skipped rather than recorded from an incomplete device list.
What it feeds
- Patch status per device, from each device's patch report
- The patch compliance component of the client health score
- Patch evidence for Essential Eight reports and evidence packs
A device that cannot be assessed is skipped, not marked compliant. If a device's patch report cannot be fetched or decoded, its existing record is left untouched.
Frequently asked questions
Does Graften change anything in NinjaRMM?
The sync reads devices and patch reports. It does not push changes to your Ninja tenant.
What if a client has no Ninja organisation mapped?
The sync refuses with a clear message asking you to map one under Client Mappings first.