Retention IQ
Trust · Booking safeguards

Your booking system stays in charge. Always.

Phase 1 keeps the practice's booking system or approved booking surface in charge. Direct write-back is not assumed. If a supported integration is proposed, source-of-truth behavior, idempotency, conflicts, rate limits, revocation, and audit evidence must pass acceptance testing before activation.

Walk through the architecture with us See the 6 safeguards ↓
Healthcare readiness
Verified before PHI
BAA template
Executed for approved flow
Idempotency
Required for write-back
Audit evidence
Tested per integration
Revocation
Verified before activation
The architecture

Six safeguards, verified before activation.

These are acceptance requirements for an integration, not a claim that every listed vendor currently supports write-back.

01

Re-read before every write

A write-back design must re-verify availability against the source system immediately before the write, with a tested staleness threshold appropriate to that vendor.

02

Idempotency keys, always

Every proposed booking write must carry a stable idempotency key, and retries must be tested against the vendor's real duplicate-handling behavior.

03

Your front desk wins every race

Conflict handling must preserve the source booking system as authority and return a safe failure or alternate path when availability changes.

04

Vendor-specific rate limits

Quotas, retries, backoff, and circuit breaking must be configured and tested for the selected vendor and tenant before production activation.

05

Audit evidence

Required reads, writes, conflicts, webhooks, messages, and support access must produce reviewable evidence with customer-approved fields and retention.

06

Revocation and parking

The selected integration must have a tested revocation path, and communications must remain parkable while readiness or health checks fail.

Architecture

The required write-back control flow.

A candidate write-back integration must implement and pass this flow. Phase 1 can use a practice-owned booking link instead of direct writes.

01 · INPUT Patient clicks SMS link 02 · READ Live availability check 03 · CHOICE Patient picks a slot 04 · RE-VERIFY Live, < 250ms before write 05A · CONFLICT Propose alternates Loop back to read 06 · WRITE Atomic + idempotency key 07 · SOURCE OF TRUTH Your booking system 08 · AUDIT LOG 7-yr retention · all actions Verification checkpoint Conflict path → propose alternates Atomic write to source of truth Audit side-channel

This is the acceptance-test target for direct write-back. It is not a statement that every platform below currently supports or has passed this flow.

Integration depth

Your platform, supported.

Four integration patterns. Booking-link handoff (Pattern A) is live for every platform today; the deeper patterns are roadmap.

A Booking-link handoff

Patient lands on your existing booking page via a tracked link. Zero API access needed. Every platform.

B Read mirror

We sync availability every 60s, propose specific times in messages. No writes.

C Write-back

Two-phase commit with idempotency. Booking happens from the SMS in one tap.

D Conversational

Two-way SMS booking with NLP, reschedule, cancel. Full audit trail.

Platform Vertical A · Booking link B · Read C · Write D · Conv.
Open Dental Dental ✓ roadmap roadmap roadmap
Dentrix Dental ✓ roadmap roadmap —
Eaglesoft Dental ✓ — — —
Curve Dental Dental ✓ roadmap roadmap —
Eyefinity / VSP Optometry ✓ roadmap roadmap roadmap
RevolutionEHR Optometry ✓ roadmap roadmap —
Athenahealth Specialty ✓ roadmap roadmap roadmap
DrChrono Specialty ✓ roadmap roadmap roadmap
Kareo / Tebra Specialty ✓ roadmap roadmap —
Boulevard Atelier ✓ roadmap roadmap roadmap
Vagaro Atelier ✓ roadmap roadmap roadmap
Mangomint Atelier ✓ roadmap roadmap —
Aesthetic Record Atelier ✓ roadmap roadmap —
Mindbody Studio ✓ roadmap roadmap roadmap
Mariana Tek Studio ✓ roadmap roadmap —
ServiceTitan Field ✓ roadmap roadmap roadmap
Housecall Pro Field ✓ roadmap roadmap roadmap
Jobber Field ✓ roadmap roadmap —
FieldEdge Field ✓ roadmap — —
live · available today roadmap · planned, not available today — · not planned (platform limitation)

Don't see your platform? Talk to us — if it exports a CSV or offers a booking link, Pattern A is always available.

Trust FAQ

The questions every operator asks.

01 Can Retention IQ double-book a patient or client by mistake?
+
Phase 1 uses the customer's source booking system or approved booking link as the authority; Retention IQ does not assume direct write-back. If write-back is proposed for a supported system, source-of-truth behavior, idempotency, conflict handling, rate limits, revocation, and acceptance tests must be documented before activation.
02 What happens if our PMS or booking system is down?
+
The approved workflow must fail closed: it must not invent availability or write a booking when the source system cannot be verified. Phase 1 can route the customer to the practice-owned booking surface instead.
03 Can our front desk revoke API access?
+
The practice remains the owner of its source system. Connection revocation and communication parking are verified during launch for the selected integration; this page does not promise a universal one-click control across every vendor.
04 What does the audit trail capture?
+
The approved integration defines which reads, writes, webhooks, messages, support access, and failures are logged, which fields are captured, who can review them, and how long they are retained. Those controls must be tested for the exact workflow before activation.
05 How do you prevent runaway API calls from harming our booking system?
+
Rate limits, retry behavior, backoff, circuit breaking, and vendor-specific quotas are integration requirements. Their tested values are documented for the exact source system rather than represented as universal across vendors.
06 Do you sign a BAA?
+
A covered booking workflow is activated only after the healthcare-readiness review passes. The applicable BAA, permitted data flow, minimum-necessary scope, subprocessor agreements, eligible service configurations, logging, retention, and message-content rules must be verified before PHI moves. The public BAA template is available at /baa.
07 What booking systems do you support?
+
Source-system fit is confirmed during the managed launch. A practice-owned booking link or structured export may be used where appropriate; read-only API access or write-back is not represented as available until credentials, vendor terms, tenant mapping, safeguards, and acceptance tests pass.

Want to see the architecture running on your platform?

15-minute walkthrough. We'll show you exactly how Pattern A / B / C / D would integrate with your specific booking system — and show you the audit log in real-time.

Book a walkthrough Existing customer sign in
15 minutes · no sales pitch Works with your booking platform