Send an Inbox prescription

Prescription input is optional. First verify the file flow in the Inbox intake quickstart. Prescription information helps Relu automate which CAD service runs for the case.

You can provide prescription information in two ways. If your system already has structured procedure, tooth, and material fields, send source_prescription when you call POST /inbox-cases. If the information comes from a scanner, pass its raw case record in metadata.additional_metadata.<scanner>. Relu can extract prescription information from reviewed scanner profiles, so you do not need to map every scanner field yourself.

Do not put raw scanner metadata inside source_prescription.

Pass scanner metadata

Keep the scanner response under its scanner namespace in metadata.additional_metadata. Do not rename the fields inside that response. This example uses an iTero case record:

{
  "external_case_id": "CASE-1042",
  "source": "itero",
  "metadata": {
    "additional_metadata": {
      "itero": {
        "procedure_name": "Crown",
        "case_type": "Restorative",
        "preps": [{ "AdaId": 8, "UnitTypeId": 2 }]
      }
    }
  },
  "files": [{ "file_id": "<upper_file_id>" }, { "file_id": "<lower_file_id>" }]
}

Relu currently has reviewed prescription profiles for 3Shape, 3DISC, DScore, iTero, Medit, Panda, and Shining 3D. Relu keeps metadata from other scanners, but does not use it to select a CAD service until a profile has been reviewed.

If the scanner also returns metadata for each file, send those records as file-level source_metadata. See Classify Inbox files for both metadata envelopes.

Structured prescription example

{
  "external_case_id": "CASE-1042",
  "files": [{ "file_id": "<upper_file_id>" }, { "file_id": "<lower_file_id>" }],
  "source_prescription": {
    "schema_version": 1,
    "prescription_id": "rx-1042",
    "revision": "7",
    "status": "submitted",
    "authored_at": "2026-08-21T09:15:00Z",
    "author": {
      "source_author_id": "doctor-18",
      "display_name": "Dr Example",
      "role": "doctor"
    },
    "source_catalog_version": "2026.4",
    "items": [
      {
        "item_id": "rx-item-1",
        "procedure": { "code": "crown", "label": "Crown" },
        "product": { "code": "LAB-CROWN-XL", "label": "Custom crown" },
        "scope": { "kind": "tooth", "teeth_fdi": [11] },
        "attributes": {
          "material": { "code": "zirconia", "label": "Zirconia" },
          "shade": "A2",
          "retention": "cemented"
        },
        "notes": "Match the adjacent tooth."
      }
    ],
    "notes": "Doctor-authored case note."
  }
}

Use stable prescription and item IDs. revision is your source revision, not a Relu version. In this create-only integration, changing the prescription and reusing the same case identity returns the normal idempotency conflict. Source updates are not part of this phase.

Procedure codes

Use a canonical Relu procedure code when your system has a clear match:

• Fixed restorative: crown, pontic, bridge, veneer, inlay, onlay, overlay, table_top, coping, post_and_core, telescope_primary, telescope_secondary, wax_up, restoration.
• Implant restorative: custom_abutment, scan_abutment, offset_substructure, implant_restoration.
• Removable prosthodontic: complete_denture, partial_denture, denture_coping, artificial_tooth, denture_replica, custom_tray, wax_rim, denture.
• Orthodontic: clear_aligner, fixed_orthodontic_appliance, removable_orthodontic_appliance, orthodontic_appliance, indirect_bonding_tray, tooth_positioner, retainer.
• Oral appliances: occlusal_splint, night_guard, sports_guard, anti_snoring_appliance, bleaching_tray, oral_appliance.
• Surgical: surgical_guide, implant_planning.
• Models: working_model.
• Diagnostic and other: study_model, diagnostic_wax_up, oral_examination, gingiva_mask, soft_tissue, missing_tooth, other, unknown.

restoration, implant_restoration, denture, orthodontic_appliance and oral_appliance name only the treatment category. Use them when your system records the category but not the specific item.

Do not guess. If no canonical code fits, send your own code and a readable label. Relu accepts the case, retains the source input, and exposes that value as unmapped for review. The same rule applies to product: product codes are source-native and do not block intake.

Unrecognized procedure, product, and material values appear in prescription.unmapped using the source code, or the label when no code was provided. source_prescription retains both the code and label. For a recognized procedure, an unrecognized material also remains in the indication's attributes.material.raw field so it stays associated with that item.

Scope and attributes

Direct integrations use permanent FDI tooth numbers. A scope is one of:

{ "kind": "tooth", "teeth_fdi": [11, 12] }
{ "kind": "jaw", "jaws": ["upper"] }
{ "kind": "full_mouth" }
{ "kind": "unscoped" }

See Tooth numbering before converting another notation. Invalid or duplicate FDI values return 422.

Optional attributes cover support, retention, provisional work, anatomy, veneering, material, shade, color, and implant system. Use shade for a tooth shade and color for any other color, such as a denture base or blank color. Keep the source code and label when available. The OpenAPI model is the source of truth for allowed enum values and limits.

Optional lab work specification

Add lab_work_specification only when the lab or its software explicitly authored a separate work specification. The following property belongs inside source_prescription; it is not a top-level Inbox case field:

{
  "lab_work_specification": {
    "specification_id": "lab-spec-1042",
    "revision": "2",
    "items": [
      {
        "item_id": "lab-item-1",
        "procedure": { "code": "crown" },
        "scope": { "kind": "tooth", "teeth_fdi": [11] }
      }
    ],
    "notes": "Lab-authored manufacturing note."
  }
}

Do not copy or infer the doctor's request into this field. Relu retains the lab specification separately and does not use it to overwrite the doctor prescription projection.

Stored source and derived result

The Inbox case response contains two different fields:

• source_prescription is the validated source-authored input.
• prescription is Relu's read-only, versioned projection with normalized indications, confidence, provenance, and unmapped values.

File or scanner evidence remains stored on the files. When source_prescription exists, later automatic derivation does not overwrite its doctor-authored facts.