WebPT Integrates Over HL7 v2, Not an API

WebPT does not publish a developer API, a self-serve key issuance flow, a sandbox, or public integration documentation. Their integrations page frames the offering as Integration Services And Ongoing Maintenance: a managed service, not a platform.

The technical foundation they name is HL7, with the example given being that a source system provides HL7 ADT transactions that create and update patients in WebPT. They describe roughly five standard integration types (inbound patient registration, outbound billing, outbound documentation, inbound documentation, and custom), and state they are integrated with more than 60 different vendors. Prospects are directed to contact them.

This is a legitimate model, and it is a completely different purchase from sign up and get a token. Two consequences follow from it.

• Integration is a project with a price and a timeline, negotiated with WebPT, not a thing you do on a Tuesday. There is a designated point of contact through development and deployment, which is a real service and also a signal about scale.
• The interfaces are shaped around the existing 60-plus vendors, meaning billing systems, hospital ADT feeds, and document repositories. Patient outreach is not one of the five patterns, so a reactivation product is not a natural fit for a surface built to move registrations and claims.

If you have only worked with REST or FHIR, adjust your expectations concretely.

HL7 v2 messages are pipe-delimited segments, not JSON. A message is a set of segments (MSH for the header, PID for patient identification, and so on) with fields separated by a pipe and components by a caret. It reads like this rather than like an object.

Transport is typically MLLP over a TCP socket, not HTTPS. That means a persistent listener, network-level access, and usually a VPN, not a public endpoint you call. Firewall and network work is part of the project.

It is event-driven rather than request-driven. You do not ask for a patient, you receive an ADT message when something happens. This is genuinely good for outreach in principle, because it is push rather than polling. It is less good in practice when the events you receive are not the ones you need.

And v2 is famously flexible. Two systems both speaking HL7 v2 routinely disagree about which optional fields carry which data, which is why every interface involves a specification document and a testing phase. Budget for the interface spec conversation; it is where the time goes.

Here is the structural problem with reactivation over this surface, and it is worth being direct about it.

ADT means Admit, Discharge, Transfer. It is a patient demographics and encounter feed. The documented direction for ADT with WebPT is inbound, a source system creating and updating patients in WebPT, which is the opposite of what an outreach product needs.

The outbound patterns are billing and documentation. Billing data will tell you a visit was billed. Documentation will give you notes as PDFs. Neither is an appointment feed, and a PDF is not a data source you want to build scheduling logic on.

Reactivation needs to know that a plan of care ended, or that a patient with an active case has not been seen in some number of weeks, or that a scheduled visit was missed. None of those map cleanly onto ADT in, billing out, or documents out.

You can approximate it. Billing data with gaps in it is a proxy for a patient who stopped attending. But you are inferring clinical status from claims, with the lag that implies, and the practice will find the result less precise than expected.

Even a practice that runs reactivation entirely by hand hits a question the interface project would not have solved: did it work?

Attribution in PT reactivation is genuinely hard, and it is hard for a reason specific to the discipline. A patient who returns four months after a check-in message may have returned anyway; the injury flared, and the text was incidental. A patient who does not return may have recovered completely, which is the outcome the practice was actually working toward. Counting returns alone rewards the wrong thing.

Two habits make the numbers mean something.

• Record the reason for return, not just the return. A patient who comes back citing the same body region as their original episode is a different data point from one presenting with something new, and only the first tells you the reactivation effort is finding people whose episode ended prematurely.
• Hold back a control group. Skip the check-in for a random slice of discharged patients and compare return rates. It feels wasteful and it is the only way to know whether the outreach does anything. Most practices that try this discover the effect is real but smaller than the pitch implied, which is still worth doing, and worth knowing accurately.

• Start inside WebPT. It has scheduling and reporting, and a discharge-and-follow-up list built from its own reports costs nothing and requires no interface project. Most practices that want reactivation software have not yet run the report, and running it usually reveals the problem is smaller or differently shaped than assumed.
• Make the check-in clinical rather than commercial. “How's the shoulder holding up?” from the treating therapist recovers patients; “book your next appointment” from a marketing system does not. This is the same point as in behavioral health for a different reason: PT patients discharge having been told they are better, so an invitation to return needs a clinical reason attached.
• Time it to the condition. Post-surgical, chronic, and acute episodes have completely different natural check-in windows, and a single fixed interval will be wrong for most of them.
• If you do want a built integration, go to WebPT with a specific ask. Their model is project-based, so we want an API gets nowhere while we need discharge events with these fields is a scoping conversation.

WebPT is not in our integration set. This page is written from WebPT's own public integrations page and general HL7 v2 knowledge, as of August 2026.

We have not scoped a WebPT integration project, so we cannot tell you what one costs or how long it takes. WebPT can. The absence of public developer documentation is not evidence that a given capability does not exist, only that it is not self-serve. Ask them.