Building a Telehealth Product on Top of the MD Integrations API

On a recent project I built the patient-facing side of a telehealth product where the clinical work was handled by a white-label API rather than by doctors we hired directly. The platform I worked with was MD Integrations, which connects a product to a network of licensed clinicians for asynchronous consultations and prescriptions. The appeal for the client was simple: they wanted to own the brand and the patient experience, but they did not want to recruit clinicians or carry the compliance weight of running a clinical practice in every state. Here is how that integration actually came together and the decisions that mattered.

What the API actually does for you

It helps to be clear about the division of labor. Your product owns the funnel: marketing, account creation, the intake questionnaire, payment, and the dashboard where a patient sees their results. The telehealth API owns the clinical layer: routing a case to a clinician who is licensed in the patient's state, the clinician review, and the prescription that flows to a pharmacy. You are essentially building a thin clinical SaaS on top of someone else's medical infrastructure.

That framing changed how I scoped the build. Most of my code was not medical logic at all. It was data collection, validation, state management, and reacting to events that the API sent back to me. The clinical decisions happened on the other side of an HTTP boundary, and my job was to give the clinician a clean, complete case and then reflect their response back to the patient honestly.

The intake questionnaire is the real product

An async consultation lives or dies on the quality of the intake. The clinician never speaks to the patient in real time, so the questionnaire has to capture everything a doctor would normally ask in a visit: medical history, current medications, allergies, contraindications, and condition-specific questions. I modeled this as a structured set of question objects rather than a static form so the client's medical advisor could add or reorder questions without a deploy.

Two things saved me pain here. First, I validated answers on the client and again on the server before anything was submitted, because a half-complete case wastes a clinician's time and gets bounced back. Second, I kept the questionnaire schema versioned. When the medical team revised a question, older submitted cases still needed to render with the exact wording the patient originally saw, which matters for the medical record.

I also separated identity and eligibility data from clinical answers. Things like the patient's state of residence, date of birth, and a photo ID often gate whether a case can even be created, and surfacing those failures early is much kinder than letting someone finish a long form and then rejecting them.

Submitting cases and listening for what comes back

Once intake is complete and payment clears, you create a patient record on the platform and then submit a case tied to that patient. The submission carries the questionnaire answers and any required uploads. From that point the flow is asynchronous, so you do not sit and wait on a response. I treated the case as a state machine in our own database: submitted, under review, more information requested, approved, prescription sent, or declined.

The transitions between those states come in through webhooks. The clinician might message the patient asking for a clearer photo, approve the case, write a prescription, or decline. Each of those is an event you have to receive, verify, and act on. I made every webhook handler idempotent because providers retry deliveries, and processing the same case-approved event twice should never charge a card twice or send two notifications. I keyed handlers on the event identifier and recorded what I had already processed.

Prescription status deserves special care because it is the part patients ask about most. A prescription can be written, sent to a pharmacy, filled, or shipped depending on how fulfillment is wired up. I never inferred those states from timing. I only moved our record forward when the webhook told me to, and I logged the raw payload so support could reconstruct exactly what happened on any given case.

Testing and compliance you cannot skip

I built the entire flow against the sandbox environment first and never tested with real patient data. The sandbox lets you create fake cases and trigger clinician responses so you can exercise every branch of your state machine, including the unhappy paths like a declined case or a request for more information. I wrote integration tests that mocked each webhook event and asserted the patient saw the correct status and notification.

On compliance, the practical rules were straightforward but non-negotiable. Patient data is protected health information, so transport is encrypted, access is logged, and we minimized what we stored on our side by leaning on the platform as the system of record for clinical data. Webhook endpoints verified signatures so no one could spoof an approval. And I was careful that the product never implied a guaranteed outcome, because the clinician can always decline, and the interface has to make that a normal, expected result rather than an error.

The lesson I took away is that integrating a clinical API is mostly an exercise in honesty and discipline. Collect complete information, reflect the real clinical state back to the patient without embellishment, and assume every event can arrive twice or out of order. Get those right and the white-label model lets a small team ship a credible telehealth product without becoming a medical practice overnight.