How I Integrated Beluga Health Into a Telehealth Product

On a recent telehealth project, the client wanted to offer doctor consultations and prescriptions without building a clinician network or a compliance team from scratch. That is exactly the gap an async telehealth platform like Beluga Health fills. This is a case study of how I approached the integration into a Next.js web app, and the parts that actually mattered once real patients started flowing through it.

What Beluga Health Actually Provides

Beluga Health is an async telehealth API. The short version: your product collects patient information, submits an async visit, and a licensed clinician in their network reviews it and either approves a prescription, requests more information, or declines. You are not running the video call or staffing the doctors. You are the front door and the patient experience.

Async is the key word here. Instead of scheduling a live appointment, the patient answers a structured intake questionnaire, and a clinician reviews it on their own time. That model is a good fit for things like prescription refills, common conditions, and follow-ups. It also simplifies your build, because you are handling forms and state rather than real-time media.

The specifics of the API depend on Beluga's current documentation, and you should treat their docs as the source of truth rather than anything I describe here. In broad terms, you get endpoints to create or identify a patient, submit a visit with intake answers, and check or receive updates on visit and prescription status. The exact field names and resource shapes are theirs to define.

Wiring It Into a Next.js App

The most important architectural decision is that all calls to Beluga go through your own backend, never directly from the browser. In Next.js I put this behind API routes (or route handlers in the App Router) so the API key lives only on the server. The client talks to my endpoints, and my endpoints talk to Beluga.

I keep a thin server-side client module that wraps the HTTP calls, attaches auth headers, and normalizes responses into my own types. This matters because their response shape and my database schema should not be the same thing. When their API changes, I want one file to update, not every component. It also gives me a clean place to add retries and logging.

On the data side, I store my own record for each visit keyed to the patient, plus the identifier Beluga returns. I never treat their system as my database. My record holds the local status, timestamps, and a reference to the remote visit, so I can render the patient's history even if a network call fails.

The Patient Intake Flow

Intake is where most of the product effort goes. The patient works through a multi-step form: identity and demographics, the condition or medication they want, and a set of clinical screening questions. I drive this as a wizard with validation at each step, and I only submit the visit to Beluga once everything required is collected and confirmed.

Two things saved me grief. First, I validate on the server before forwarding, because a rejected visit from the clinician side is a much worse experience than a form error. Second, I save intake progress as the patient goes, so a dropped connection or a refresh does not wipe their answers. Medical intake is long, and people abandon long forms.

After submission I show a clear pending state. The patient should understand that a real clinician is reviewing their request and that this is not instant. Setting that expectation in the UI reduced support questions noticeably, because the async model is unfamiliar to people used to instant checkout.

Webhooks and Status, and the Compliance Care

Polling for visit status is tempting but wrong. I set up a webhook endpoint so Beluga can push updates when a visit is approved, declined, needs more information, or a prescription is issued. The handler verifies the request is genuinely from Beluga, updates my local visit record, and triggers any follow-up like notifying the patient. I keep the handler fast and idempotent, since the same event can arrive more than once.

Idempotency is not optional. I store a processed event identifier and skip duplicates, so a retried webhook never double-sends an email or double-updates a record. I also log the raw payloads to a secure store for a while, which makes debugging a stuck visit far easier when a clinician asks what the patient submitted.

The compliance side deserves real respect, not a checkbox. You are handling protected health information, so transport is encrypted, secrets stay server-side, access is logged, and you only collect what the visit needs. Confirm with Beluga and your own legal advisor what falls under their coverage versus yours, including any business associate agreement. I am a developer, not a compliance officer, so I treat those requirements as hard constraints and bring in the right people rather than guessing.

The honest takeaway: integrating Beluga Health is less about clever code and more about disciplined boundaries. Keep their API behind your server, own your data model, make intake forgiving, handle webhooks idempotently, and take compliance seriously. Do that, and you can ship a working telehealth product without becoming a healthcare operator yourself.