Tooth numbering

The API uses FDI (ISO 3950) tooth numbers everywhere. Convert from Universal (UNN) before calling — the API cannot detect Universal numbers for you.

Every tooth number in the Relu Automate API is an FDI (ISO 3950) number. That covers:

Input keys — margin_line_18, input_crown_18, …
Parameter values — parameter_values.tooth_nbs entries like crown_18, per-tooth implant fields like tooth11
Output names — die_18, margin_line_18, and the file names inside output zips

There is no Universal (UNN) mode, no auto-detection, and no per-order notation switch. If your system works in Universal numbers, convert to FDI before calling the API.

The API cannot catch every Universal number

Universal numbers 1–10 and 29–32 are not valid FDI numbers, so the API rejects them with a 422 that names the offending key and suggests the FDI mapping. But Universal 11–28 are also valid FDI numbers — for completely different teeth. Send Universal 12 (upper left first premolar) and the API will happily process FDI 12 (upper right lateral incisor). No error, wrong tooth. Conversion on your side is the only safe path.

FDI ↔ Universal mapping

FDI numbers are two digits: quadrant (1–4 permanent, 5–8 deciduous) followed by position 1–8 counted from the midline.

Region	FDI	Universal (UNN)
Upper right	18 17 16 15 14 13 12 11	1 2 3 4 5 6 7 8
Upper left	21 22 23 24 25 26 27 28	9 10 11 12 13 14 15 16
Lower left	31 32 33 34 35 36 37 38	24 23 22 21 20 19 18 17
Lower right	41 42 43 44 45 46 47 48	25 26 27 28 29 30 31 32

Read each row left-to-right as one continuous arch position: FDI 18 ↔ UNN 1, FDI 11 ↔ UNN 8, FDI 21 ↔ UNN 9, FDI 28 ↔ UNN 16, FDI 38 ↔ UNN 17, FDI 31 ↔ UNN 24, FDI 41 ↔ UNN 25, FDI 48 ↔ UNN 32.

Deciduous (primary) teeth are valid FDI input too: quadrants 5–8, i.e. 51–55, 61–65, 71–75, 81–85. Universal labels deciduous teeth A–T; those letters are never accepted — convert them to FDI digits as well.

Worked example: converting a Universal order

Say your lab system holds an upper-right three-unit case as Universal teeth 6, 7, 8 (canine, lateral incisor, central incisor). In FDI those are 13, 12, 11:

UNN 6 → FDI 13
UNN 7 → FDI 12
UNN 8 → FDI 11

So this payload is wrong (the API rejects margin_line_6/7/8 with a 422, since 6–8 aren't valid FDI):

"input_data": {
  "margin_line_6": { "...": "..." },
  "margin_line_7": { "...": "..." },
  "margin_line_8": { "...": "..." }
}

and this one is correct:

"input_data": {
  "margin_line_13": { "...": "..." },
  "margin_line_12": { "...": "..." },
  "margin_line_11": { "...": "..." }
}

The same conversion applies to parameter_values.tooth_nbs (["crown_13", "crown_12", "crown_11"], not ["crown_6", …]) and to reading outputs back (die_13, margin_line_13, …).

Invalid tooth numbers in per-tooth input keys or tooth_nbs values fail the request synchronously with a 422 that names the offending key or value — the order is never created.

Service-specific details

How per-tooth inputs are keyed, and what number gets physically engraved on outputs, is documented per service — for Crown & Bridge Models (per-tooth margin lines, input_crown_* key shapes, and the die engraving parameters), see the Crown & Bridge guide.

FDI ↔ Universal mapping

Worked example: converting a Universal order

Service-specific details

On this page