Skip to main content
The Partner API lets practice management systems and other platforms embed Everbility’s report writing into their own workflow. Your platform starts a launch session for a client, the clinician writes the report in Everbility under their own login, and your platform retrieves the finished document. Unlike the Public API, which uses per-user API keys, the Partner API is built for third-party platforms: a practice admin connects your app once with OAuth 2.0, and your server acts on behalf of that whole practice.
Partner apps are provisioned manually. Email support@everbility.com to register as a partner and receive your OAuth client_id and client_secret. If you enable webhooks, Everbility also gives you a separate webhook_secret.

​
How it works

​
The three building blocks

Connection

A practice admin approves your app once. You exchange the authorization code for tokens and refresh them on a 90-day rolling window.

Launch session

A single report-writing hand-off. You create it with a clinician email and your client ID, then send the clinician to the launch_url.

Document retrieval

Receive a completion webhook, then pull the rendered report as Markdown or HTML into your platform.

Webhooks

Receive signed session opened, completed, and expired events.

Branding

Download approved assets and add an Open in Everbility button.

​
Base URL

All partner endpoints, including the OAuth token endpoint, live under this prefix. See the API reference for full request and response schemas.

​
Client mapping

Your platform and Everbility each have their own client records. The first time a clinician opens a session for one of your clients, Everbility asks them to link it to an Everbility client (or they create one). The mapping is remembered per connection, so every later session for that external_client_id skips straight to writing.

​
Lifetimes at a glance

​
Security model

  • PKCE is mandatory. Every authorization uses code_challenge_method=S256, in addition to your client_secret.
  • Tokens are opaque and hashed at rest. Everbility stores only SHA-256 hashes of codes, tokens, and your client secret.
  • Webhook signing uses a separate secret. Everbility stores the webhook secret encrypted and decrypts it only when signing a delivery.
  • Refresh tokens rotate. Reusing an already-consumed refresh token revokes the whole token family and flags the connection for re-authorization.
  • Clinicians use their own login. Your platform never handles Everbility user credentials; sessions are bound to a specific clinician by verified email.

​
Start here

1

Get credentials

Email support@everbility.com with your redirect URI and optional webhook URL. Everbility gives you an OAuth client_id and client_secret, plus a separate webhook_secret when webhooks are enabled.
2

Connect a practice

Send a practice admin through the consent flow and exchange the code for tokens.
3

Launch and retrieve

Create a launch session, hand the clinician the launch_url, and retrieve the document after the completion webhook.

​
Before you go live

  • Register a separate partner app, redirect URI, webhook URL, and credential set for each environment.
  • Store OAuth tokens, the OAuth client secret, and the webhook secret in a server-side secret manager.
  • Persist each rotated refresh-token pair atomically so you never reuse a consumed refresh token.
  • Generate a unique Idempotency-Key for each logical launch session and reuse it only when retrying that request.
  • Verify webhook signatures against the raw request bytes, reject stale timestamps, and deduplicate by event ID.
  • Keep session-status polling as a recovery path if webhook delivery reaches its final retry.