A verified badge is a mark a platform puts on an account. Every network has one, and no two mean the same thing.
That is why a single verified: true/false field across platforms is one of the least trustworthy things in a social data API.
Four different claims wearing the same icon
| Platform behaviour | What the badge actually asserts |
|---|---|
| Identity checked against documents | This is who they say they are |
| Paid subscription | They pay for the tier that includes the mark |
| Domain or link ownership | They control a website — not who they are |
| Merchant or business status | Commercial verification, not personal |
One network we read has three separate flags — domain verified, verified merchant, verified identity — that mean three different things. Choosing one of them to populate a single boolean publishes a badge the platform did not grant. So our Pinterest route returns null there and says so.
The federated case
On a federated network, verification is link verification: the account proved it controls a URL. Nobody checked a passport. Filling a verified field from that would claim an identity check that does not exist anywhere in the protocol, which is why the Mastodon profile route leaves it null.
Why null and not false
Because false is a claim. It says the platform looked and did not verify this account. null says we do not have that information. Those are different statements, and a consumer can act on the difference — see unified schema for the general form of the problem.
A provider that returns false everywhere it has no data will look more complete and be less correct.
What to ask a vendor
Not "do you return verified status" — almost everyone says yes. Ask which platforms return null and why. The answer tells you whether they measured the source or filled the column.