Nabla APIs for AI Agents

HealthcareClinical DataJentic-Generated SpecsBearer tokenAgent Ready

www.nabla.com·Developer portal → docs.nabla.com

Nabla API Catalog

2 APIs across 1 product group. All share one credential.

Healthcare2

Nabla Core User APIRun client-side ambient transcription, clinical note generation, dot-phrase management, and custom-dictionary editing for individual clinicians on Nabla.~24 endpoints Nabla Core Server APIIssue user JWTs, manage clinician accounts, and run server-side ambient transcription, note generation, normalization, and patient-instruction operations on Nabla's clinical AI platform.~19 endpoints

Which Nabla API should I use?

I want to...	Use	Why
Issue OAuth tokens and mint per-clinician JWTs	Nabla Core 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 Core 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 Core 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 Core User API	Dot-phrase and custom-dictionary operations are exposed only on the User API.
Transcribe an encounter and produce a structured digest	Nabla Core 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.

Install Jentic One Beta

Connect the Nabla APIs to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Nabla APIs, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Why Jentic?

What agents get from Jentic-routed access to this vendor.

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 isolation

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.

FAQs

Specific to using Nabla APIs through Jentic.

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.

BOOK A DEMO

Start Connecting APIs to Your AI Agents

Browse thousands of APIs and connect them all to your agent with Jentic One. One layer, one credential — every API your agent needs.

Book a Demo

For Agents

APIs2 in catalogue

Endpoints43 indexed

AuthBearer token — 1 credential for all 2 APIs

ProvenanceJentic-generated specs

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.

Nabla is clinically tuned ambient documentation rather than raw speech-to-text: the same encounter audio yields a structured digest, ICD-normalized data, and plain-language patient instructions. It splits cleanly into a server-side API for auth, user lifecycle, and orchestration and a user-side API for the operations a clinician runs live in their own app.

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

Credentials: Both APIs use HTTP bearer authentication, but the credentials differ: the Server API holds an OAuth token and mints per-clinician JWTs, and those JWTs are the bearer credential the User API expects, so one server credential ultimately backs both surfaces.

All 2 Nabla OpenAPI specs are Jentic-generated and indexed by Jentic, kept validated and agent-ready.

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.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fnabla.com" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fnabla.com" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Once connected, ask your agent something like: “provision a clinician and turn their visit audio into a structured note”.

What AI Agents Can Do with Nabla

Each workflow spans multiple Nabla APIs. Jentic routes each operation to the right API automatically.

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.

APIs used

Nabla Core Server API + Nabla Core User API

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.

APIs used

Nabla Core Server API + Nabla Core User API

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.

APIs used

Nabla Core Server API + Nabla Core User API

Intent-based discovery

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.

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.

Nabla APIs for AI Agents

Nabla API Catalog

Healthcare2

Which Nabla API should I use?

Connect the Nabla APIs to your agent

Why Jentic?

FAQs

Start Connecting APIs to Your AI Agents

What AI Agents Can Do with Nabla

If you need a different Healthcare vendor