Six fields to write down every time you resolve a device
Months later, someone will ask why a phone was priced the way it was. These six answer it; anything less turns into an argument.
Logging is one of those tasks that never feels urgent while it is cheap and is impossible once it is needed. For device lookups the useful set is small and specific, so it is worth being deliberate rather than logging everything or nothing.
The six
The number that was sent, exactly as sent — before normalisation. This is what distinguishes a typo from a device, and it is the field most often lost because tidying it up feels like an improvement.
What came back, in full. Not just the model string you display, but the fields you priced against. Six months later the question is what the register said at the time, and a stored model name cannot answer it.
When. Records are corrected and enriched over time, so a resolution is a statement about a moment, and the moment matters when two answers disagree.
Who or what asked. Which branch, which integration, which member of staff. This is how a systematic problem in one place gets noticed as a pattern rather than as scattered complaints.
Whether it was a cache hit or a call. Without it, nobody can explain the size of the bill, and cache effectiveness is invisible.
The error, if there was one, as the documented code rather than as a boolean. "Failed" tells whoever is debugging nothing; 422 against 402 against 502 tells them where to look.
Where logs become personal data
An identifier and a model, on their own, describe an object. Joined to a customer, an order or a branch and a timestamp, the same row describes a person's property and their transaction — and that changes how long it may be kept and what has to happen when someone asks for their data to be removed.
Two practical consequences. Set a retention period and actually enforce it, rather than keeping everything on the grounds that storage is cheap; the cost of old logs is not storage, it is obligation.
And separate the two: an operational log keyed on the device, and a customer record that references it. Deleting the second when required then does not blind the first, which still has to answer questions about stock, pricing and spend.
What not to log
- The API key. It belongs in configuration, never in a line of output that gets copied into a ticket.
- Full request and response bodies for every call, indefinitely. That is a way of collecting obligations without collecting answers.
- Personal details that were never needed for the lookup. The device is the subject; the person is a separate record with a separate lifetime.
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.