WarrantySync reads the hardware you already track in Jira, asks Dell, Lenovo and HP when each machine’s cover ends, and raises an issue before it does. The only thing that ever leaves is a device serial number, sent to that device’s own manufacturer.
Somebody built it from a purchase order two years ago. It has no owner, no refresh, and no way to tell a machine that was replaced under warranty from one that never was. It is consulted, disbelieved, and then consulted again.
The decision turns on whether the machine is covered, and the agent making it has no login to the manufacturer’s portal. So it is guessed, or it waits for somebody who does.
A support contract ends quietly. Nothing breaks on the day. It surfaces weeks later, at the worst possible moment, as a machine that cannot be fixed under a contract that expired in March.
Four things, in that order. The first needs no credentials at all, which is the point: the estate is counted and classified before anybody has to request a single credential.
Counts your estate before you have a single credential. How many Dell, Lenovo and HP devices, how many from manufacturers it does not cover, and how many have no serial number to look up.
Once a manufacturer is connected, it looks warranties up in batches, writes the end date onto your device records, and keeps a per-device history.
A daily sweep re-derives every status from the stored end date, so a device crosses into the warning window on exactly the right day without waiting for a manufacturer.
It raises Jira issues before warranties expire, under flood controls strict enough that a first run on a fresh install raises at most one summary issue.
Dell approval takes a few working days. Lenovo and HP are not self-service at all. So the app is built to be useful before any of that arrives: install it, point it at your hardware, and the first pre-scan tells you what is there.
An app that raises one issue per expiring device, on an estate where two hundred warranties lapsed last year, is an app that gets uninstalled on its first afternoon. Four rules stop that, and none of them is a setting you have to find.
A device whose warranty ended eight months ago never gets a per-device issue. The backlog is on the dashboard, where it can be worked through, not in your project.
Whatever the first sync finds, it produces at most a single summary issue naming the counts: the estate is described, not enumerated. That summary is not behind the switch below, which is deliberate — it is how you find out the app is working. Turn the switch on before your first sync and you get per-device issues as well.
Ongoing issue creation starts disabled and stays disabled until a Jira administrator deliberately switches it on, on the dashboard.
An issue you resolved is not re-raised for the same expiry date. The de-duplication key lives in Jira, so it survives the app being uninstalled and put back.
There is also a digest style: a single issue per run listing the devices that entered the warning window, instead of one issue each. A digest lists at most 200 devices and says in the issue how many were held over.
That is the entire output of a first sync, whatever the size of the estate: one issue, naming the counts, so somebody knows the app is working without anybody’s board filling up.
Jira Service Management Assets is a Premium and Enterprise feature. Plenty of teams track hardware without it, and buying Assets in order to run this app would be the wrong way round.
Point it at an object schema and an object type. The app reads your hardware objects and writes the warranty end date back into the attribute you mapped.
JSM Premium or Enterprise
Point it at a project and an issue type. Serial number, manufacturer, model and warranty end are read from and written to the custom fields you already use.
Any Jira edition, Free included
You choose which, and the settings page offers both. Discovery then proposes a mapping and an administrator confirms or overrides every field; nothing is saved automatically. It never creates a custom field, an Assets attribute or a schema in your site — if a mapping is missing, it names the field to create and offers to look again.
The app ships with none of its own. That is deliberate: your warranty entitlement is yours, the rate limit is yours, and no lookup of yours is pooled with anybody else’s.
Self-service
Needs: A TechDirect Client ID and Client Secret
Self-service. Register for TechDirect API access with your Dell account; approval usually takes a few working days.
Via your account manager
Needs: A Support API ClientID
Not self-service. Your Lenovo account manager issues it. The settings page gives you the request email to send.
Via your account manager
Needs: Warranty API credentials
Not self-service. Your HP account manager or reseller partner issues them. The settings page gives you the request email to send.
A manufacturer with no credential saved is never contacted. Connect one, all three, or none at all and stay in pre-scan.
Where the three adapters stand. Each is built to that manufacturer’s published API — its host, its authentication and its response shape — and each is covered by tests against a stand-in for it. None has yet been run against live credentials, because we hold none: Dell approval is pending and Lenovo and HP issue theirs through an account manager. Every one will be exercised against a real account before the app is listed, and any that cannot be will be dropped from the listing rather than claimed. If you have credentials already and would be willing to help prove one, that is the single most useful thing you could offer us.
The whole estate in four numbers, filterable by status and exportable to CSV. A refresh plan you can take to a budget meeting, with the expiry dates behind it.
Coverage on the work item you are already looking at. Whether this machine is under warranty decides repair or replace, and it is on the screen rather than in somebody else’s portal.
Discovery proposes a field mapping and you confirm it. The app never creates a custom field, an Assets attribute or a schema in your site.
Three declared hosts, one data type, no analytics, and a cloud security statement written to be read rather than skimmed.
What it is, and is not. Every date here comes from the manufacturer that sold the machine — we do not generate it, correct it or independently confirm it. So this is a monitoring aid rather than a system of record: it is built to tell you where to look and when, and before you act on one machine you should confirm it with the manufacturer or with your own purchase record. The longer version is on the features page.
A serial number, sent to that device’s own manufacturer. No device names, no email addresses, no account ids, no issue content. This is structural rather than promised: the vendor adapters accept a list of serial numbers and take no other argument.
| Host | Receives | Processed in | Contacted |
|---|---|---|---|
apigtwb2c.us.dell.com | Dell service tags | United States | Only once Dell credentials are saved |
supportapi.lenovo.com | Lenovo serial numbers | Not published by Lenovo; assume outside the UK and EEA | Only once Lenovo credentials are saved |
css.api.hp.com | HP serial numbers | Not published by HP; assume outside the UK and EEA | Only once HP credentials are saved |
That list is the whole allowlist, declared in the app’s manifest and shown to you at install, and Forge refuses any address that is not on it.
It installs with no credentials and counts your estate on the first run, so you know the size of the problem before anybody has to request API access. It is free, and there is no licence check to fail.
