No-Show Recovery for Tebra (Kareo) Practices

The Tebra Web Services API, version 2.1, is a set of SOAP web services. Its WSDL still lives on the Kareo domain, at webservice.kareo.com/services/soap/2.1/KareoServices.svc, and its documentation is the API Integration Technical Guide, a PDF linked from Tebra's help center (the April 2026 edition runs to 129 pages).

• What you can read and write. Get operations cover appointments, appointment reasons, patients, providers, practices, service locations, encounters, charges, payments and transactions. Writes cover creating appointments, patients, encounters, documents and payments; updating appointments, appointment status and patients; and deleting appointments and documents. There is no open-slot or availability operation and no webhook.
• How access is granted. A System Administrator on the practice's Tebra account opens a Customer Care case to request API access. Once it is done, the account's customer key appears under My Account, Get Customer Key. Every request carries that key plus the login and password of a Tebra user with the System Admin role.
• Practical limits. Rate limits are per account and per operation, for example one GetAppointments call per second and one CreateAppointment or UpdateAppointment call every half second, and exceeding them returns a 429 error. Every Get call needs at least one filter, a date filter needs both its start and end, and Tebra asks integrators to poll as rarely as possible, every two hours rather than every five minutes.

SOAP isn't bad technology. It's older, more verbose, and strongly typed in a way that catches certain mistakes early, and plenty of healthcare and financial systems run on it without issue. The problem isn't quality, it's ecosystem, and the costs land in tooling and iteration speed rather than in the protocol itself.

Your HTTP client changes. You're generating client code from a WSDL or hand-building XML envelopes, not calling a JSON endpoint with a plain request body. Most language ecosystems have a SOAP library, but it's rarely the well-maintained, obviously-correct default a REST project would reach for, and evaluating options costs time a JSON API wouldn't have charged you.

Your debugging changes too. You can't paste a URL into a browser and read the response. Exploration needs a SOAP client, and the afternoon most REST integrations spend just poking at the API stretches into something longer.

Your error handling changes as well. A SOAP fault is structured differently from an HTTP status code, and the useful detail usually sits nested inside the fault body rather than in the response line. Code written to assume a non-200 means failure will misread a fault returned with a 200.

None of this blocks the project. All of it is a line item, and an estimate that skips these three will be wrong.

This gets its own section because it changes how you research the project, not just how you build it.

Tebra distributes its API Technical Guide as a PDF download linked from its help center rather than as browsable web documentation. Anyone can download it, but you can't link a teammate to one method, and a search engine rarely lands you on the operation you need.

Read the guide before you commit to a delivery date. A comparison built only on Tebra's web pages will underrate it, because most of what it can do is only in the PDF. An estimate built on the assumption that it behaves like the last REST API you touched will be optimistic in the other direction.

There's a signal in Tebra's own support guidance too: its help center notes that Customer Care can support the API only on Tebra's side, and asks that a support ticket include the request and response XML pasted in directly. Log full request and response XML from day one. You'll need it for support, and reconstructing a failed call after the fact from a summary line is miserable. Redact PHI before any of it leaves your systems, but capture the rest.

The protocol friction pushes toward a particular architecture, and it happens to be a good one regardless of the transport underneath it.

Talk to Tebra as little as possible. Mirror the data you need locally, sync it on a schedule, and run every piece of business logic, segmentation, timing, message selection, suppression, against your own store. Anything you can keep out of the SOAP layer is logic you can test without a SOAP client sitting in the loop.

Wrap the API behind a thin adapter with a clean internal interface, so one module speaks XML and everything else speaks your own types. That's standard practice with any external API, but the payoff is larger here, because the alternative is XML parsing scattered through the codebase and a rewrite the day Tebra changes a field.

Batch wherever the API supports it. Per-record calls cost more with an XML envelope wrapped around each one than they would against a lightweight REST endpoint, and the round trips add up faster than the estimate expects.

Once the mirror exists, no-show recovery is the same problem it is anywhere else: find the missed visits, wait an appropriate interval, reach out with real available times instead of an invitation to call, and stand down the moment the patient rebooks through any channel.

The details that move the outcome are mostly not technical. Reach out the same day or the next morning, while the visit is still fresh in the patient's mind. Name two or three real times rather than asking them to call in, because an open-ended callback converts far worse than a slot they can just accept. Cap the sequence at two or three messages, and stop.

That last part is where the SOAP friction reaches into the outcome instead of just the build. A sync that's expensive to run gets run less often, and a stale local mirror sends a recovery message to someone who already rebooked. Budget for syncing more often than the friction makes comfortable.

Four questions move a Tebra estimate by weeks, not hours. The technical guide answers all four.

• Can appointments be filtered by modified date? Yes. GetAppointments takes FromLastModifiedDate and ToLastModifiedDate, so incremental sync is possible and the sync cost does not have to scale with practice size.
• Is there a distinct no-show state, or is it inferred? Explicit. The appointment status values include NoShow, alongside Confirmed, CheckedIn, Cancelled, Rescheduled and others, so a missed visit does not have to be deduced from a missing check-in, as long as staff mark it.
• Are writes supported, and which ones? Yes. UpdateAppointmentStatus can set a status such as Confirmed or NoShow, appointments carry a notes field, and appointments can be created, updated and deleted, so a confirmation does not have to be retyped by staff.
• What are the rate or concurrency limits? Published per operation and per account, from one call every quarter second to one every five seconds, and subject to change. Against the batch sizes this architecture needs, the one-call-per-second ceiling on GetAppointments is the number to plan around.

Everything above comes from Tebra's public help center and its API Integration Technical Guide (April 2026 edition), not from an integration we operate in production on Tebra's API. The guide notes that rate limits are subject to change, so check the current edition before you size a sync.

This page summarizes the guide; it does not replace it. Method signatures, field names and full status lists are in the PDF.

The same guide for other EHRs: no-show follow-up in Canvas Medical, no-show follow-up in TherapyNotes, and patient recall in Elation Health.