Identity
Bixel IDs, the two entity kinds, how resolve answers, what an ID guarantees, and the attribution block.
Bixel Identity is the free layer under everything else: one permanent ID per company, two kinds of entity, and one resolver that turns whatever you have (a name, a domain, a registry number) into that ID with evidence. It is unmetered on every plan, the free account included.
Bixel IDs
An ID looks like bxc_6y0d3p6f83jm: the prefix bxc_ and 12 characters from a 30-symbol alphabet (0123456789bcdfghjkmnpqrstvxyz, no vowels, no l), so anyone can write a validator. IDs are opaque: no country, no kind, no sequence. Input is case-insensitive; output is lowercase. bx_ is the API-key prefix and is rejected, never echoed.
What an issued ID guarantees:
- Never reused, never deleted. Every ID ever issued resolves forever: to a current entity, to a redirect, or to a retirement notice. The API never answers 404 for an issued ID.
- Merges keep the trail. When two IDs turn out to be one thing, one survives and the other redirects to it; the answer carries the chain, and a three-deep chain resolves to the terminal survivor.
- Corrections are dated events. A wrong merge or retirement is reversed by a new, evidenced event; nothing is rewritten.
- A well-formed ID that was never issued answers
unresolvedwith reasonunknown_id, notinput_invalid.
Every ID has a page at https://bixel.com/id/<bixel_id>, which forwards to the company record when one is published.
Two kinds
| kind | what it is | how you look it up |
|---|---|---|
brand | an operating presence people know by its own name or domain: a company as the market knows it, a product with its own site | domain, URL, name |
legal_entity | a registered company on an authoritative register | LEI, Companies House number, CIK, name plus jurisdiction |
A kind never changes on an ID. A company with one site and one registration has two IDs and a dated operates link between them; a resolve answer for one always links the other when the link is evidenced. Which ID should you store? The brand ID if you care about the company people know; the legal-entity ID if you care about who signs the contract. Both survive every lifecycle event.
Resolving
GET /v1/resolve?identifier=... takes one input and classifies it itself: a Bixel ID, a domain or URL, an email address (the domain after the @), a LinkedIn or Crunchbase company URL, an LEI (checksum-validated), a CIK, a Companies House number, a Wikidata QID, or a name with an optional jurisdiction. POST /v1/resolve/batch takes a list of the same shape. Full parameters in the reference.
Every parseable request answers HTTP 200 with a result_type; problem documents are for protocol errors only (a missing parameter, an oversize body, authentication).
| result_type | meaning |
|---|---|
resolved | one entity, at or above the inferred evidence tier, with evidence references |
redirected | the input was a merged ID, a former domain or a former identifier; the answer carries the survivor and the chain |
ambiguous | more than one plausible entity; candidates are listed, never picked by popularity |
unresolved | no entity, or evidence below the bar; the reason says why and what would resolve it |
not_a_company | valid input that is not an organisation (a consumer mail domain, a government body) |
retired | the ID existed and was retired with no successor |
input_invalid | the input could not be normalised (a malformed value, a personal profile URL, a key-shaped string) |
Matches carry an evidence tier, attested, corroborated or inferred, and the references behind it; there is no numeric confidence score anywhere in the contract. Reason codes are an open list: tolerate values you have not seen.
Attribution
The identity data is published under ODbL 1.0 with attribution, and every resolve answer, abstentions included, carries the block to pass through:
"attribution": {
"source": "Bixel",
"url": "https://bixel.com/id/bxc_6y0d3p6f83jm",
"license": "ODbL-1.0",
"notice": "from Bixel",
"data_version": "2026-09-21T14:40:12.000Z"
}Works you produce from the data are yours; only an adapted database inherits share-alike. Organisations that cannot accept share-alike license the data commercially through the Enterprise tier.