# Changelog

Updates to the Nabla Core API — including new features, fields, or endpoints — are released under a new-dated version to ensure stability and predictability. This means these changes won’t affect your integration unless you explicitly opt into the newer version (see [Targeting a specific version](/core-api/guides/api-versioning/usage.md)).

That said, some updates — like internal AI models improvements, bug fixes, or strictly non-breaking changes that don’t affect the schema or observable behavior — may be rolled out across all versions.

Below is a list of all available Core API versions, along with their associated changes.

<!-- -->

### 2026-10-05[​](#2026-10-05 "Direct link to 2026-10-05")

* **E/M coding — additional covered specialties.** [`POST /generate-em-codes-async`](/core-api/reference/server/generate-em-codes-async.md) and [`POST /compute-em-codes`](/core-api/reference/server/compute-em-codes.md) now accept `CARDIOLOGY`, `NEUROLOGY`, and `PSYCHIATRY` on `em_specialty_kind`. These specialties use office/outpatient E/M codes. This change also applies to all prior versions.

* **ChartSync — separated Assessment and Plan.** The `kind` of a `structured_context.source_note` section accepts two new values, `ASSESSMENT` and `PLAN`, for source notes that keep the assessment and the plan in separate sections instead of a single merged one. A source note cannot mix `ASSESSMENT_AND_PLAN` with either of them. `content.type: "SUBSECTIONS"` remains supported on `ASSESSMENT_AND_PLAN` only. Applies to both **Server** and **User** APIs. See the [ChartSync guide](/core-api/guides/chartsync.md).

* New **suggested orders** generation endpoints on both **Server API** and **User API**:

  * `POST /generate-suggested-orders` ([Server](/core-api/reference/server/generate-suggested-orders.md), [User](/core-api/reference/user/generate-suggested-orders.md)) — Extract the orders mentioned in a Nabla-generated note (laboratory tests, imaging studies, medications, procedures, referrals, immunizations, durable medical equipment) as a flat list of suggestions discriminated by `category`: every order carries a `description` and optional `details`, and `MEDICATION` orders additionally carry the structured prescription (`action`, `dose_value`, `dose_unit`, `prn`, frequency, `route`), summarized in their `details`. Optional `encounter_diagnoses_coding`, `patient_demographics` and `source_note` (only its `ASSESSMENT_AND_PLAN` section is used) provide additional context.
  * `POST /generate-suggested-orders-async` ([Server](/core-api/reference/server/generate-suggested-orders-async.md), [User](/core-api/reference/user/generate-suggested-orders-async.md)) — Asynchronous variant of the above, following the standard polling pattern. The result is kept for two hours.
  * `GET /generate-suggested-orders-async/{id}` ([Server](/core-api/reference/server/get-generate-suggested-orders-async.md), [User](/core-api/reference/user/get-generate-suggested-orders-async.md)) — Poll the status and results of an in-progress or completed suggested orders generation.
  * New webhook events [`generate_suggested_orders_async.succeeded`](/core-api/reference/webhook/api-receive-webhook.md) and `generate_suggested_orders_async.failed`, sent when an asynchronous suggested orders generation completes. As for every webhook, payloads follow your organization's pinned API version, so the `succeeded` event is only delivered once your organization is pinned to this version or later.

### 2026-08-25[​](#2026-08-25 "Direct link to 2026-08-25")

* **E/M coding — restricted `specialty` enum.** [`POST /generate-em-codes-async`](/core-api/reference/2026-08-25/server/generate-em-codes-async.md) and [`POST /compute-em-codes`](/core-api/reference/2026-08-25/server/compute-em-codes.md) document only the covered specialties via `em_specialty_kind`: `EMERGENCY_MEDICINE`, `FAMILY_MEDICINE`, `GENERAL_MEDICINE`, `GENERAL_PRACTICE`, `INTERNAL_MEDICINE`, `PEDIATRICS`.

* New **patient instruction translation** endpoint on both **Server API** and **User API**: `POST /translate-patient-instructions` translates already-generated patient instructions from one locale into another, and returns them in the same `{ instructions }` shape as `POST /generate-patient-instructions`. The response ends with a disclaimer, written in the target locale, stating that the text was machine-translated. Both `current_locale` and `new_locale` accept the same locales as the `instructions_locale` field of `POST /generate-patient-instructions`; passing the same value for both returns the instructions unchanged.

* **Structured Assessment & Plan.** Every note section now carries a required `content` union: `{ type: "TEXT", text }` or `{ type: "SUBSECTIONS", subsections }` instead of `text`. On templates with a merged Assessment & Plan section, that section uses `SUBSECTIONS`; all other sections use `TEXT`. Applies to both **Server** and **User** APIs.

  <!-- -->

  * **Note responses** (`/generate-note`, `/generate-note-async`, `/edit-note-with-instructions`) return the Assessment & Plan section as `content.type: "SUBSECTIONS"` with one subsection per clinical problem (`id`, `title`, `text`). Subsection `id` values are stable when the client sends structured `SUBSECTIONS` on input; when the API converts legacy flat A\&P `TEXT`, it assigns new server-generated IDs.
  * **Note request bodies** (e.g. `/generate-normalized-data`, `/generate-patient-instructions`, `/edit-note-with-instructions`) accept `content.type: "TEXT"` or `content.type: "SUBSECTIONS"` on the Assessment & Plan section. `SUBSECTIONS` on any other section or on a template without a merged Assessment & Plan section returns `400 BAD_REQUEST`.
  * **Normalized data** (`/generate-normalized-data`, `/generate-normalized-data-async`) responses include `subsection_id` on conditions, linking each encounter-diagnosis condition back to the Assessment & Plan subsection (`subsections[].id` inside `content`) it was extracted from when the input note uses `content.type: "SUBSECTIONS"` on A\&P. Subsection matching is always on (no `include_corresponding_note_problems` request field) and `corresponding_note_problem` is not returned; use `subsection_id` for join-back. See the [Assessment & Plan guide](/core-api/guides/assessment-and-plan.md).
  * **ChartSync** (`structured_context.source_note`) sections replace the flat `text` field with a required `content` field, using the same `{ type: "TEXT" | "SUBSECTIONS", ... }` union. Prior versions keep flat `text` unchanged. On the `ASSESSMENT_AND_PLAN` kind, sending `content.type: "SUBSECTIONS"` lets the client carry the previous note's per-problem structure forward directly, instead of flattening it to text and having the server re-derive the structure. `SUBSECTIONS` on any other kind returns `400 BAD_REQUEST`. See the [ChartSync guide](/core-api/guides/chartsync.md).

### 2026-07-01[​](#2026-07-01 "Direct link to 2026-07-01")

* New **Server API** endpoints for E/M (Evaluation & Management) CPT code generation (U.S. product release only):

  * [`POST /generate-em-codes-async`](/core-api/reference/2026-07-01/server/generate-em-codes-async.md) — Submit a transcript and note to generate E/M CPT codes asynchronously. The endpoint infers the visit type (if not provided) and determines the MDM level in parallel, then computes the appropriate CPT codes. The result is kept for two hours.
  * [`GET /generate-em-codes-async/{id}`](/core-api/reference/2026-07-01/server/get-generate-em-codes-async.md) — Poll the status and results of an in-progress or completed E/M code generation.
  * [`POST /compute-em-codes`](/core-api/reference/2026-07-01/server/compute-em-codes.md) — Deterministic, fast recomputation of E/M CPT codes from structured encounter inputs (no transcript or note required). Use to recompute codes after the user changes encounter info such as modality, payer, or total encounter time.
  * These endpoints accept `em_specialty_kind` with covered specialties only: `EMERGENCY_MEDICINE`, `FAMILY_MEDICINE`, `GENERAL_MEDICINE`, `GENERAL_PRACTICE`, `INTERNAL_MEDICINE`, `PEDIATRICS`.

* New **asynchronous normalized data generation** endpoints on both **Server API** and **User API**:

  * `POST /generate-normalized-data-async` — start an asynchronous job to extract ICD-10 and LOINC codes from a Nabla-generated clinical note in a FHIR-compliant structure.
  * `GET /generate-normalized-data-async/{id}` — poll the status and retrieve the results of an asynchronous normalized data generation job.

* **Dictation WebSocket** (`/dictate-ws`) — the server may now emit a new `ASYNC_CORRECTION` item on both the **Server API** and **User API**. This item carries a `suffix` and `replacement` pair instructing the client to replace the trailing portion of the dictation that matches `suffix` with `replacement`, allowing the server to refine or fix previously streamed `DICTATED_TEXT` segments after additional processing (e.g. punctuation, formatting, model-based corrections). Clients opt in by setting the new `enable_async_corrections` boolean (defaults to `false`) on the initial `CONFIG` frame.

* **Template-level note customization** — optional `note_template_custom_instructions` (nullable string, same 700-character limit as section `custom_instruction`) for note-wide guidelines on a template:

  * **User API:** [`GET /note-settings/templates/{template_key}/customization`](/core-api/reference/2026-07-01/user/get-note-settings-template-customization.md) and [`PATCH /note-settings/templates/{template_key}/customization`](/core-api/reference/2026-07-01/user/update-note-settings-template-customization.md) for stored settings; applied on [`POST /generate-note`](/core-api/reference/2026-07-01/user/generate-note.md) and async when using profile settings (API version `2025-04-03`+).
  * **Server API:** optional request field on [`POST /generate-note`](/core-api/reference/2026-07-01/server/generate-note.md) and [`POST /generate-note-async`](/core-api/reference/2026-07-01/server/generate-note-async.md).

* **ChartSync — follow-up note generation.** Replaces the free-text `draft_assessment_and_plan` input with a structured `source_note` that describes both the provenance of the seed content and the semantic role of each section. See the [ChartSync guide](/core-api/guides/chartsync.md) for more details.

  * `structured_context.draft_assessment_and_plan` has been **replaced** by `structured_context.source_note` in `/generate-note` and `/generate-note-async` request bodies on both **Server** and **User** APIs.

  * New `supported_source_note_section_kinds` field on the template detail endpoints, listing the semantic kinds the template accepts as source-note inputs.

  * **Migration from `draft_assessment_and_plan`.** The previous field accepted a single free-text string used to seed the Assessment & Plan section. To migrate, move that string into the new structure:

    ```
    // Before

    {

      "structured_context": {

        "draft_assessment_and_plan": "1. Type 2 diabetes — continue metformin..."

      }

    }



    // After

    {

      "structured_context": {

        "source_note": {

          "type": "DRAFT",

          "sections": [

            {

              "kind": "ASSESSMENT_AND_PLAN",

              "text": "1. Type 2 diabetes — continue metformin..."

            }

          ]

        }

      }

    }
    ```

### 2026-06-12[​](#2026-06-12 "Direct link to 2026-06-12")

* **Haitian Creole transcription support.** Haitian Creole (`HAITIAN_HT`) can now be used as a speech locale value on the transcription endpoints (`/transcribe`, `/transcribe-async`, `/transcribe-ws`) of both the **Server** and **User** APIs. Support is experimental and access is limited — please reach out to get access. Haitian Creole cannot be combined with any other locale: when transcribing Haitian Creole, `speech_locales` must contain exactly one entry. This change also applies to all prior versions that take a `speech_locale` or `speech_locales` too — you can specify `HAITIAN_HT` on most of the latest API versions.

* **Removed `family_history` field from normalized data.** The `family_history` field has been removed from the `NormalizedData` response object on both **User** and **Server** APIs (`/generate-normalized-data`). Family-related conditions are already covered through dedicated ICD-10 codes in the standard conditions field.

* **Custom note templates** — templates and sections are now identified by a freetext key (string) instead of a fixed enum. Changes across all existing endpoints:

  <!-- -->

  * `note_template` (enum) note generation request bodies has been renamed to `note_template_key` (string). This only impacts the *Server API*.
  * `template` (enum) in note generation responses has been renamed to `template_key` (string).
  * Section identifiers (`key` / `section_key`) are now freetext strings instead of a fixed enum.

* New **Server API** endpoints to browse available templates:

  <!-- -->

  * `GET /generate-note/templates?locale={locale}` — list all templates available to the organization.
  * `GET /generate-note/templates/{template_key}?locale={locale}` — get metadata and sections for a single template.

* New **User API** endpoints for template customization:

  <!-- -->

  * `GET /note-settings/templates` — list all templates available to the authenticated user.
  * `GET /note-settings/templates/{template_key}` — get metadata and sections for a single template.
  * `GET /note-settings/templates/{template_key}/customization` — get note template customization.
  * `PATCH /note-settings/templates/{template_key}/customization` — update note template customization.
  * `GET /note-settings/templates/{template_key}/customization` and `PATCH /note-settings/templates/{template_key}/customization` replace the now deprecated `GET`/`PATCH /note-settings/note-sections-customization/{template_key}`.

### 2026-04-24[​](#2026-04-24 "Direct link to 2026-04-24")

* Introduce an optional provider `specialty` field. This field lets you set a user's medical specialty. If set, it will for now have impact, but in the near future, this piece of information will be leveraged to improve the dictation, transcription, and note generation.

  <!-- -->

  * Added optional `specialty` field to user management endpoints on the **Server API** (`POST /users`, `PATCH /users/{id}`, `GET /users/{id}`, `GET /users`).
  * On the other **Server API**, the same `specialty` field is available on the request bodies for `/transcribe`, `/transcribe-async`, `/dictate`, `/dictate-async`, `/generate-note`, and `/generate-note-async`.
  * On the **User API**, transcription, dictation, and note generation use the authenticated user's profile specialty instead (no `specialty` field on those request bodies).

* Added optional `encounter_date` field to note generation endpoints (`/generate-note` and `/generate-note-async`) on both **User** and **Server** APIs. When provided, this date grounds relative temporal references (e.g., "last year") in the generated note. Defaults to today's date when omitted.

### 2026-03-16[​](#2026-03-16 "Direct link to 2026-03-16")

* Add new bulk Dot Phrase management endpoints to the **User API**, each supporting up to 100 items per request:

  <!-- -->

  * [`POST /dot-phrases/bulk-create`](/core-api/reference/2026-03-16/user/bulk-create-user-dot-phrases.md) — Create multiple Dot Phrases in a single request.
  * [`POST /dot-phrases/bulk-update`](/core-api/reference/2026-03-16/user/bulk-update-user-dot-phrases.md) — Update multiple Dot Phrases in a single request.
  * [`POST /dot-phrases/bulk-delete`](/core-api/reference/2026-03-16/user/bulk-delete-user-dot-phrases.md) — Delete multiple Dot Phrases in a single request.

* Added `created_at` and `updated_at` timestamp fields to the dot phrase API responses.

* **`/generate-patient-instructions` now returns an error when no patient instructions can be generated.** Previously, this endpoint would silently return a placeholder string (`[Insert your patient instructions here]`) when the note lacked actionable content. It now returns error code `83023` (`NOTE_HAS_NO_PATIENT_INSTRUCTIONS_INFORMATION`) with HTTP 400, allowing clients to handle this case explicitly (e.g., display their own placeholder).

### 2026-02-20[​](#2026-02-20 "Direct link to 2026-02-20")

* Breaking change: JWT audience `us-central1` and `eu-west1` are now deprecated.

  * If you are using the `us-central1` or `eu-west1` regions in the URL of your JWT audiences; use the generic `us` and `eu` instead.

* **Diarization support.**

  * Diarization support for transcription WebSocket sessions (`/transcribe-ws`). Starting with this API version, when `speaker_type=UNSPECIFIED` is set in the configuration of an audio stream, the Nabla transcription engine will perform speaker diarization. For each transcript item, the system will infer and return either `speaker_type=DOCTOR` or `speaker_type=PATIENT`.
  * Diarization support for transcription HTTP endpoints (`/transcribe` and `transcribe-async`). Starting with this API version, the returned

  If there is not enough context to reliably determine whether the speaker is a healthcare provider or a patient, the speaker\_type will remain `UNSPECIFIED`, effectively behaving as if diarization were not enabled.

* The `locale` and `template` fields are now **required properties** of the note request schemas for both Server and User APIs. These fields specify the locale and template used to generate the note and must be included in note data structures.

* The `note` response schema for both Server and User APIs has been updated to include the `locale` and `template` fields, indicating the locale and template used for the generated note.

* The `note_locale` and `note_template` fields have been **removed** from the request bodies of the following endpoints:

  * Server/User API: `edit-note-with-instructions`, `generate-normalized-data`, `generate-patient-instructions` These fields are replaced by `locale` and `template` in the `note` when making requests to these endpoints.

* Changes to the response body of `/generate-normalized-data`:

  * The `is_hcc` and `is_mcc` fields within `conditions` have been moved into the nested `coding` object.
  * A new `alternative_coding` field has been added to `conditions`. This field is an array of ICD-10 codes that are closely related to the primary coding and represent plausible alternative coding for the condition.

### 2025-11-14[​](#2025-11-14 "Direct link to 2025-11-14")

* New optional fields in object `structured_context` for all note generation endpoints:

  <!-- -->

  * `patient_demographics`: Demographic information about the patient.
  * `draft_assessment_and_plan`: Starting text for generating the *Assessment & Plan* section.

* New optional `structured_context` field for the `/edit-note-with-instructions` endpoint.

* Renaming for clarity and consistency:

  <!-- -->

  * Rename `patient_context` to `unstructured_context` in note generation and edit-note-with-instructions endpoints.

  * Rename `previous_note` to `current_note` in note generation endpoints.

  * Rename `active_encounter_diagnoses_coding` to `encounter_diagnoses_coding` in:

    <!-- -->

    * `structured_context` object in both 'generate-note' and 'edit-note-with-instructions' endpoints.
    * normalization (`/generate-normalized-data`).

* Patched on January 7th: Fixed an issue where the `current_note` field was not taken into account during asynchronous note generation.

* Patched on September 16th: `unstructured_context` now accepts up to 10,000 characters (was 700), on this and every later version, for both the note generation and the `/edit-note-with-instructions` endpoints. Generating the note will take longer if you pass a long `unstructured_context`.

### 2025-08-05[​](#2025-08-05 "Direct link to 2025-08-05")

* Add a new optional input field for all note generation endpoints:
  <!-- -->
  * `structured_context`: Structured context about the patient and the encounter, which will be taken into account when generating the note. Currently only includes:
    <!-- -->
    * `active_encounter_diagnoses_coding`: The ICD-10 coding for the patient's active encounter diagnoses. If the template used for the note generation contains an `ASSESSMENT_AND_PLAN` section, these diagnoses will be used for the "by problem" structuration of this section if they are discussed during the encounter.
* Added a new `active_encounter_diagnoses_coding` parameter to `/generate-normalized-data`. If related diagnoses are found in the input note, the call will return in priority the codes passed.

### 2025-07-24[​](#2025-07-24 "Direct link to 2025-07-24")

* Remove `suggested_dot_phrases` from response of `/generate-note` in Server API as it has always been null (Dot Phrases are only applicable for User API).
* Add new CRUD endpoints to manage **Dictation Text Replacements** for a user.
* Extend support for per-section customization options to note generation in French. This change applies to all prior versions too.
* Add new optional `text_field_context` property to dictation WS config to improve dictation quality by providing initial text context.

### 2025-05-21[​](#2025-05-21 "Direct link to 2025-05-21")

* Add new boolean fields `is_hcc` and `is_mcc` to the FHIR condition objects returned by the `/generate-normalized-data` endpoint.

### 2025-05-07[​](#2025-05-07 "Direct link to 2025-05-07")

* Change the dictate WebSocket protocol. The WebSocket dictation protocol evolves to a faster and simpler model, where small units of text —such as individual words, short phrases, or punctuation marks— are sent once and don’t require any further updates. Clients are expected to append each received unit in order, without inserting spaces or applying any formatting. This change introduces the following breaking changes.

  <!-- -->

  * Evolution of configuration options in `CONFIG` frame.

    <!-- -->

    * The `dictate_punctuation` field has been renamed to `punctuation_mode` and is now an enum, with currently one possible value: `EXPLICIT`.
    * The `speech_locale` field has been renamed to `dictate_locale` and is reduced to the five following locales: `ENGLISH_US`, `ENGLISH_UK`, `SPANISH_ES`, `SPANISH_MX` and `FRENCH_FR`.
    * The `enable_audio_chunk_ack` option has been removed, since audio acknowledgement is now always activated.

  * Simplification and renaming of `DICTATION_ITEM` frame:

    <!-- -->

    * The `DICTATION_ITEM` frame type has been renamed to `DICTATED_TEXT`.
    * It has been simplified and now contains only a string `text` property.
    * Fields `id`, `is_final`, `start_offset_ms` and `end_offset_ms` properties have been removed since dictated texts are now necessarily final and are returned in chronological order.

* Add new `code`, `name` and `trace_id` fields in WebSockets error frame JSON body. Also, the `message` field formatting changed (reminder: do not rely on this formatted string but only on the numeric `code`).

### 2025-05-05[​](#2025-05-05 "Direct link to 2025-05-05")

* Add new `corresponding_note_problem` in the conditions returned by `/generate-normalized-data` endpoint. Use the `include_corresponding_note_problems` flag in the input body to enable this feature.

### 2025-04-03[​](#2025-04-03 "Direct link to 2025-04-03")

* Enforce a limit of 700 on the length of the custom instructions per section for note generation endpoints

* Add new **User API endpoints** to allow users to configure and persist their note generation preferences:

  <!-- -->

  * [`GET /note-settings`](/core-api/reference/2025-04-03/user/get-note-settings.md) — Retrieve the user’s current **locale** and **template**. Default values: `note_locale = ENGLISH_US`, `note_template = GENERIC_MULTIPLE_SECTIONS`.
  * [`PATCH /note-settings`](/core-api/reference/2025-04-03/user/update-note-settings.md) — Update the user’s current **locale** and **template**.
  * [`GET /note-settings/note-sections-customization/:note_template`](/core-api/reference/2025-04-03/user/get-note-sections-customization.md) — Retrieve the default **per-section customization** options for a specific template.
  * [`PATCH /note-settings/note-sections-customization/:note_template`](/core-api/reference/2025-04-03/user/update-note-sections-customization.md) — Update the default **per-section customization** options for a specific template.

* Change in User API [`/generate-note`](/core-api/reference/2025-04-03/user/generate-note.md) and [`/generate-note-async`](/core-api/reference/2025-04-03/user/generate-note-async.md) endpoints:

  <!-- -->

  * The following fields have been **removed** from the request body:

    <!-- -->

    * `note_locale`
    * `note_template`
    * `note_sections_customization`

  * These endpoints will now automatically apply the settings stored in the user’s **note settings** and **per-section customization**.

* Change in User API [`/edit-note-with-instructions`](/core-api/reference/2025-04-03/user/edit-note-with-instructions.md) endpoint:

  <!-- -->

  * The optional field `note_sections_customization` has been **removed**.
  * The endpoint will now automatically apply the settings stored in the user’s **per-section customization**, for the locale and note template provided as endpoint parameters.

### 2025-02-25[​](#2025-02-25 "Direct link to 2025-02-25")

* Bilingual support has been added to transcription endpoints and Websocket.
  <!-- -->
  * In request bodies and WS config frame, `speech_locale` property has been removed and replaced by new `speech_locales` property, an array that can contain one or two distinct speech locales.

### 2025-01-07[​](#2025-01-07 "Direct link to 2025-01-07")

* Add a new [synchronous dictation from file upload endpoint](/core-api/reference/2025-01-07/server/dictate.md).

* Add a new [asynchronous dictation from file URL](/core-api/reference/2025-01-07/server/dictate-async.md), with the ability to either:

  <!-- -->

  * poll the result through a [polling endpoint](/core-api/reference/2025-01-07/server/get-dictation-async.md);
  * or receive it via a webhook event.
    <!-- -->
    * Note: If you already have a webhook integration set up, make sure you go to the [Developer Console](https://pro.nabla.com/developers/webhooks) and extend its set of enabled event types to include dictation-related ones.

* Require endpoints host to specify a region, i.e., either `us.api.nabla.com` or `eu.api.nabla.com`, the generic `api.nabla.com` is not supported anymore.

### 2024-12-23[​](#2024-12-23 "Direct link to 2024-12-23")

* Add a new [audio chunk acknowledgement protocol](/core-api/guides/best-practices/transcription-network-resilience.md), this change applies to all prior versions too.
* Require endpoints paths to start with either "/v1/core/server" or "/v1/core/user"; paths like "copilot-api/server," "copilot/server," "copilot-api/user" or "copilot/user" are not supported anymore.

### 2024-11-08[​](#2024-11-08 "Direct link to 2024-11-08")

* Fixed the case for server-to-client frames in Transcribe Websocket. It is now `SCREAMING_SNAKE_CASE` for all the frames, e.g. `transcript_item` becomes `TRANSCRIPT_ITEM`.

### 2024-10-01[​](#2024-10-01 "Direct link to 2024-10-01")

* **New `2024-10-01` major API version. Check the [Migration guide](/core-api/guides/api-versioning/migrating-from-prior-to-2024-10-01.md) for an exhaustive list of the changes.**
* Add support for [OAuth Client authentication](/core-api/guides/authentication.md) flow for server-to-server integrations.
* Add support for [Webhooks](/core-api/reference/2024-10-01/webhook/api-receive-webhook.md) with events sent upon completion of asynchronous tasks like asynchronous note generation.
* Add a new [transcription websocket](/core-api/reference/2024-10-01/server/transcribe-ws.md) with a simpler frames schema, and **support for 35 languages**.
* Add a new [note generation endpoint](/core-api/reference/2024-10-01/server/generate-note.md) with **[per-section customization capabilities](/core-api/guides/note-templates/note-customization.md)**.
* Add a new [asynchronous note generation endpoint](/core-api/reference/2024-10-01/server/generate-note-async.md) with the ability to poll the result through a [polling endpoint](/core-api/reference/2024-10-01/server/get-generate-note-async.md).
* Add a new [transcription from file upload endpoint](/core-api/reference/2024-10-01/server/transcribe.md) with a simpler body schema.
* Add a new [transcription from file upload endpoint](/core-api/reference/2024-10-01/server/transcribe-async.md) with the ability to poll the result through a [polling endpoint](/core-api/reference/2024-10-01/server/get-transcribe-async.md).
* Change endpoints paths to start with either `/v1/core/server` or `/v1/core/user`.
* Change endpoints host to support for direct URL to a specific geographical region, e.g. `us.api.nabla.com/*` instead of just `api.nabla.com/*`.
* Remove or renamed endpoints (still supported on older versions for backward compatibility): `/digest`, `/digest_async`, `/listen`, `/listen-ws`, `/listen_async`, `/generate_normalized_data`, `/generate_patient_instructions`, `/dot_phrases` & `/dot_phrases/{id}`.

### 2024-04-22[​](#2024-04-22 "Direct link to 2024-04-22")

* Add a new endpoint `/generate_patient_instructions` to generate a patient-friendly summary from an encounter.
* Add a new endpoint `/generate_normalized_data` to generate normalized data from a note, available on both the Server API and the User API.
* Add a new WebSocket endpoint `/dictate` for transcribing medical dictation.
* Add a new endpoint `/users/find_by_external_id/:external_id` to fetch a user with a unique external ID from another system.
* Add new endpoints to manage **Dot Phrases** for a user.
* When set on a user, suggest matching Dot Phrases alongside the generated note in the 'digest' endpoint.
* Add four new [templates](/core-api/guides/note-templates/note-templates-sections.md): `GENERAL_MEDICINE_WCC`, `SOAP_WCC`, `GENERAL_MEDICINE_EMERGENCY`, `SOAP_EMERGENCY`.
* Add a `title` property in the note generated by server digest, server digest async, user digest, and user digest async endpoints. The title is a short description of the note content.
* Add a `patient_context` property in `digest` and `digest_async` requests body.
* Add a `PATCH /users/:id` endpoint.
* Add `external_id`, `metadata` and `created_at` on the User object, the external ID and metadata are editable through the patch endpoint.
* Remove `upcoming_appointments_details` from the output of the `/generate_patient_instructions` endpoint. Upcoming appointments details are now included inside instructions starting for this version.
* Remove `note_generation_mode` request property from digest and digest async endpoints.
* Remove `upcoming_appointments_details` from the output of the `/generate_patient_instructions` endpoint. Upcoming appointments details are now included inside `instructions` starting for this version.

### 2024-02-27[​](#2024-02-27 "Direct link to 2024-02-27")

* Add new endpoints: activate-user and deactivate user.
* Add new endpoints to fetch a single user or all users using filters and pagination.
* Add `split_by_problem` to digest and listen-from-file endpoints.
* Add optional `client_request_id` parameter to `/digest` and `/digest_async` endpoints.
* Deprecate `[es-ES, es-MX]` as note generation languages in Core API for digest and listen endpoints.
* Remove `note.section.content: string[]` field, usage to be replaced by `text: string` which is equivalent but formatted.
* Remove the note generation feature from Listen Websocket API (recommend using the dedicated endpoint).

### 2023-06-26[​](#2023-06-26 "Direct link to 2023-06-26")

First version of the API.