Launching the Unified MDM API: Integrate Iru, NinjaOne, and More

Integrating with Mobile Device Management (MDM) platforms is a necessary evil for any B2B SaaS application touching corporate devices. Today, we are launching Truto's Unified MDM API. It allows you to read and write data across multiple MDM providers—starting with Iru (formerly Kandji) and NinjaOne—using a single, normalized data model.

Why Building MDM Integrations is an Engineering Nightmare

Ask any engineer who has built integrations for Jamf, Intune, or NinjaOne, and they will tell you the exact same thing: MDM APIs are uniquely punishing. You aren't just dealing with different API design philosophies; you are dealing with fundamental differences in how Apple, Microsoft, and Google model device ownership.

Rate Limits That Break Production

MDM platforms are notorious for aggressive throttling, and they all handle it differently.

• Jamf Pro officially recommends limiting full inventory fetches to once per day to avoid degrading their cloud performance, and strictly limits concurrent API connections to five.
• Microsoft Intune (via Microsoft Graph) enforces a hard limit of 200 requests per 20 seconds per tenant.
• Iru (Kandji) caps requests at 10,000 per hour per tenant.
• NinjaOne heavily throttles based on the endpoint, often requiring request batching and intelligent caching just to stay under the radar.

If your app tries to sync a fleet of 5,000 devices using a naive polling mechanism, you will hit a 429 Too Many Requests error almost immediately. You are then forced to build complex backoff-and-retry queues just to maintain a basic sync state.

Truto standardizes what you see when a provider rate-limits. We detect rate limiting per integration (by default HTTP 429; we can also use configurable JSONata for providers that signal limits with other statuses or custom headers). When we determine a response is rate limited, we always return HTTP 429 to your app with a normalized Retry-After header and, when configured, the same ratelimit-limit, ratelimit-remaining, and ratelimit-reset headers regardless of the MDM. Those same quota headers are also sent on successful responses so you can read quota state and avoid hitting the limit. The Unified API sets truto_error_insight.rate_limit_error on 429 responses so you can handle rate limits in code without parsing body text.

Pagination Hell Across MDM Providers

Because device fleets are massive, you will spend an unreasonable amount of time writing pagination logic. Intune uses OData @odata.nextLink URLs. Iru uses traditional limit and offset query parameters. NinjaOne relies on cursor-based navigation. Writing, testing, and maintaining separate pagination handlers for every MDM is a massive drain on engineering resources.

Authentication Fragmentation

B2B customers hate complex onboarding. Unfortunately, MDM authentication is rarely straightforward.

• Iru (Kandji) relies on static API tokens generated in the admin dashboard.
• NinjaOne uses a traditional OAuth2 flow but requires specific client credential configurations depending on the region (EU vs US instances).
• Jamf Pro requires managing short-lived Bearer tokens and handling fallback logic between their Classic API and Pro API.

Supported MDM Platforms and Normalized Entities

What is a Unified MDM API? A Unified MDM API is a single integration layer that standardizes authentication, pagination, rate limiting, and data schemas across multiple Mobile Device Management providers.

Right now, the Truto API supports Iru (formerly Kandji) and NinjaOne. We normalized the core entities that matter most to B2B SaaS integrations:

• Devices: Hardware specs, OS versions, compliance status, and assigned users.
• Apps: Installed software inventory and versioning.
• Users: Directory information mapped to the device owner.
• Organizations: Tenant and grouping structures.

How Truto Normalizes MDM Schemas Under the Hood

Mapping a "Device" across different MDM providers exposes the underlying philosophy of the vendor. Intune treats devices as extensions of the Azure AD user identity. Iru treats the Apple hardware as the absolute source of truth. If you want to understand why this is difficult, read our post on why schema normalization is the hardest problem in SaaS integrations.

When you query /unified/mdm/devices via Truto, we map vendor-specific fields into a predictable schema.

// Example: Fetching normalized devices
GET /unified/mdm/devices
Authorization: Bearer <truto_token>
Truto-Target-Account-Id: <account_id>
 
{
  "result": [
    {
      "id": "dev_12345",
      "name": "Engineering MacBook Pro",
      "serial_number": "C02X12345678",
      "mac_address": "00:1A:2B:3C:4D:5E",
      "os_name": "macOS",
      "os_version": "14.2.1",
      "is_compliant": true,
      "remote_data": {
        // The raw, unmodified payload from the MDM provider
      }
    }
  ],
  "next_cursor": "...",
  "result_count": 1
}

The Proxy Layer and JSONata Mapping

Truto does not just blindly map fields. We use a dedicated proxy layer that handles the raw HTTP requests to the third-party services. This layer automatically manages the authentication (whether it's OAuth or API keys), handles the specific pagination strategy (cursor, offset, or link-header), and standardizes rate-limit responses: when an MDM rate-limits a request, we always return 429 with a normalized Retry-After and optional ratelimit-* headers so your app sees a consistent shape for every provider.

Once the proxy layer retrieves the raw data, our mapping engine uses JSONata expressions to transform the response into the unified schema. We extract serial_number, mac_address, and hardware_uuid into top-level fields. This prevents you from having to dig through nested network_interfaces arrays just to find a MAC address. Device compliance state is normalized into a boolean is_compliant flag.

Fetching Related Resources Without Hitting Rate Limits

In many MDM APIs, retrieving a device only gives you a user ID, not the user's actual details. To get the user's email or department, you have to make a secondary API call. If you are syncing 5,000 devices, that is 5,000 additional API calls—guaranteeing you will hit rate limits.

Truto handles this internally using Related Resources. When you query the unified API, you can side-load related data. Our engine automatically intercepts the primary response, extracts the necessary IDs, makes the secondary API calls through our proxy layer (respecting concurrency limits), and joins the data back together before returning the normalized JSON to you. You make one request; we handle the orchestration.

The Escape Hatch: Accessing Raw remote_data

Notice the remote_data object in the JSON response above. We always attach the original, unmodified third-party response to every mapped object. If a specific customer uses a custom extension attribute in Jamf or a proprietary field in NinjaOne that isn't covered by our unified schema, you are not blocked. You can always access the raw data.

Standardizing MDM Webhooks and Event Syncing

Modern SaaS applications expect real-time updates. When a device falls out of compliance, your application needs to know immediately to revoke access.

The problem is that MDM providers handle event streaming very differently. Some providers offer mature webhook implementations. Others force you to poll their endpoints on a cron job.

Truto abstracts this entirely. We ingest the event stream where webhooks are supported, and we manage the polling infrastructure where they aren't. Your application receives a standardized webhook event from Truto whenever a device state changes, completely decoupling your architecture from the vendor's limitations.

The Trade-offs: When Not to Use a Unified MDM API

Let's be highly objective. A unified API is not a magic wand. Truto normalizes the data schema and handles the transport layer (authentication, pagination, rate limits). We do not normalize the underlying OS policies.

If you need to push a highly specific, proprietary macOS configuration profile that only Jamf supports, or execute a custom Bash script via NinjaOne's remote control tools, a unified API abstracts away too much detail. Unified APIs excel at broad, horizontal use cases—like inventory syncing, compliance reporting, and access management—not deep, vendor-specific policy enforcement.

If your core product is a specialized Mac administration tool, build direct integrations. If your product is an HR platform, a compliance dashboard, or an IT ticketing system that just needs to know who owns what device and whether it is secure, use a unified API.

MDM Integration Roadmap: Jamf, Intune, and More

We are aggressively expanding our MDM coverage. The following platforms are on our immediate roadmap:

• Jamf Pro
• Microsoft Intune
• VMware Workspace ONE
• Ivanti
• Cisco Meraki Systems Manager
• Google Endpoint Management

Stop Building Redundant MDM Integrations

If your roadmap includes building MDM integrations, you have a choice. You can spend the next three sprints reading outdated API docs, building custom OAuth flows, and writing retry logic for HTTP 429 errors, or you can integrate once with Truto.