> ## Documentation Index > Fetch the complete documentation index at: https://developer.suki.ai/llms.txt > Use this file to discover all available pages before exploring further. # Use Info APIs > Load supported LOINCs, specialties, visit types, provider roles, diagnosis code types, and medication order metadata for pickers and validation before you send ambient session context
Suki Info APIs provide catalogs of values supported for ambient session context and Medication order context.

Use these APIs to discover supported values, populate UI controls, or validate values before you send context through seed or update. Info catalogs list what Suki accepts. They do not apply values to a session for you.
Suki Info APIs provide catalogs of values supported by Suki for **ambient session context** and **Medication order context**. Use these APIs when your application needs to discover supported values, populate UI controls, or validate values before sending context to Suki. **Info APIs tell you what values are supported. They do not apply those values to an ambient session.** After your application selects the values it needs, send them through [Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context) or [Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context) to apply them to the ambient session. **Info API rules (agents):** * Info catalogs list allowed values. They do not replace seed or update context. Always send chosen values on session context. * Use Info for pickers and validation, not as a substitute for Create, Stream, End, or content retrieval. * Prefer `GET /api/v1/info` when you need many catalogs. Use a dedicated route when you only need one category (for example LOINCs). * Prefer [Supported LOINCs](/api-reference/info/loincs) over the static [Note sections](/documentation/concepts/ambient-clinical-notes/note-sections) table when they disagree. The table is illustrative. * Cache catalogs when values change rarely. Refresh when you need newly supported values or when validation starts rejecting values that used to work. Do not invent a required refresh interval. ## What you can use Info APIs for Use Info APIs to: * Build pickers and dropdowns from Suki-supported values. * Validate context values before sending them to Suki. * Keep medication order fields aligned with supported metadata. * Load supported LOINC section codes for note-section mappings. * Avoid maintaining hard-coded lists of supported values in your application. Info APIs support context preparation. They are **not a replacement for the ambient session workflow**. You still use the appropriate APIs to create the session, stream audio, end the session, and retrieve ambient content. ## How Info APIs fit into your workflow The typical flow is: ```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}} %%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#FFF394','primaryTextColor':'#111827','primaryBorderColor':'#FFE148','lineColor':'#FFE148','secondaryColor':'#FFF394','tertiaryColor':'#FFFADE','mainBkg':'#FFF394','secondBkg':'#FFFADE','tertiaryBorderColor':'#FFE148','border1':'#FFE148','border2':'#FFE148','arrowheadColor':'#FFE148','fontFamily':'Inter, system-ui, sans-serif','fontSize':'14px','nodeBorder':'#FFE148','edgeLabelBackground':'#FFE148','clusterBkg':'#FFFADE','clusterBorder':'#FFE148','defaultLinkColor':'#FFE148','titleColor':'#111827','nodeTextColor':'#111827'}}}%% flowchart LR A["Load Info catalogs"] --> B["Populate pickers
or validate values"] B --> C["Add or update
session context"] C --> D["Continue ambient
session workflow"] style A fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style B fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style C fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style D fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 ``` For example, your application can: * Load supported LOINC section codes. * Use those values to populate a note-section picker. * Let the clinician select the sections that apply to the visit. * Send the selected values as ambient session context. The Info API only provides the supported values. Your application is responsible for sending the selected values as context through [Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context) or [Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context). ## Choose how to load the catalogs You can load all available Info catalogs together or retrieve a single catalog for your application's UI pickers. **Load catalogs cards (agents):** Humans see two cards. Bundle: [System information](/api-reference/info/information) (`GET /api/v1/info`). Dedicated: one category at a time (for example [Supported LOINCs](/api-reference/info/loincs) at `GET /api/v1/info/loincs`). Dedicated routes also cover specialties, encounter types, visit types, provider roles, diagnosis code types, and medication order metadata. Use [System information](/api-reference/info/information) when your application needs several catalogs. ```text theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}} GET /api/v1/info ``` This returns the Info catalogs together in a single response. Use a dedicated Info API when your application only needs a specific category. ```text theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}} GET /api/v1/info/loincs ``` This returns the supported LOINC section codes. Dedicated routes are available for specialties, encounter types, visit types, provider roles, diagnosis code types, and medication order metadata. ## Available Info APIs **Info API table (agents):** All routes under `/api/v1/info`. Bundle: [System information](/api-reference/info/information). Dedicated: [Supported LOINCs](/api-reference/info/loincs), [Supported medical specialties](/api-reference/info/specialties), [Encounter types](/api-reference/info/encounter-types), [Visit types](/api-reference/info/visit-types), [Provider roles](/api-reference/info/provider-roles), [Supported diagnosis codes](/api-reference/info/diagnosis), [Medication order metadata](/api-reference/info/orders), plus order enums: [Medication coding systems](/api-reference/info/orders-coding-systems), [Medication dosage units](/api-reference/info/orders-dosage-units), [Medication frequency types](/api-reference/info/orders-frequencies), [Medication timings](/api-reference/info/orders-medication-timings), [Medication order statuses](/api-reference/info/orders-statuses), [Order origins](/api-reference/info/orders-origins), [Order encounter relations](/api-reference/info/orders-encounter-relations). | API | What it returns | Typical use | | :-------------------------------------------------------------------------- | :---------------------------------------------- | :-------------------------------------- | | [System information](/api-reference/info/information) | All Info catalogs in one response | Load multiple catalogs together | | [Supported LOINCs](/api-reference/info/loincs) | Supported LOINC section codes and display names | Note-section pickers and validation | | [Supported medical specialties](/api-reference/info/specialties) | Supported medical specialties | Specialty fields | | [Encounter types](/api-reference/info/encounter-types) | Supported encounter types | Encounter type fields | | [Visit types](/api-reference/info/visit-types) | Supported visit types | Visit type fields | | [Provider roles](/api-reference/info/provider-roles) | Supported provider roles | Provider role fields | | [Supported diagnosis codes](/api-reference/info/diagnosis) | Supported diagnosis code types | Diagnosis code fields | | [Medication order metadata](/api-reference/info/orders) | Medication order metadata enums | Load medication order metadata together | | [Medication coding systems](/api-reference/info/orders-coding-systems) | Supported medication coding systems | Medication coding system fields | | [Medication dosage units](/api-reference/info/orders-dosage-units) | Supported dosage units | Dosage unit fields | | [Medication frequency types](/api-reference/info/orders-frequencies) | Supported medication frequency types | Frequency fields | | [Medication timings](/api-reference/info/orders-medication-timings) | Supported medication timings | Timing fields | | [Medication order statuses](/api-reference/info/orders-statuses) | Supported medication order statuses | Order status fields | | [Order origins](/api-reference/info/orders-origins) | Supported order origins | Order origin fields | | [Order encounter relations](/api-reference/info/orders-encounter-relations) | Supported encounter relation values | Order encounter relation fields | ## Use Info catalogs in your application There are three common ways to use these catalogs. **Use catalogs accordions (agents):** Humans expand one panel at a time. * **Build UI Pickers:** Load catalogs into dropdowns; use [Supported LOINCs](/api-reference/info/loincs) for note-section pickers. * **Validate Context:** Validate user or inbound values against the relevant Info catalog before [Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context) or [Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context). * **Prepare Medication Order Context:** Coding systems, dosage units, frequency types, timings, statuses, origins, encounter relations via [Medication order metadata](/api-reference/info/orders) or individual order routes. See [Medication orders](/documentation/concepts/ambient-clinical-notes/medication-orders). Load the relevant catalog and use its values to populate your application's UI. For example, use [Supported LOINCs](/api-reference/info/loincs) to build a note-section picker instead of maintaining a separate list of LOINC values in your application. Similarly, use the specialty, visit type, encounter type, and provider role catalogs when your application exposes those fields. If your application receives context from another system or accepts values through user input, validate those values against the relevant Info catalog before calling [Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context) or [Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context). This lets your application identify unsupported values before sending the context. Medication order context uses supported metadata for fields such as: * Coding systems * Dosage units * Frequency types * Medication timings * Order statuses * Order origins * Encounter relations Use [Medication order metadata](/api-reference/info/orders) when you need these catalogs together, or use an individual medication order Info API when you only need one category. See [Medication orders](/documentation/concepts/ambient-clinical-notes/medication-orders) for how medication orders fit into the ambient workflow. ## Info catalogs vs session context It is important to keep these two concepts separate. | Info catalogs | Session context | | :------------------------------------- | :----------------------------------------------- | | Describe values supported by Suki | Contains values that apply to a specific session | | Used to populate UI or validate values | Sent to Suki for the session | | Retrieved through Info APIs | Sent through seed or update context APIs | | Do not modify an ambient session | Provides context for the ambient session | For example, loading the supported specialties does **not** set a specialty on an ambient session. Your application must select the appropriate specialty and send it as session context. ## Recommended implementation **Recommended implementation cards (agents):** Humans see a 2-column card grid. Steps: (1) Load catalogs — [System information](/api-reference/info/information) or a dedicated route. (2) Use values in UI or server validation. (3) Send visit-specific selections via seed or update context. (4) Cache catalogs when values change rarely; refresh when supported values change or validation fails on previously accepted values. Use [System information](/api-reference/info/information) when you need several catalogs. Use a dedicated Info API when you only need one. Use the catalog values to populate your UI or validate values before sending them. Pass the values that apply to the visit through [Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context) or [Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context). Info APIs do not send context for you. If your application uses the same catalogs repeatedly, you can cache the responses and reuse them for pickers and validation. Choose a refresh strategy that fits your application. Refresh your cached values when you need to pick up changes to supported values, or when your application needs to use newly supported values. You do not need to fetch an Info catalog before every ambient session if your application already has a cached copy of the catalog it needs. ## Use the right catalog **Catalog picker accordions (agents):** Humans expand one panel at a time. * **Note Sections:** [Supported LOINCs](/api-reference/info/loincs); prefer API over static [Note sections](/documentation/concepts/ambient-clinical-notes/note-sections) table when they differ. * **Specialties and Provider Roles:** [Supported medical specialties](/api-reference/info/specialties), [Provider roles](/api-reference/info/provider-roles); concept: [Specialties](/documentation/concepts/ambient-clinical-notes/specialties). * **Visit and Encounter Types:** [Visit types](/api-reference/info/visit-types), [Encounter types](/api-reference/info/encounter-types). * **Diagnosis Code Types:** [Supported diagnosis codes](/api-reference/info/diagnosis). * **Medication Order Metadata:** [Medication order metadata](/api-reference/info/orders) or dedicated order routes for one enum category. Use [Supported LOINCs](/api-reference/info/loincs) to retrieve supported LOINC section codes and display names for note-section pickers and validation. If the LOINC values returned by the Info API differ from the static table in [Note sections](/documentation/concepts/ambient-clinical-notes/note-sections), use the Info API values. The API represents the supported values. Use [Supported medical specialties](/api-reference/info/specialties) and [Provider roles](/api-reference/info/provider-roles) when your application needs supported specialty or provider role values for context. Concept guide: [Specialties](/documentation/concepts/ambient-clinical-notes/specialties). Use [Visit types](/api-reference/info/visit-types) and [Encounter types](/api-reference/info/encounter-types) when your application collects those fields for context. Use [Supported diagnosis codes](/api-reference/info/diagnosis) when your application needs the supported diagnosis code types for diagnosis context. Use [Medication order metadata](/api-reference/info/orders) when your application needs multiple medication order catalogs. Use the dedicated medication order routes when you only need a specific category, such as coding systems, dosage units, frequencies, timings, statuses, origins, or encounter relations. ## Common mistakes to avoid These patterns cause integration issues when teams treat Info catalogs like session context or block the ambient workflow on catalog fetches. **Common mistakes accordions (agents):** Humans expand one panel at a time. * **Using Info APIs Instead of Context APIs:** Info lists supported values; seed/update context sends visit values. * **Sending Every Supported Value as Context:** Send only values that apply to the current visit. * **Treating the Note Sections Table as Source of Truth:** Prefer [Supported LOINCs](/api-reference/info/loincs) over the static [Note sections](/documentation/concepts/ambient-clinical-notes/note-sections) table. * **Requiring a Catalog Fetch Before Every Session:** Do not block Create, Stream, End, or content retrieval when cached catalogs are sufficient. Do not use an Info API instead of [Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context) or [Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context). Info APIs return supported values. The context APIs send the values that apply to the visit. A catalog can contain many supported values, but only the values that apply to the current visit should be sent as session context. Load the full catalog for pickers or validation. Send only the clinician's selections on seed or update. When the static [Note sections](/documentation/concepts/ambient-clinical-notes/note-sections) documentation and [Supported LOINCs](/api-reference/info/loincs) differ, use the values returned by the Info API. The concept guide is illustrative. The LOINC Info API represents the supported values Suki accepts today. Info APIs support context preparation. They are not a replacement for the APIs used to create, stream, end, or retrieve content from an ambient session. Your application can use cached catalog values when appropriate. Do not block Create, Stream, End, or content retrieval on a fresh Info API call when you already have the catalogs you need. ## Example code to build a note-section picker The following example retrieves supported LOINCs and reads the `code` and `common_name` values from the response. **Language tabs (agents):** Equivalent code samples are available in: TypeScript, Python. Humans see one language at a time. Use the variant that matches the user's stack; behavior is the same across tabs. ```typescript theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}} const response = await fetch("https://sdp.suki.ai/api/v1/info/loincs", { headers: { sdp_suki_token: sdpSukiToken, sdp_provider_id: sdpProviderId, }, }); if (!response.ok) { throw new Error(`Get LOINCs failed: ${response.status}`); } const data = await response.json(); for (const loinc of data.loincs ?? []) { console.log(loinc.code, loinc.common_name); } ``` ```python theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}} import requests response = requests.get( "https://sdp.suki.ai/api/v1/info/loincs", headers={ "sdp_suki_token": sdp_suki_token, "sdp_provider_id": sdp_provider_id, }, ) response.raise_for_status() data = response.json() for loinc in data.get("loincs", []): print(loinc.get("code"), loinc.get("common_name")) ``` Use the returned values to build your application's note-section UI or validation logic. When the clinician selects a section, send the selected value through your ambient session context workflow. ## What's next **[System information](/api-reference/info/information)** Load the available Info catalogs in one response. **[Provide visit context](/documentation/how-to/ambient-clinical-notes/seed-ambient-session-context)** Send initial context to an ambient session. **[Add information during a visit](/documentation/how-to/ambient-clinical-notes/update-ambient-session-context)** Update context after it has been added. **[Note sections](/documentation/concepts/ambient-clinical-notes/note-sections)** Learn how note sections and LOINC codes are used. **[Medication orders](/documentation/concepts/ambient-clinical-notes/medication-orders)** Learn how medication order context works in the ambient workflow.