Partner Intake API01/11

One request, and your patient is in care.

Send us a patient from your system. We create the record, open a clinical queue item, and put their intake forms in front of them, all in a single call you can safely repeat.

Partner Intake API Integration overview Arrow keys to advance

SignalIntake accepted

What it is02/11

A clinical back end you can call, instead of one you have to build.

You own the patient relationship and the front end. Everything behind the handoff, from licensed provider matching through clinical review, prescribing and fulfilment, runs on our side under our clinical entity.

Calls to integrate: 1One POST per patient. No SDK, no polling loop, no queue for you to drain.
Required fields: 3Name, email, and the state the patient is in. Everything else is optional.
Duplicate records: 0A repeated call returns the original patient rather than creating a second one.
Typical time to live: DaysMost partners are sending real intakes within a week of receiving a key.

Presenter note

This is the whole pitch. If the room is non technical, spend most of your time on this slide. The four numbers are the argument. Build it yourself means clinicians licensed in every state, medical records software, and audits. Call us means one request.

You could build all of this yourself. People do. It means clinicians licensed in every single state you want to sell into, and then the software those clinicians live in, the medical record, the charting, the prescribing. Then it means an audit trail that holds up when somebody official asks to see it. That is not a sprint, that is a company inside your company, and it is the part that keeps working long after launch. The other option is that you send us one request, and everything I just described is already standing behind it. Same outcome for your patient, and none of it on your roadmap.

The handoff03/11

Four steps, and only two of them are yours.

The boundary is deliberate. You stop at the moment a patient is ready for care, and we pick them up there.

Step 01

You capture the patient

Your funnel, form or checkout collects their details, however you already do it.

Your system

Step 02

You post the intake

One authenticated call carrying the patient's name, email and state.

Your system

Step 03

We open the chart

A patient record and a clinical queue item, returned to you with identifiers you can store.

TrueEval

Step 04

The patient completes intake

They get a secure link to a health history baseline and a form specific to their treatment.

TrueEval

Who talks to the patient

By default we email the intake link. If you would rather keep every message in your own brand and voice, say so and we will hand you the link and stay silent.

Presenter note

Point at the two tags. The two green tags say Your system and they stop at step two. That is the message: their work ends the moment a patient is ready for care. Everything clinical after that is our liability, not theirs.

There are four steps between a signup and a patient in care, and only the first two are yours. Your patient fills in your form, your system sends us one request, and at that point you are done. From there we take the identity check, the clinician, the state licensing, the record, the prescription and the follow up. That line in the middle is the important part of this slide. Everything on our side of it is our responsibility and our liability, not yours. So when you are deciding how much engineering to budget for this, the honest answer is two steps.

What you send04/11

A complete, working request fits on one screen.

Three fields are required. The rest sharpen the clinical picture, and you can add them at your own pace once you are live.

patient_nameFull name, as one string.

patient_emailThe patient's identity for the intake link.

patient_stateTwo letter code. Providers are licensed per state, so this decides who is allowed to see them.

external_order_idYour own reference. This is what makes a repeated call safe.

treatment_typeWhat they are coming in for. We infer it if you leave it out.

Requestcurl

# One patient, one call.
# Your base URL is issued with your key.
curl -X POST "$TRUEEVAL_BASE/external-intake-webhook" \
  -H "x-api-key: te_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "patient_name":      "Jordan Reyes",
    "patient_email":     "jordan@example.com",
    "patient_state":     "TX",
    "treatment_type":    "glp1",
    "external_order_id": "ORD-2026-44817"
  }'

Phone and address

Send a phone number and we can text the intake link as well as email it. Send an address if anything will ship to the patient.

In plain English

If you can give us a name, an email address and a state, you can send us a patient. Everything else only makes the clinician's job easier.

Presenter note

Skip fast if nobody codes. For engineers, walk the curl. For everyone else say three fields, name, email and state, then move on. The state field is worth one sentence: it decides which licensed provider is allowed to see the patient.

That is the whole integration, right there on one screen. A name, an email, and the state the patient lives in. Three fields. Everything else on that list is optional, and all it does is save our clinician a question later. The state field is the one worth pausing on, because it is not an address, it is a routing decision. It decides which licensed provider is allowed to see that person at all, and we enforce that on our side so you never have to think about it. If your form already collects those three things, and it almost certainly does, you already have everything you need to send us.

What comes back05/11

Two identifiers worth writing down.

201 Createdabridged

{
  "success":           true,
  "patient_id":        "8f14e45f…",
  "queue_item_id":     "c9a2d7b1…",
  "status":            "pending_intake",
  "intake_link":       "https://…",
  "treatment_program": "GLP1 Weight Management",
  "email_sent":        true
}

patient_idOur permanent identifier for this person. Every future conversation about them starts here.

queue_item_idThis specific episode of care, which is not the same thing as the patient.

intake_linkTheir secure form address, which is what you send if you are handling the messaging.

statusWhere the episode starts. Useful on your own dashboards.

Store both

Partners who keep only the patient identifier end up unable to say which visit they are asking about. Keep the pair together.

In plain English

Save the two ID numbers we hand back. One says who the patient is. The other says which visit you are talking about.

Presenter note

One ask only. The only thing you need them to agree to is storing two identifiers. Patient is the person, queue item is the visit. Partners who keep only the first one end up unable to tell us which visit they are calling about.

When you call us, we hand you back two numbers, and I would ask you to write both of them down in your own database. The first one is the person. That never changes, it is them, forever. The second one is the visit, so this particular consultation, this particular prescription. People remember the first and forget the second, and then three weeks later they call us asking about a patient who has been through twice, and nobody can tell which visit we are talking about. Keep both and any question you ever have about a patient, we can answer in seconds.

Reliability06/11

The failure that creates two patients cannot happen here.

The dangerous network failure is not the one that fails. It is the one that succeeds on our side and times out on yours. You send it again, and now one person has two charts.

Sending your own external_order_id closes that. We key on it, so a repeat of the same intake returns the original result rather than creating anything new.

Recommended

Generate the reference once, when the intake is first created in your system, and not once per attempt. Then repeat freely on timeouts and server errors.

200 OKsame reference sent twice

{
  "success":       true,
  "deduplicated":  true,
  "patient_id":    "8f14e45f…",
  "queue_item_id": "c9a2d7b1…",
  "message":       "Request already processed"
}

Same identifiers, no second chart, and no second email to the patient. The status code tells you which happened: 201 created something new, 200 found it already there.

In plain English

If your server never hears back from ours, send the identical request again. You get the same patient back, not a second one.

Presenter note

The slide engineers care about. Duplicate patient charts are a real fear in this industry. Say it plainly: send us your own reference number and a repeated call returns the original patient rather than making a second one. Engineers relax here.

Here is the failure everybody in this industry worries about. You send a request, our answer gets lost somewhere on the way back to you, and now you genuinely do not know whether it worked. So you send it again, and you have just created a second chart for the same human being. That cannot happen here. You attach your own reference number to the request, and if we have seen that number before we hand you back the original patient instead of making a new one. So the rule for your developer is simple. If you are unsure, send it again. Repeating a request is always safe.

Access and trust07/11

Your key does exactly what it was issued to do, and nothing else.

Scoped by design

Keys carry named permissions. An intake key can create patients and open queue items. It cannot read anyone else's data.
If a permission is missing, the response names it, so you never have to guess.

Stored as a hash

We keep a one way hash, never a readable copy. Nobody at TrueEval can look your key up.
A lost or exposed key is replaced rather than recovered. Rotation runs with an overlap window so you switch across without downtime.

Clinically bounded

State decides which licensed provider may see a patient. That routing is enforced on our side, not trusted from yours.
Every access to a chart is attributed and auditable.

In plain English

Your key opens one door and no others. We cannot read it back to you. A patient in Texas is only ever seen by someone licensed in Texas.

Presenter note

Expect the security question. This is where procurement wakes up. Stick to what is true: the key is scoped, we store only a one way hash, and state licensing is enforced on our side. Do not promise that keys expire on a timer, that is not shipped yet.

Let me get ahead of the security question, because it is the right question to ask. Your key can do exactly one thing, which is create patients. It cannot read anybody else's data, it cannot read yours back, it cannot reach anything it was not issued for. On our side we do not even store the key, we store a one way hash of it, which means nobody here can look yours up and nobody who steals our database gets a working key. And the clinical side is enforced the same way. Somebody in Texas is only ever seen by a provider licensed in Texas, and that is decided by us, not trusted from you. If your security team wants to go deeper than this, put me in front of them and I will take the whole call.

Where the patient lands08/11

One integration, a whole platform behind it.

The API is the front door. What makes it worth walking through is everything already standing on the other side.

The compliance layer

Provider licensing tracked per state, so a patient is only ever seen by someone allowed to treat them where they live.
Credentialing, state rules, and an audit trail on every chart access.

The clinical record

Intake, clinical review, notes, orders and follow up all sit on one record.
Your call opens that record, so nothing has to be keyed in twice.

Fulfilment

Prescriptions are dispensed and shipped through pharmacy partners already wired to the same record.
The journey does not stop at the consultation, so neither does your patient.

Presenter note

Credibility, not detail. The point is depth. They are not buying an endpoint, they are buying everything standing behind it. Say that fulfilment is included, so the journey does not stop at the consultation. Do not name our platform or pharmacy partners unless they ask.

I want to be clear about what you are actually buying, because it is not an endpoint. Behind that one request there is the licensing, so a real clinician who is allowed to treat that person in that state. There is the clinical record, so the visit is documented properly and it is there when somebody asks. And there is fulfilment, so the journey does not stop at a consultation, the patient actually receives their treatment. You get all of that from the same integration you just saw. Any one of those three would be a project on its own if you went and built it.

Getting started09/11

What we need from you, and what you get from us.

From you

A technical contact who owns the integration
Expected volume at launch, and at steady state
Which treatment types you will be sending
Whether we message patients, or you do

From us

An API key scoped to this integration
An agreed reference prefix for test traffic, so it is easy to spot and clear out
A named contact for integration questions
Notice ahead of any change to this contract

Authenticate firstPost an empty body. A validation error proves your key and headers are right.
Send one full intakeWith patient messaging switched off, so nothing reaches a real person while you are wiring up.
Send the exact same one againYou should get the same identifiers back and no second chart. This is the check most integrations skip and later regret.
Then one live runWith an address you control, so you see exactly what a patient sees.

In plain English

Tell us how many patients, and from which states. We hand you a key. You run four test calls before you send anybody real.

Presenter note

Ask for their number here. The four test calls make the work feel small, which is the point. Before leaving this slide, ask what volume they expect at launch. You need that number to size their limits.

Let me tell you what the first week actually looks like, because it is smaller than people expect. We issue your key, usually the same day. Your developer makes four test calls against it, with patient messaging switched off, so nothing reaches a real person while you are experimenting. When those four come back clean, you send one real patient through and you watch it end to end yourself. Most partners are live inside a week, and the part that takes the longest is usually not the code, it is deciding who on your side owns it. Before we move on, roughly what volume are you expecting at launch? I need that number to size your limits properly.

Who builds it10/11

Three ways to connect, and one of them asks nothing of you.

Nobody on your team has to write code for this to work. If you would rather hand it over, our engineers will go in and set the whole thing up for you.

Your developer

One authenticated POST. Most engineers finish it in an afternoon.
You get the field reference, sample requests and a named contact on our side.

Your automation tool

Zapier, Make, n8n or the webhook builder already inside your CRM can all send this call.
No code, no hosting, no deploy. You paste the fields into a form.

We do it for you

Our team, in your systems

You grant access. We build the connection, test it and hand it back working.
Scope and cost agreed in writing before anyone touches anything.

How the handover runs

Access. You give us the narrowest login that can do the job, on the one system that needs changing.
Build. We wire your form, funnel or CRM to the intake call.
Test. Four test patients, with messaging switched off, so nothing reaches a real person.
Handover. We walk you through what changed, then you revoke our access.

How we treat your access

We ask for the least we can work with, we never ask for anything holding patient data, and access ends the day the work does. If your platform can issue a temporary or limited login, use that one.

Typical shape

Most of these take under a week from access to first live patient. If your setup is unusual we will say so before we start, not halfway through.

Presenter note

The slide that unblocks non technical leads. If they have no developer, this is the slide that saves the deal. Do not quote a price and do not promise a date. Scope first, in writing. If you are unsure whether we can staff it, say you will confirm rather than guessing.

And if you do not have a developer, I want to say clearly that this is not a problem and it does not slow anything down. There are three ways in. Your own developer, which is an afternoon of work. Your automation tool, so Zapier or Make or whatever is already sitting inside your CRM, and that needs no code at all. Or we do it for you. You grant us access, we build it, we test it, we hand it back to you working, and then you switch our access off. Let me scope that properly and put it in writing first so we both know exactly what is included.

Next11/11

Bring your volume, your states and your treatment list.

Thirty minutes with your engineer and ours is usually enough to agree the contract and issue a key.

Volume. Intakes per day at launch, and where you expect to be in six months.

States. Where your patients are, so we can confirm provider coverage.

Treatments. What you are sending, so we can map it to a program.

Messaging. Who emails the patient, you or us.

Timing. The date you want to be live.

Presenter note

Close by booking the next call. Do not end on questions, end on a calendar. You want five answers: volume, states, treatments, who emails the patient, and the date they want to be live. Anything you cannot answer, write down and follow up the same day.

So rather than ending on questions, let me tell you what I need from you and we will book the next call now. Five things. How many patients a day you expect. Which states you are selling into. Which treatments. Whether you email the patient after signup or you would rather we do it. And the date you want to be live, because everything else works backwards from that. If you have four of the five today we can start, and I will chase the last one. Anything I could not answer today, I will send you in writing before the end of the day.