Introducing Live Data APIs: Fresh from the Chair

The age of the answer

CRMBridge keeps a continuously-updated copy of each connected practice’s data in the cloud. That is why the synced endpoints are fast, and for most workflows — dashboards, analytics, bulk pulls, patient engagement — a copy that is minutes old is exactly right.

But some moments cannot wait for the next sync cycle. Verifying eligibility while the patient is standing at check-in. Confirming a claim’s status on a phone call. Reading the note the front desk typed ten seconds ago. In those moments the useful metric is not response time — it is the age of the answer when it lands. A nightly-sync API responds fast, with yesterday’s data.

Today we are launching the Live Data APIs: 22 read endpoints that go straight to the practice management system at request time, plus a status endpoint to check realtime connectivity before you rely on it.

The migration is one prefix

Every live endpoint keeps its synced counterpart’s name, verbs, headers, and response shape. If you already call /v1/GetPatient, you already know how to call the live version:

POST https://api.crmbridge.ai/v1/live/GetPatient
BusinessID: your-business-id
APIToken: your-api-token
LocationId: your-location-id

Same headers. Same body. The response is the wrapper you already parse — TotalCount / Count / Data — with freshness markers on top:

{
  "Source": "live",
  "IntegratorLatencyMs": 1840,
  "FromCache": false,
  "TotalCount": 3,
  "Count": 3,
  "Data": [ /* same fields as the synced endpoint */ ]
}

Your models, parsers, and mappings work unchanged. The migration for a read where freshness matters is, quite literally, adding /live to the path.

Built for the real world: graceful fallback

A live read depends on the practice’s own system being reachable at that moment. Practices restart servers. Networks blip. We designed for that instead of pretending it away.

And before you rely on live reads for a practice at all, ask: GET /live/Status returns whether the integrator is online, whether live queries are supported, and exactly which operations that practice can serve in real time.

What’s live on day one

A live counterpart exists for every read where freshness matters: patient search and lookup, patient balance, appointments, available slots, transactions, treatment plans, insurance claims and companies, clinical notes, recalls, perio charts, documents, providers, practices, operatories, staff, procedure codes, fee schedules, payment and adjustment types, and definitions.

Two behaviors worth knowing before you build:

• Expect seconds, not milliseconds. A live read round-trips to software running inside the practice. Keep using the synced endpoints for bulk work; reach for /live at the moments freshness pays for the latency.
• Practice-wide windows are bounded. Windowed reads (appointments, transactions, treatment plans) without a PatientId are clamped to a 31-day span; with a PatientId and no dates you get that patient’s full history.

The documentation has the full endpoint list, the envelope reference, and worked examples — and the launch page tells the story in one screen.

Why this design

We could have shipped realtime as a separate product with its own schema. We deliberately did not. Every hour a partner spends remapping fields is an hour not spent shipping their product, and every divergence between a “fast” shape and a “fresh” shape becomes a bug the first time someone mixes them. Mirroring the synced contracts means the choice between cached and live is a per-call decision — not an architecture decision.

If you already integrate with CRMBridge, your existing credentials and connected practices work with the Live APIs right now. Nothing to enable, nothing to re-onboard.