Connect warranty lookups to your inventory workflow
Retrieve available warranty and factory data for Lenovo, Dell, HP and Apple. Start with simulated sandbox records, then test the fields available for your own inventory.
Ready-made integrations for your ITAM
Install an integration in your own GLPI, NetBox or Snipe-IT system. Each release includes setup instructions and source code. A CheckWarranty account and API key connect your installation to the warranty API.
Current release: 1.0.1. CLI images support Linux AMD64 and ARM64; Python packages are available from GitHub Releases.
GLPI plugin
Native GLPI interface
Add a Computer warranty tab with manual refresh and optional background synchronization. Store exact expiration dates in financial information without changing purchase dates.
Before connecting: Create the documented Device custom fields and configure an API token. For the Custom Script, configure the CheckWarranty key in the worker environment.
Snipe-IT sync
Python CLI or Docker
Write exact warranty expiration dates and available factory specifications to asset custom fields. Existing purchase dates are preserved.
Tested with Snipe-IT 8.8.3 and the public CheckWarranty sandbox API.
Before connecting: Configure the Snipe-IT URL, an asset view/edit API token and the database name of your warranty expiration custom field.
Watch: connect Snipe-IT in a sandbox
40 seconds · Silent video with English and Russian subtitles · Connector 1.0.1
Recorded Snipe-IT screens and illustrated commands show one test asset before and after synchronization through the public HTTPS sandbox API.
Recorded result: one TEST-ENDONLY asset updated, 0 credits used, purchase dates and other assets preserved. The expiration date 2026-08-20 is simulated fixture data.
Install release 1.0.1. Configure your Snipe-IT URL, an asset view/edit API token, the warranty expiration custom field database name and a CheckWarranty sandbox key in a private environment file, following the installation guide.
Use an isolated Snipe-IT test instance containing only TEST-* assets. Run --plan --limit 1 to inspect the first candidate without CheckWarranty lookups or asset changes.
With the sandbox key, run --force --limit 1 and inspect the exact expiration custom field. Sandbox data is simulated and uses no scan credits. A live key can incur charges.
Connect your first test device
Choose an integration above and follow its installation guide on your own server.
Create a sandbox API key and keep it in the server configuration. Use an isolated ITAM test instance containing only TEST-* devices, such as TEST-DELL-001.
For a CLI, start with --plan. For the NetBox Custom Script, leave Plan only enabled. These modes list candidates without CheckWarranty lookups or asset changes.
Run a sandbox synchronization and inspect the exact expiration field. In the GLPI plugin, configure the sandbox key before using manual refresh. Keep its automatic action disabled while testing.
For real inventory, configure a live key, review the candidate list and start with a small batch before scheduling synchronization.
Plan, sandbox and dry-run are different
--plan sends no CheckWarranty requests. A sandbox key returns simulated TEST-* data without spending credits. --dry-run prevents asset writes but still calls CheckWarranty and can spend credits with a live key.
Live results with useful warranty or specification data can be chargeable, including partial results. A result with no useful device data releases the scan reservation. Missing dates stay unknown; warranty start and purchase dates are distinct.
1. Run your first sandbox request
Set the CW_API_KEY environment variable to a cw_test_ key from your dashboard. Sandbox records are simulated and consume no scan credits. Production keys can incur charges for useful device data.
# Set CW_API_KEY to a cw_test_ key from your dashboard.
# Reuse this idempotency key when retrying the same request.
REQUEST_ID=$(uuidgen)
curl -i -X POST "https://checkwarranty.info/api/v1/devices/lookup" \
-H "X-API-Key: $CW_API_KEY" \
-H "Idempotency-Key: $REQUEST_ID" \
-H "Content-Type: application/json" \
-d '{"serialNumber":"TEST-LENOVO-001","brand":"lenovo"}'
# HTTP 202: retrieve the result from the Location response header.
Keep the Idempotency-Key unchanged when retrying the same request. A new operation needs a new key. Read the idempotency contract.
2. Enrich a CSV file with Python
The downloadable Python 3 script uses the standard library. It submits rows sequentially, preserves each complete JSON response in the output CSV, follows asynchronous results and records failures separately.
CSV columns: serialNumber, brand, optional productNumber. Use lowercase brand names. Some HP devices require the product number from the same device label.
For a retry, preserve the input file, row order and run ID; choose a new output filename. The script refuses to overwrite existing output. It requires an explicit --live flag for production keys. It stops polling after 60 attempts; pending work may still finish later.
Map results back to your inventory
Keep your internal asset ID and original serial number in your inventory. Match returned records by brand and serial number rather than row order. The downloadable recipe does not copy extra asset-ID columns into its output.
The web upload reads the first column and applies one selected brand to the batch. Split a mixed-brand file before using the web scanner. The bulk API supports an explicit brand on each item; some HP lookups also need productNumber.
Store missing warranty dates as unknown, not expired. Keep factory configuration separate from the installed RAM and SSD. Inspect upgraded devices separately.
Run this server-side in a current Node.js runtime with native fetch. Keep API keys out of browser bundles and source control.
// Set CW_API_KEY to a cw_test_ key. Reuse requestId for retries.
const requestId = crypto.randomUUID();
const response = await fetch("https://checkwarranty.info/api/v1/devices/lookup", {
method: "POST",
redirect: "error",
headers: {
"X-API-Key": process.env.CW_API_KEY,
"Idempotency-Key": requestId,
"Content-Type": "application/json"
},
body: JSON.stringify({serialNumber: "TEST-LENOVO-001", brand: "lenovo"})
});
if (!response.ok) throw new Error(await response.text());
if (response.status === 202) {
console.log("Processing; retrieve result:", response.headers.get("Location"));
} else {
console.log(await response.json());
}
HTTP 202 means accepted, not completed. Authenticate GET requests to the Location URL and inspect the batch status and individual items. Accept only polling URLs on the API origin. Handle pending results, missing fields, product-number requirements and errors explicitly.
4. Move from a trial file to warehouse batches
The web app accepts up to 100 devices per batch; the bulk API accepts up to 500. A credit package can cover multiple batches. The Python recipe above uses single lookups; use the bulk endpoint for a queued batch workflow.
Factory data does not confirm components installed after an upgrade. Useful partial data, such as warranty only or specifications only, is chargeable. No useful device data means the scan reservation is released.