Caching and retrying device lookups

Most API integration advice about caching is hedged, because most data changes. Device records are the pleasant exception, and the reason is worth understanding rather than taking on trust.

Why device records keep

A Type Allocation Code — the first eight digits of an IMEI — is allocated to a manufacturer for a specific model and is not reassigned. There is no process by which the code identifying one phone comes to identify another later.

So the mapping from those eight digits to a device is stable in a way that almost nothing else in an integration is. What it meant last year is what it means today.

The practical consequence is that you should cache on the TAC, not on the full IMEI. Every handset of the same model shares those eight digits, so one lookup answers for all of them — the thousandth iPhone of a given variant through your door costs nothing.

What must never be cached

Anything describing your account rather than the device. Balance, quota state and every error response are true at one instant and about you, not about the hardware.

Caching a 402 is the memorable version of this mistake: the balance is topped up, and the integration keeps serving a stale "no lookups left" from its own cache while the account sits full.

Which failures deserve a retry

The distinction is whether repeating the identical request could plausibly produce a different answer. A failed checksum will fail identically forever. An unallocated code will not become allocated in the next two seconds. An invalid key will not become valid.

A rate limit and an upstream failure are different: both describe a temporary condition, and both are worth trying again — the first after the interval the response names, the second on a backoff.

Retrying the permanent failures is worse than useless. A loop that retries a malformed number turns one bad digit into a burst of identical requests, which is precisely the traffic shape that gets an integration rate-limited.

A shape that works

1. Validate the checksum locally before sending anything. Most bad input dies here, free and instantly.
2. Look in your own cache, keyed on the first eight digits.
3. On a miss, call the API once.
4. Branch on the documented error codes explicitly — do not collapse them into a single failure path.
5. Cache the successful record; cache nothing else.
6. Back off on 429 and 5xx, using the interval the response gives you rather than a number you invented.

None of this is exotic. It is the ordinary shape of a well-behaved client, and it is worth writing down because the failure mode of getting it wrong — a cache holding an error, a loop retrying something permanent — tends to surface as "the API is broken" long before anyone suspects the integration.