---
title: "Facts for one allele, prefix, group, deleted name, or reported shorthand"
method: GET
path: "/v1/allele/{name}"
---

# Facts for one allele, prefix, group, deleted name, or reported shorthand

`GET /v1/allele/{name}`

## Request

- Base URL: `https://api.hlaverify.com`
- URL: `https://api.hlaverify.com/v1/allele/{name}`
- Auth: one of:
  - none
  - API key in header `X-API-Key`

Accepts what /v1/normalize accepts: current names at 1-4 fields, legacy spellings (A*0101, Cw*0702, Cw*07:02), deleted names, G/P group names, the XX code (A*02:XX), two-field A*02:01g and an optional HLA- prefix. A shorthand answers with the facts of the name it stands for plus 'resolves_to' and a flag (deprecated_name, xx_code, lg_notation); an NMDP multiple allele code (A*02:AB) returns status mac_code, recognised but not expanded. 'serology' values are WMDA serological equivalents as published in rel_dna_ser.txt: an antigen number, '?' for an undetermined equivalent, or '∅' for none (null); the lab routes report these as 'uncertain' and 'null'. valid_prefix results also carry 'resolution' ({fields, level, distinguishes}): what a name with fewer than four fields does and does not distinguish, so a lab that typed to that resolution on purpose knows the member count is not telling it the typing is ambiguous. Class I (A/B/C) names carry a trailing 'ligands' object (leader_21, bw, c_group, kir_ligand; see /v1/typing/check).

## Path parameters

- `name` string, required

## Response `200`

assigned | valid_prefix | group | deleted | mac_code (+ resolves_to and flags for a shorthand)

## Other responses

- `404`: not in this release

---

[API](https://skmtc.dev/hlaverify/apis/hla-verify.md) · [All operations](https://skmtc.dev/hlaverify/apis/hla-verify/llms.txt) · [OpenAPI document](https://skmtc.dev/hlaverify/apis/hla-verify/revisions/40cd5e7d134d?raw)