CheckWarranty.info

ERP · WMS · ITAM · Refurbished inventory

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.

Tested with GLPI 10.0.28 and 11.0.12.

Before connecting: Extract the checkwarranty folder into plugins/, then install, activate and configure it in GLPI.

GLPI command-line sync

Python CLI or Docker

Synchronize Computer financial records through the GLPI REST API. Run it from your own server or scheduler using GLPI application and user tokens.

Tested with the REST API of GLPI 10.0.28 and 11.0.12.

Before connecting: Configure the GLPI URL, application token and user token in a private environment file.

NetBox sync

Python CLI, Docker or NetBox Custom Script

Update device custom fields with expiration dates, warranty status, support tiers and available factory specifications.

Tested with NetBox 4.7, including the Custom Script and restricted-user permissions.

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.

Follow the steps on your own test server
  1. 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.
  2. 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.
  3. 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

  1. Choose an integration above and follow its installation guide on your own server.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

python3 checkwarranty-csv.py sandbox-inventory.csv results.csv --run-id sandbox-intake-001

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.

CSV upload and export instructions

3. Add a Node.js request to your application

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.

Bulk request and status contract · Webhook delivery and verification

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.