Intune Insights: Warranty Integration Implementation Guide

Warranty lookups for HP and Lenovo devices already run on a schedule once a valid key exists for the deployment. This API is how you set (or remove) that key.

The two type strings are part of the contract and must be spelled exactly as shown.

See Two exact type strings, no allow-list below for further information on why it's important to match these exact strings.

All calls use Authorization: Bearer <jwt>, where the JWT comes from the same admin token issuance Nerdio already uses for every other partner-facing feature:

POST /api/nerdio/issue-jwt/admin
ApiSecret: <shared secret>
Content-Type: application/json
 
{ "userEmail": "you@example.com", "userName": "Your Name" }

Response: 200 OK

{ "jwt": "<admin JWT>" }

The integrations endpoints below require an Instance Admin user, which is what the admin JWT already carries. No further permission grant is required.

GET /api/admin/integrations/{type}

Response: 200 OK

{
  "integrationId": 1,
  "integrationType": "HpWarranty",
  "isEnabled": true,
  "isConfigured": true,
  "configJson": null,
  "createdAt": "2026-09-01T19:13:09.6863181Z",
  "updatedAt": "2026-09-01T19:13:09.6863565Z"
}

isConfigured tells you whether a credential is on file. The credential itself is never returned by this or any other endpoint.

Unknown or never-created {type} returns 404 Not Found.

To list everything configured for the deployment:

GET /api/admin/integrations

Response: 200 OK, an array of the same shape, one entry per integration type that has ever been saved (soft-deleted ones are excluded).

PUT /api/admin/integrations/{type}
Content-Type: application/json
 
{
  "integrationType": "HpWarranty",
  "isEnabled": true,
  "credentialsJson": "{\"apiKey\":\"...\",\"apiSecret\":\"...\"}"
}

PUT /api/admin/integrations/{type}
Content-Type: application/json
 
{
  "integrationType": "LenovoWarranty",
  "isEnabled": true,
  "credentialsJson": "{\"clientId\":\"...\"}"
}

Response: 200 OK, the resulting IntegrationResponseDto (same shape as section 1).

This call is an upsert: the first PUT for a {type} creates it, every subsequent PUT updates the same row.

PATCH /api/admin/integrations/{type}/toggle
Content-Type: application/json
 
{ "isEnabled": false }

Response: 204 No Content. Unknown {type} returns 404 Not Found.

DELETE /api/admin/integrations/{type}

Response: 204 No Content on success, 404 Not Found if nothing is on file for that type. This is a soft delete: calling PUT again afterwards for the same {type} creates a brand new record (a new integrationId), it does not revive the deleted one.

Nerdio Manager has no way to check an HP or Lenovo key against the vendor before storing it. Saving a mistyped or expired key succeeds immediately with 200 OK and isConfigured: true, exactly the same response you'd get for a correct key.

The mistake surfaces later and quietly: the next scheduled sync tries the vendor call, it fails, and a warning is written to the background sync log. Nothing is returned to whoever called this API, and no visible error message appears. From the administrator's perspective, the only visible symptom is that warranty dates for that vendor simply never populate on devices. If that happens, double-check the credential value itself; the API call having returned 200 does not mean the key is good.

PUT does not validate {type} against a known list. PUT /api/admin/integrations/HPWaranty (typo'd) returns 200 OK and creates a row exactly like a correctly-spelled one; there is no 404 to catch the mistake.

That row is then invisible to the sync job forever. The read path (GET/PUT/DELETE) matches {type} case-insensitively against the database, so GET /api/admin/integrations/hpwarranty happily returns the HpWarranty row and makes a typo'd or wrongly-cased save look fine on inspection. The sync job, however, loads enabled integrations and then matches the type in memory with an exact, case-sensitive string comparison against the literals "HpWarranty" and "LenovoWarranty". A row stored as HPWaranty, hpwarranty, or any other variant passes every read-side check but is silently skipped by every sync run.

{type} is HpWarranty or LenovoWarranty. Do not call this API for DellWarranty.