·4 min readapi designaccuracyengineering

An unmeasured signal must never report as a negative finding

Our API told customers that every .de, .ru and .ac.uk domain was 'not newly registered'. We had never checked. Here is the one-line bug and why nulls belong in an API response.

A benchmark run against RDAP — the registry's own record of when a domain was created — turned up one disagreement in seven. Chasing it found a bug with a much larger blast radius than the single domain that surfaced it.

The line

newly_registered: ageDays !== null && ageDays < 30,

Read it carefully. When ageDays is null — RDAP unreachable, a cached failure, or a TLD that publishes no RDAP at all — the expression is false. Not unknown. False.

So a domain we had never checked was reported with exactly the same confidence as one we had checked and found to be ten years old. A caller writing `if (!signals.newly_registered)` could not tell the two apart, because there was nothing to tell apart: the API had flattened them.

How big was it

Bigger than a transient blip. Several large ccTLDs publish no RDAP whatsoever — .de, .ru, .ac.uk among them. Every domain on those TLDs was permanently and confidently reported as established.

A domain registered yesterday is one of the strongest fraud signals there is. Answering 'not new' for an entire national TLD inverts precisely the signal a customer is paying for.

Three states, not two

newly_registered: ageDays === null ? null : ageDays < 30,

null means unknown. It is falsy in JavaScript, so existing `if (signals.newly_registered)` code is unaffected, and the OpenAPI schema and the free tool both now say 'unknown' rather than 'no'.

This was not a new idea in the codebase. `mailbox_exists` already carried the comment `null = couldn't verify (unknown)`, because Gmail and Yahoo accept mail for addresses that do not exist and any vendor claiming certainty there is inventing it. The convention existed; this field simply had not followed it.

The general rule

A signal you did not measure must never be reported as a negative finding.

It is worth auditing your own responses for this. Every boolean that can be computed from an optional upstream is a candidate, and the failure is invisible in testing because the upstream works on your machine.

Try the API this was written about

1,000 lookups a month free, no card. The free tools need no signup at all.

More posts