canonical: https://jentic.com/apis/nabla.com

# Nabla APIs

Nabla is an AI clinical assistant that turns ambient encounter audio into structured notes, normalized clinical data, and patient instructions. Its two APIs split the work by surface: the Core Server API runs backend integrations, issuing OAuth tokens, provisioning clinician accounts, minting per-user JWTs, and running server-side transcription, digest, normalization, and patient-instruction operations, while the Core User API powers clinician-facing apps with in-session transcription, note and digest generation, dot-phrase management, custom-dictionary tuning, and JWT refresh and logout. Jentic publishes and maintains the only available OpenAPI specifications for both, keeping them validated and agent-ready.

## For AI agents

Across Nabla's two APIs an agent can provision clinician accounts and mint per-user tokens on the server side, then transcribe encounter audio, generate structured clinical digests and notes, normalize data into ICD codes, produce patient instructions, and manage per-clinician dot phrases and custom dictionaries on the client side.

## Scope

Use for: Ambient clinical documentation on Nabla: transcribing encounter audio, generating structured digests and notes, normalizing data into ICD codes, producing patient instructions, provisioning clinicians, and managing dot phrases and custom dictionaries.

Not supported:
- billing claims submission
- prescription writing
- appointment scheduling
- raw non-clinical transcription
- EHR record storage

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| Nabla Core User API | healthcare | 24 | Run client-side ambient transcription, clinical note generation, dot-phrase management, and custom-dictionary editing for individual clinicians on Nabla. |
| Nabla Core Server API | healthcare | 19 | Issue user JWTs, manage clinician accounts, and run server-side ambient transcription, note generation, normalization, and patient-instruction operations on Nabla's clinical AI platform. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Issue OAuth tokens and mint per-clinician JWTs | nabla-server-api | The Server API owns POST /oauth/token and POST /jwt/authenticate/{user_id}; the User API only refreshes and revokes an existing token. |
| Provision, deactivate, or look up clinician accounts | nabla-server-api | User lifecycle operations including find_by_external_id live only on the Server API. |
| Run transcription and note generation inside a clinician's app session | nabla-user-api | The User API drives client-side /listen, /digest, and note generation under a per-clinician JWT. |
| Manage dot phrases or custom dictionary entries | nabla-user-api | Dot-phrase and custom-dictionary operations are exposed only on the User API. |
| Transcribe an encounter and produce a structured digest | nabla-server-api | Both APIs expose /listen and /digest; choose the Server API for backend batch orchestration and the User API for in-session device calls. |

## Cross-API use cases

### Onboard a clinician then document their first visit

Provision a clinician on the Server API, mint their JWT, then run in-session transcription and digest generation on the User API from the clinician's own app. The Server API handles account creation and token issuance while the User API handles the live encounter, giving one end-to-end path from HR onboarding to a completed note.

Example prompt: Call POST /users then POST /jwt/authenticate/{user_id} on the Server API, hand the token to the User API session, and call POST /listen and POST /digest to produce the clinician's first structured note.

### Backend orchestration with a clinician-facing front end

Split a documentation product so the backend issues tokens and normalizes data server-side while the clinician app runs transcription and edits dot phrases in-session. The Server API mints JWTs and runs normalization for downstream systems; the User API surfaces the clinician's personal shortcuts and dictionary in the note editor.

Example prompt: Mint a JWT via POST /jwt/authenticate/{user_id} and run POST /generate_normalized_data on the Server API, then on the User API list POST /dot-phrases for the clinician's note editor.

### Offboard a departed clinician and revoke their session

When HR offboards a clinician, deactivate their account server-side and end any active device session on the User API. The Server API deactivates by external HR id while the User API revokes the live JWT, closing both the account and the session in one flow.

Example prompt: Look up the user via GET /users/find_by_external_id/{external_id} and call POST /users/{id}/deactivate on the Server API, then POST /jwt/logout on the User API to end the device session.

## Why Jentic

- **Setup:** Wiring Nabla by hand means running the OAuth token and JWT flows, holding the bearer credential, and picking the right regional host under {region}.api.nabla.com for each surface. Through Jentic you install once, add the Server and User APIs from the Jentic directory, store the credentials once, and your agent calls both.
- **Permission scoping:** Your own rules decide which Nabla operations the agent may call across the two APIs, so you can allow digest generation and dot-phrase edits while leaving account creation and JWT logout out unless you add them. Where Nabla puts the clinician id in the path, a rule can pin the agent to one user.
- **Credential handling:** Your Nabla OAuth token and per-clinician JWTs are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search the Jentic directory by intent such as 'transcribe a clinical encounter' or 'add a Nabla dot phrase', and Jentic returns the matching operation from the Server or User API with its input schema so the agent calls the right endpoint.

## Related vendors

- **DrChrono** — EHR of record where Nabla-generated notes and normalized data are typically written back.
- **athenahealth** — Enterprise EHR destination for Nabla's structured digests and ICD-normalized clinical data.
- **Deepgram** — General-purpose speech-to-text alternative when you need raw transcription rather than clinically tuned notes.

## FAQ

### What is the difference between the Nabla Core Server API and the Core User API?

The Server API is for backend integrations: it issues OAuth tokens, provisions and deactivates clinician accounts, mints per-user JWTs, and runs server-side transcription, digest, normalization, and patient-instruction operations. The User API is for clinician-facing apps: it runs in-session transcription and note generation, manages dot phrases and custom dictionaries, and refreshes or revokes the clinician's JWT. Backends use the Server API; the clinician's own device or web client uses the User API.

### Can one credential work across both Nabla APIs?

Not directly, but they are linked. The Server API obtains an OAuth token and mints per-clinician JWTs, and those JWTs are exactly the bearer credential the User API expects. So a single server-side setup backs both surfaces, with the Server API producing the tokens the User API consumes.

### Which Nabla API should an agent start with?

Start with whichever surface owns the operation. Account creation, OAuth, and JWT minting live only on the Server API, while dot phrases, custom dictionaries, and JWT refresh or logout live only on the User API. Transcription and digest generation exist on both, so pick the Server API for backend batch work and the User API for calls made inside a clinician's live session.

### Is Nabla just speech-to-text?

No. Nabla is clinically tuned rather than general transcription. The same encounter audio produces a structured clinical digest, normalized data such as ICD codes, and plain-language patient instructions, across both the Server and User APIs. If you only need raw transcription you would use a general speech-to-text service instead.

### What can an AI agent do across the Nabla APIs?

An agent can run the full documentation lifecycle: provision a clinician and mint their token on the Server API, then transcribe an encounter, generate the digest and note, normalize the data, produce patient instructions, and manage the clinician's dot phrases and custom dictionary on the User API. Through Jentic the agent finds the right operation by intent across both APIs rather than browsing reference docs.

### Does Nabla store patient records or handle billing?

No. These APIs cover ambient documentation only. They do not submit billing claims, write prescriptions, schedule appointments, or store records as an EHR. Normalized notes and instructions are typically written back to a separate EHR of record such as DrChrono or athenahealth.

### Are the Nabla OpenAPI specs official?

Nabla does not publish OpenAPI specifications. Jentic generates and maintains the specs for both the Core Server API and the Core User API, validated against the live APIs and kept up to date so agents and developers can call them through structured tooling.