The Complete Guide to Tebra (Kareo) API Integration

If you're searching for the "Tebra API," here is the first thing to know: it is the Kareo API. When Kareo and PatientPop merged to form Tebra, the practice management platform kept its Web Services API unchanged — SOAP 2.1, served from the original webservice.kareo.com endpoint, with operations still namespaced under KareoServices. Everything written about the Kareo API still applies to Tebra, and everything in this guide applies whether your practice signed up under the Kareo name or the Tebra one.

This guide covers how the API actually behaves in production — the authentication model, the quirks that cost integration teams the most time, per-endpoint rate limits, and what each entity type does and does not support. It is based on our production connector, not just the vendor documentation.

Authentication: stateless, credential-per-request

Tebra does not use OAuth or session tokens. Every SOAP request carries three credentials in its RequestHeader: a Customer Key (issued in the Tebra admin portal under My Account > Get Customer Key), plus the username and password of an API user that must hold the System Administrator role. There is no token refresh lifecycle to manage — credentials are validated on every call, and every response includes a security block reporting the outcome.

The quirks that will cost you a debugging afternoon

SecurityResultSuccess is inverted. The response field named SecurityResultSuccess means the opposite of what it says: false indicates the request succeeded with no security issue, and true indicates it failed. Integrations that read it at face value treat every successful call as an auth failure. Use the Authenticated field as the reliable indicator instead.

GetPatients has no pagination. The primary patient read endpoint returns its full result set in one response. For a practice with tens of thousands of patients, an unfiltered call is impractical. The workable strategy is date-range batching: filter by FromLastModifiedDate / ToLastModifiedDate, store the last sync timestamp as a cursor, and pull only what changed since. Initial backfills walk historical windows in slices instead of asking for everything at once.

Date formats are inconsistent across endpoints. Different operations return timestamps in different formats, so a parser that assumes one format will fail on another endpoint's response. Normalize every vendor timestamp at the boundary — in our pipeline, everything becomes UTC ISO 8601 before it touches the canonical model.

Rate limits: per-endpoint cooldowns, not request windows

Tebra enforces a minimum interval between consecutive calls to the same endpoint, scoped to your Account ID — a different model from the request-per-window quotas most APIs use. Exceed it and you get an HTTP 429 telling you exactly which endpoint to slow down on. Most read endpoints (GetPatients, GetAppointments, GetCharges) sit on a 1-second interval; heavyweight operations like GetAllPatients require 5 seconds between calls. Two practical consequences: a sync engine needs a per-endpoint limiter rather than a global one, and polling aggressively buys nothing — an incremental, cursor-based sync every couple of hours moves the same data with a fraction of the API traffic.

What each entity type actually supports

The API's read and write support is uneven across entity types, and integration scope should be planned around it. Patients support read, create, and update — but not delete. Appointments support the full lifecycle including delete. Encounters can be read and created, but updates are limited to status changes. Charges, providers, practices, service locations, procedure codes, and transactions are read-only. Payments can be read and created but never updated.

The sharpest edge is documents: the API can upload a document but exposes no download operation. That means document sync out of Tebra is not possible for any integration, ours included — plan for documents to live in Tebra or be captured upstream of it.

Build it yourself, or use a managed integration

Everything above is buildable in-house: a SOAP client with envelope construction and XML parsing, credential handling, a per-endpoint rate limiter, date-range cursor management, timestamp normalization, and retry logic for 429s — plus HIPAA obligations the moment PHI flows through your pipeline: encryption at rest, TLS in transit, immutable audit logging, and a BAA with Tebra (required before production data access). It is a few engineering months to build and an ongoing commitment to maintain against undocumented behavior changes.

Orisan Connect's Tebra integration is that pipeline, already built: the SOAP interface is abstracted behind a canonical JSON model, rate limits are enforced per endpoint before requests are sent, syncs are incremental with conflict detection, and every operation is audit-logged in a HIPAA-compliant pipeline (AES-256-GCM at rest, TLS 1.2+ in transit). It connects Tebra to AdvancedMD, athenahealth, and Google Calendar today. If you would rather see it run than build it, request a demo.