What an IMEI API is for
An IMEI lookup turns fifteen digits into a device record. What that buys you, what it cannot tell you, and when a lookup beats a list you maintain yourself.
An IMEI API answers one question: given these fifteen digits, what is this device? Send the number, get back a manufacturer, a model, a code name, a device type and a radio profile. That is the whole of it.
The interesting part is not the mechanism but what stops being your problem once you have it.
The problem it removes
Any system that takes in second-hand devices, prices them, repairs them or insures them has to know what it is holding. Without a lookup there are two ways to find out, and both are worse.
You can ask a person. A dropdown of manufacturers and models, filled in by whoever is at the counter. It is free, it is instant, and it is wrong often enough to matter: the wrong storage tier, the wrong regional variant, the right model name attached to the wrong hardware.
Or you can keep a list. Every model, every variant, every carrier build, maintained by hand. It works until the week a manufacturer ships something nobody added yet.
That asymmetry is the case for a lookup, and it is worth stating plainly: a list has to be right about every device that exists, forever. A lookup only has to be right about the one in front of you.
What one call actually does
- Your system takes fifteen digits from somewhere — a barcode, a dialled *#06#, a form field.
- The checksum is tested locally. A mistyped number fails here, costs nothing, and never leaves your process.
- The register is asked. This is the step that costs a lookup.
- One JSON object comes back, or a documented error explaining why not.
What it cannot tell you
A device record describes the hardware as allocated. It is not a history and not a status:
- Not whether the device is stolen. That lives in national blocking registries, which are separate, per-country, and not the same data.
- Not its condition. A cracked screen and a mint one resolve identically.
- Not who owns it, has owned it, or where it has been.
- Not whether a network will accept it today — the record says what the hardware supports, not what a given operator has decided.
Systems that quietly assume otherwise tend to fail in the same way: a lookup returns successfully, the result is treated as a clean bill of health, and something that was never checked is presumed fine.
Integrating one without regret
Three things are worth deciding at the start, because all three are painful to change later.
Store the record, not just the answer
Keep the fields you got and the number you sent. A month later, when a price looks wrong, the question will be what the register said at the time — and a stored model string alone cannot answer it.
Key on the device, not the marketing name
The commercial name is what you show a customer. The code name and the radio profile are what you make decisions with, and they are what distinguish two devices sold under one name.
Handle the documented failures explicitly
A failed checksum, an unallocated code and an exhausted balance are three different situations with three different fixes. Collapsing them into one "lookup failed" branch means whoever debugs it later has to guess which one happened.
When you do not need one
If devices arrive in bulk from a single supplier who already sends you a manifest, you have the identity already; a lookup is confirmation, not information. If you handle a handful of units a month, a person reading a label is cheaper than an integration.
The case for a lookup gets stronger with volume, with variety, and with how expensive it is to be wrong. Buyback and insurance sit at the far end of all three, which is why that is where these integrations usually appear first.
Read next
Turn an IMEI into a device record.
Brand, model, code name, device type and radio bands, in one call. Tell us what you're building and we'll set you up with a key.