DEV Community: CAmador

How a Dentist-Developer Shipped a Bilingual AI Receptionist in 2 Weeks (Without Rebuilding His Stack)

CAmador — Wed, 22 Apr 2026 00:29:04 +0000

How can you build something prod ready between patient appointments?

Dr. Erfan Zarger runs a full-time dental practice at Potomac Dental seeing patients all day, and building in the gaps. He spent nearly 15 years writing software before ever picking up a dental drill, and now runs a thriving practice in North Bethesda, Maryland offering everything from cosmetic veneers to implants to root canals.

And he still shipped a bilingual AI receptionist in 2 weeks.

When Dr. Zarger took over his practice, the issue was obvious. Calls were being missed.

Mostly after hours, when patients were calling with real intent and no one was there to answer.

“Almost 90% of after-hours callers don’t even pick up when you call them back the next morning.”

At the same time, he lost his Spanish-speaking front desk staff member. Replacing that role didn’t make sense for the volume, but the need didn’t go away.

So now the system had to do two things without adding staff.

Capture every after-hours call
Support both English and Spanish patients

Dr. Zarger knew he needed a bi-lingual AI receptionist. If you’ve tried to build anything like this, you already know where it breaks.

Not in the model. Not in the call flow.
In the integration layer.

You can get a request working pretty quickly. That’s not the issue.

The issue is everything after that:

inconsistent data across systems
scheduling logic that doesn’t behave the same way twice
endpoints that technically work but don’t map cleanly to real workflows
edge cases that multiply the second you hit production
legacy PMS with an update that throws everything off

And this is exactly what Dr. Zarger ran into trying to connect his voice layer to his practice management system.

Instead of continuing to wire directly into his PMS, he changed the approach.

He stopped trying to solve integration as part of the product. When searching for a solution in Google Gemini and ChatGPT he had the same answer: Synchronizer API by NexHealth.

Dr. Zarger had his system up and running in one day.

Using the Synchronizer API gave him a stable, consistent way to access scheduling and patient data without rebuilding logic for every system or edge case.

postman.com

The part that stood out wasn’t just the API.

It was his developer experience with access to:

clean, organized documentation
multi-language code samples
a live sandbox where he could test calls before touching production

If you’ve been stuck in integration work, this is the point where most projects either accelerate or stall completely.

If you want to see what that actually looks like, the docs he used are here: [https://docs.nexhealth.com/]

Within two weeks, the system was live. Not only that, it was built in the gaps between running a dental practice.

Dr. Zarger deployed two AI receptionists.

The first handled after-hours English calls. It answered every call, collected patient details, answered common questions, and surfaced appointment availability without needing staff involvement.

The second handled Spanish-language calls at any hour, translated the full conversation into English, and sent structured summaries to the front desk.

So when staff came in the next morning, they weren’t guessing what happened. They were following up with clarity.

“Even if both of my front desk staff don’t show up to work, the AI can answer all the phone calls with no problems.”

That’s not just automation.
That’s removing a failure point from the system.

In two weeks:

zero after-hours missed calls
two AI receptionists running simultaneously
bilingual coverage without hiring
staff time shifted from triage to actual patient work

This wasn’t a prototype.
It was running in production.

He wasn’t working full days on this. He was building between patients.
If you’re building anything that touches real-world systems, this is the constraint: You don’t lose time building features.

You lose time trying to normalize everything around them.

The developers who ship aren’t the ones who solve every layer. They’re the ones who decide which layers not to own.

Dr. Zarger made that decision early. That’s why this took two weeks instead of two months.

https://synchronizer.io/case-studies/dr-zarger
https://postman.com/nexhealth/nexhealth-public
https://github.com/synchronizer-api

Validate Dental Scheduling in 5 Minutes

CAmador — Thu, 12 Feb 2026 23:39:21 +0000

If you’re in the middle of wiring up dental PMS integrations (Dentrix, Open Dental, Eaglesoft, etc.), you don’t need a tour, you need working calls to confirm what’s actually bookable and how appointment states behave.

This post links to a read-only Postman collection that runs five GETs to validate scheduling semantics, before you write any business logic.

Run It

Run in Postman https://god.gw.postman.com/run-collection/19774779-358d4afa-f4b1-4aac-8167-2d73f9a92882

3-min video (account + core concepts):
https://www.loom.com/share/e541491c076c4003b61528b052e3c96f

Quickstart (curl):
https://github.com/synchronizer-api/quickstart

What you validate (read-only)

Locations: list locations, pick a simple one for first pass
Providers: scope to a provider in that location
Availability: check configured bookable times across a time window
Appointment details : see CONFIRMED / PATIENT_MISSED / CANCELED as explicit events

This avoids inferring behavior from timestamps or UI quirks and lets you sanity-check slot semantics quickly.

Prereqs (free dev signup to token)

Create a developer account (free)
get a sandbox API key / token
Fork the Postman collection
Set environment variables:

BASE_URL (e.g., https://nexhealth.info)
TOKEN (1-hour bearer from POST /authenticates)
subdomain
location_id
You’ll also set providerId, startIso, endIso, apptId (sandbox values are available in your portal)

Headers on every call:
Accept: application/vnd.Nexhealth+json;version=2
Authorization: Bearer

The Five Requests (high level)

GET /locations?subdomain={{subdomain}}
GET /providers?location_id=…GET /providers?location_id={{location_id}}
GET /availability?location_id=…&provider_id=…&start=…&end=…GET /availabilities?subdomain?subdomain={{subdomain}}&location_id={{location_id}}&page=1&per_page=5&active=true&ignore_past_dates=false
GET /appointment_slots?subdomain=test&start_date={{startIso}}&days=10&lids[]={{location_id}}&pids[]={{provider_id}}&overlapping_operatory_slots=false
GET /appointments/{id}/historyGET /appointments/{{appt_id}}

If you prefer terminal over UI, the quickstart repo has curl equivalents.

Why this helps
Truth over guesswork: \appointment_slots endpoint returns realt time availability of a provider

Auditable changes: appointment details exposes rcancels/confirmations/patient missed as events, not vibes.

Safe to try: read-only in a sandbox.

Try it now

Fork & run: https://god.gw.postman.com/run-collection/19774779-358d4afa-f4b1-4aac-8167-2d73f9a92882
Curl quickstart: https://github.com/synchronizer-api/quickstart

What examples would help next? Thinking: webhooks delivery/retries, conflict paths, multi-location diffs.

Why Operatory Schedules Look Fine but Don’t Feel Reliable

CAmador — Wed, 28 Jan 2026 19:53:45 +0000

When your regional ops starts each call with a friendly “quick question” that somehow turns into a thirty-minute mystery hunt through appointment logs…it’s a red flag.

It’s a sign that something deeper is going on.

Your API health checks clear, your status dashboard is green and practice calendars look fine.

But troubleshooting calls don’t seem to stop.

Most Dental Service Organizations (DSOs) start with a straightforward model.

One location, one set of rules, with predictable slot generation.
Then a new acquisition brings new workflows. New clinics inherit their own scheduling habits, and providers' rules are inconsistent.

And time zones, which seem harmless on paper, begin to blur meaning even when timestamps look perfectly normalized.

Confidence breaks one regional ops call at a time.

A slot that appears valid in one system turns out not to represent real capacity once it hits planning, analytics, or forecasting. Availability becomes something leadership asks about instead of something they can rely on.

This is what scheduling drift looks like in practice. The schedules technically work, but the interpretation does not.

Why this happens in every multi-location DSO

Operatory scheduling is not just data.

It is behavior.

Each location encodes its own assumptions about:
• When a provider is actually available
• What counts as a valid slot
• How overruns and exceptions are handled
• How time zones are interpreted operationally

Those behaviors make perfect sense locally. But once aggregated, they don’t map to a stable organizational truth.

Engineering absorbs some of it in code, then analytics absorbs some of it in reconciliation logic.

Regional operations absorb the rest through manual interpretation. The thing is, no one decides this. It just accumulates which can be so fun.

And eventually, the organization realizes that scheduling is no longer just generating blocks on a calendar.

It is maintaining a set of guarantees that other systems rely on, even though those guarantees are scattered across teams and tools.

This is where DSOs begin to lose operating leverage.

When you try to “tighten the process,” “clean up scheduling rules,” or “restandardize workflows.” Those efforts help at the margins, but they do not resolve the real constraint.

DSOs will try to either standardize protocols across regions with detailed SOPs or hire scheduling coordinators to ensure consistency.

Because at scale, this is no longer an operational problem. It is architectural. Every doctor practices differently.

Every DSO that grows into multi-region operations eventually faces the same decision.

Do you continue letting each system interpret operatory behavior on its own?

Or do you centralize interpretation into a shared reference layer before it reaches analytics, planning, forecasting, or operations?

The DSOs that move through this phase successfully are not the ones who “fix scheduling.”

They are the ones who define where interpretation belongs.

They decide:
• What downstream systems are allowed to rely on
• What ambiguity must be absorbed centrally
• What rules need to be stable across the entire organization
• Which behaviors matter for capacity and which are harmless locally

This is a sequencing decision, not a tooling decision. When the pattern is acknowledged, the ownership decision is the best next step.

What a unified reference layer actually looks like

Some DSOs build their own layer. Many outgrow that path once new clinics and locations cause drift.

Increasingly, teams evaluate external reference layers so they can normalize availability upstream without replatforming scheduling systems.
Built for this problem is the NexHealth Synchronizer API and it is one example of how DSOs scale across regions.

It shows how availability is normalized across locations, how slot generation becomes observable instead of inferred, how time zones stop leaking downstream, and how this work turns into infrastructure instead of ghost logic hidden in multiple services.

Because once scheduling behavior becomes infrastructure, decisions become faster. Future forward DSOs prefer predictable onboarding with clear capacity planning.

And engineering gets out of the business of maintaining hidden guarantees.

This is the moment DSOs regain leverage.

You’re past the threshold. You are operating inside a scheduling drift.
The question is no longer whether it exists. It is whether you decide to own it intentionally.

Because operatory scheduling becomes infrastructure at scale, whether you acknowledge it or not.

If you want to see what a centralized interpretation layer looks like in practice, review the public GitHub quickstart and reference architecture for Synchronizer API by NexHealth.

Your team might miss the calls from the regional ops office but they’ll finally trust what the schedule is saying.

https://github.com/synchronizer-api/quickstart

Why DSO Integration Problems Surface as Delayed Decisions, Not System Failures

CAmador — Mon, 12 Jan 2026 14:31:18 +0000

Dental Service Organizations integration problems rarely announce themselves through outages or broken systems. They surface as hesitation.

Decisions that once took days begin to take weeks.

Analytics reviews slow as leaders ask for clarification instead of acting on results.

Onboarding timelines stretch unevenly, not because teams are behind, but because confidence in the systems underneath those decisions has quietly eroded.

Growth continues, but momentum becomes harder to sustain.

This pattern is consistent with what health IT researchers describe as interoperability drag, situations where systems technically exchange data, but organizations struggle to act on it with confidence.

That gap between exchange and shared meaning is where decision latency begins.

When DSO systems look healthy but decisions slow down

By the time decision latency becomes noticeable, nothing appears obviously wrong.

Reports populate.

Dashboards refresh.

Product teams ship features.

From a distance, the organization looks operationally sound. Up close, leadership discussions begin with qualifiers. Metrics require explanation. Roadmap conversations include buffers. Acquisitions take longer to operationalize than expected.

Enterprise integration research consistently shows that this is how integration risk presents when it is structural rather than technical.

Panorama Consulting Group, which studies large-scale system integrations across regulated industries, describes this effect clearly:

“When integration logic is fragmented across teams and systems, organizations experience slower decision-making even when applications remain operational.” Panorama Consulting Group, The Consequences of System Integration Issues

At this stage, the constraint is no longer uptime or throughput. It is architectural clarity about where data interpretation lives.

Why scheduling exposes the problem first

In DSOs, multi-location dental scheduling is almost always the forcing function.

Scheduling data is often treated as a simple object as appointments, providers, locations, timestamps. In reality, it represents operational behavior, not static records. Appointments are rescheduled, split, merged, overridden, or canceled in ways that are locally valid but ambiguous once aggregated across locations.

Healthcare interoperability studies repeatedly identify workflow-driven domains like scheduling as the hardest to normalize, because behavior varies by site, staff role, and vendor implementation.

HIMSS notes this explicitly:

“Workflow variability across sites is one of the primary contributors to data inconsistency in multi-site healthcare organizations.” HIMSS, Interoperability in Healthcare

As DSOs scale, scheduling stops being a data synchronization problem and becomes a behavior synchronization problem. The same update can mean different things depending on origin, timing, and context. Identity, state transitions, and history all matter.

Nothing fails.
But interpretation diverges.

The hidden cost: interpretation without ownership

When interpretation is not centralized, it spreads.

Become a member
Engineering teams encode PMS-specific scheduling logic to stabilize downstream systems. Analytics teams reconcile inconsistencies before results can be trusted.

Operations teams manually validate edge cases. Leadership absorbs longer timelines and plans conservatively because confidence in dental PMS data reliability erodes.

This phenomenon, where integration logic becomes organizational drag, is widely documented in healthcare data architecture research.

Deloitte summarizes the business impact this way:

“Organizations that lack a unified data and integration layer experience slower execution, higher operational overhead, and reduced confidence in analytics as they scale.” Deloitte, Healthcare Interoperability and Data Integration

This cost rarely appears as downtime. It appears as decision latency, reduced operating leverage, and slower post-acquisition value realization.

Where this stops being theoretical

Once DSO leaders recognize that integration risk shows up as delayed decisions rather than system failures, the question shifts from diagnosis to ownership.

Interpretation lives in code, dashboards, documentation, and people’s heads. Every acquisition introduces new scheduling behavior. Every new PMS integration adds another interpretation path.

The decision is no longer whether this layer exists.

It is whether it will remain fragmented or become intentional, governed infrastructure.

Why this is infrastructure DSOs should not keep rebuilding

Maintaining multi-location scheduling interpretation internally requires ongoing engineering investment in normalizing PMS behavior across vendors, resolving identity and state ambiguity, handling retries and idempotency safely, insulating downstream systems from vendor API changes, and maintaining observability over time.

This work does not differentiate the business.
It reduces fragility at a cost.

Healthcare IT analysts increasingly recommend centralizing and externalizing this layer once organizations reach scale, because interpretation consistency is foundational, not competitive.

Where Synchronizer by NexHealth Can Help

Synchronizer.io is built specifically to address this class of problem.

Rather than forcing every product, analytics, and operations team to independently interpret multi-location dental scheduling behavior, Synchronizer.io by NexHealth centralizes that interpretation into a governed integration layer. Scheduling behavior is normalized once across PMS systems.

Sync state is observable instead of inferred. Retries are handled safely and idempotently. Vendor API limitations and behavioral inconsistencies are contained before they propagate downstream.

For developers, this removes undifferentiated integration logic from the critical path.

For DSO leaders, it restores confidence in analytics, onboarding timelines, and post-acquisition execution.

The value is not abstraction.
The value is decision velocity.

The real ROI: faster, more confident decisions

DSOs do not win by having the most integrations and dragging around legacy system issues. They win by making faster, more confident decisions as they scale across locations, PMS platforms, and acquisitions.

When scheduling complexity and PMS behavior are handled as intentional infrastructure rather than scattered logic, decision latency drops. Analytics become actionable.

Engineering capacity shifts back toward product differentiation instead of integration maintenance.

That is the outcome Synchronizer API by NexHealth is designed to support.

See how an intentional scheduling interpretation layer is made possible at www.synchronizer.io

Why Dental PMS Data Feels Fine Locally, and Unstable Globally

CAmador — Wed, 07 Jan 2026 20:54:45 +0000

Why I’m posting this: This is the pattern I see right before integration logic turns into infrastructure, and teams don’t realize it’s happening until much later.

Raw PMS data behaves well inside a single practice, it doesn’t feel like an accident, it’s more so the scope the system was designed for.
Once you aggregate across locations or various health record systems, assumptions start breaking with edits that overwrite intent, collapsed history and “authoritative” becomes contextual.

The data hasn’t degraded, it’s more that the context has expanded.

This is usually where integration logic starts accumulating exceptions.

Over time, those exceptions stop being temporary fixes and start becoming architecture.

When did you cross the line in the sand to unstable? Was it a slow creep for you too?

Synchronizer API Quickstart: Build Once, Integrate with 15+ Dental PMS Systems

CAmador — Sat, 27 Dec 2025 03:00:40 +0000

Integrating with dental PMS systems is rarely about missing APIs — it’s about inconsistent behavior, especially around scheduling and state changes.

Synchronizer API by NexHealth provides a single, normalized integration layer across 15+ dental PMS platforms (Dentrix, OpenDental, Eaglesoft, and more), so developers don’t have to rebuild the same logic over and over.

The GitHub Quickstart shows how to connect to real PMS data, handle scheduling updates safely, and rely on a stable contract instead of fragile, vendor-specific code.

👉 https://github.com/synchronizer-api/quickstart

You’ll learn:

How to connect to a sandbox and start syncing PMS data fast
How appointments, patients, and providers are normalized across systems
Why scheduling behavior needs interpretation, not just mapping
How to avoid rebuilding retries and edge-case handling

If you’re building healthcare, dental, telehealth, or AI scheduling products, this is a fast way to evaluate a production-grade integration layer without committing months of engineering time.

How a Solo Developer Shipped a Production-Ready AI Dental Receptionist in 2 Months

CAmador — Sat, 27 Dec 2025 02:46:57 +0000

Most developers don’t fail because of bad ideas.
They fail because integration work eats the roadmap.

That was the problem Dr. Peter Gabbay set out to avoid.

Dr. Gabbay isn’t just a dentist, he’s also a seasoned software engineer.

And like a lot of devs building in healthcare, he saw an obvious inefficiency hiding in plain sight: nearly 40% of calls to dental offices were going unanswered. Not because staff didn’t care, but because phones ring during procedures, after hours, and during peak load.

Missed calls meant missed appointments. Missed appointments meant missed revenue.

The solution was clear: an AI-powered dental receptionist that could answer calls, talk to patients, and book appointments 24/7.

The hard part wasn’t the AI.
It was the integrations.

The Real Constraint: Integration Debt Before Product-Market Fit

To work in the real world, Dentina.AI had to integrate deeply with existing dental practice management systems like OpenDental, Dentrix, and Eaglesoft — systems every dental office already depends on, and systems developers know are notoriously fragmented.

The naive approach would have been to build and maintain custom integrations for each PMS.

For a solo founder, that wasn’t just inefficient. It was existential risk.

Every additional PMS would have meant:

a new data model
a new scheduling workflow
a new set of edge cases
and a permanent maintenance burden

Dr. Gabbay didn’t need to become a PMS integration company.
He needed to ship a product.

The Decision That Changed the Timeline
Instead of rebuilding integration logic from scratch, Dentina.AI chose Synchronizer.io to handle PMS connectivity through a single, unified API.

That decision compressed what would normally be quarters of integration work into weeks.

“I got set up with the sandbox and thought, ‘Wow, this is very developer-friendly.’ I was able to get started really quickly.”
— Dr. Peter Gabbay, Founder & CEO, Dentina.AI

Synchronizer gave Dentina something most healthcare APIs don’t: a stable contract. One way to access scheduling, patient, and appointment data across 15+ PMS systems, without rewriting logic every time a new system came online.

What Shipping Fast Actually Looked Like
With Synchronizer handling the hard parts of data sync and PMS variability, Dentina.AI was able to focus on what mattered:

Designing natural AI call flows
Handling real-time appointment booking
Optimizing patient experience
Iterating quickly based on real usage

Instead of debugging brittle integrations, development time went into product behavior and reliability.

The result:

2 months from first API call to public launch
One API instead of 15+ custom integrations
1-hour onboarding for dental practices
40% of calls handled automatically
24/7 availability, without staff burnout

This is what happens when integration work stops being the bottleneck.

Why This Matters for Other Developers
Dentina.AI’s story isn’t special because it used AI.
It’s special because the founder protected his velocity.

Too many healthtech products stall because developers are forced to:

interpret vendor-specific scheduling behavior
normalize inconsistent data models
rebuild retries, idempotency, and edge-case handling
maintain integrations that don’t differentiate the product

Synchronizer removed that undifferentiated work from the critical path.

That meant Dentina.AI could layer proprietary logic on top of reliable, real-time data instead of fighting upstream complexity.

Support That Actually Feels Like Support

One thing developers often underestimate is the cost of being alone when things break.

Beyond the API itself, Dr. Gabbay credits hands-on collaboration from NexHealth’s team as a key factor in shipping quickly.

“James from support was extremely helpful and available. That kind of collaboration was critical to our success with the API.”

For a solo founder, fast answers and real human support matter as much as clean endpoints.

The Takeaway: Don’t Rebuild What You Don’t Need to Own

Dentina.AI didn’t win because it built the most integrations.
It won because it didn’t.

By treating PMS integration as infrastructure, not product, Dr. Gabbay preserved his time, focus, and momentum. He shipped faster, onboarded customers more easily, and scaled with confidence.

If you’re a developer building in healthcare, dental, or any regulated ecosystem with fragmented legacy systems, the lesson is simple:

Protect your velocity.
Own your differentiation.
Externalize the rest.

Dentina.AI did it in two months.

You don’t need a massive team to do the same, just Synchronizer API.

When Integration Work Becomes Dental Organizational Drag

CAmador — Tue, 23 Dec 2025 04:08:22 +0000

I didn’t notice it when the integration first shipped.
There was no outage. No postmortem. No dramatic failure.
What changed was the conversation.

Our product lead asked why onboarding a new dental customer was taking weeks instead of days.

Our data lead asked which system we should trust when numbers didn’t line up. Eaglesoft and Denticon felt like....

Someone else asked during our stand up whether a roadmap item needed to move because of an API change upstream.

The integration was technically “working.” But everyone had started working around it. Questions, no major changes though.

That’s the moment you realize you’re no longer just integrating a PMS.
You’re running infrastructure, and crossing more “that’s not my job” moments than anyone planned for.

This is the phase teams don't name.

Let’s rewind to how this started.

We know that multi-location dental data doesn’t break loudly. It drifts.

For leadership, this usually first appears as reporting caveats and timeline slippage...and hidden costs.

Scheduling behaves differently across locations, then patient identity fractures.

Providers span offices in ways the data model never anticipated.

Workflows that were clean in a single practice become ambiguous at scale.
None of this looks like a bug. It looks like slow adaptation.

Our conversations, our stand ups, our monthly check-ins started to center around either “it’s not my job to fix it” or “how can we duct tape this together before the next call?”.

We had normalization working just ok, product teams complacent with uncertainty, data teams adding verbal disclaimers to dashboards and our leadership team nervous but steady handed on our painfully slow project.

Nothing was broken enough to justify doing anything but rolling up our sleeves and fixing each issue. That’s when our organizational drag started to show up more often than I would have liked.

Somewhere along the way, I realized I wasn’t just integrating PMS systems anymore.

I was maintaining versioned behavior across PMSs.

Explaining in standups why downstream systems went down even though “nothing changed.”

Adding guardrails so retries didn’t corrupt state.

Writing code to compensate for behavior that was technically valid, but operationally unsafe.

None of this existed because the team over-engineered solutions. It existed because the EHR endpoints were intentionally incomplete.

Most dental EHR vendors:

expose read-heavy endpoints
restrict or omit write, update, or workflow-critical actions
limit bulk operations, scheduling mutations, financial edits, or state changes

So you can see data, but you can’t act on it the same way the native UI or internal systems can.

That’s intentional.
What isn’t intentional, but happens anyway, is what this creates downstream.

When teams can’t rely on APIs to behave as stable contracts, engineering absorbs the gap. When engineering absorbs the gap, product timelines become conditional.

When timelines become conditional, teams start planning around uncertainty instead of capability.

This is where integration work quietly turns into organizational drag.
Not because anything is broken.

But because every team is compensating for constraints they don’t control, and no single system owns the risk.

From the business side, this looks like “extra time.” But from the engineering side, it’s necessary work. Both sides have requests that might seem unreasonable....I think both are right.

When integration risk becomes roadmap risk seems like something teams avoid. No one wants to say it out loud. Because delivery timelines stop being driven solely by engineering capacity and contingent on external systems.

Our adventure started when we realized that EHR vendors deprecate endpoints intentionally, or withholds functionality to support their own products. We were forced to ask:
Do we delay the roadmap?
Do we rebuild internally?
Do we scramble for an alternative?

This is where integration work stops being a technical concern and becomes a business one.

Our roadmap didn't slip because the team is slow.
It slipped because the system boundary was never stable.

Eventually, we stopped asking, how do we fix this integration?

And turned to:
Why are we asking product teams to own integration guarantees—retries, normalization, observability, PMS variance handling, that don’t differentiate the product but can absolutely derail it?

That’s not a tooling question.
That’s a system decision.
And it’s where buy-vs-build actually belongs.

We didn’t reach this conclusion because our engineers couldn’t build it.
We reached it because maintaining integrations across legacy and modern PMS systems was consuming bandwidth we needed for the product itself.

We needed:

standardized data behavior across PMSs
observable sync state and actionable logs
safe retries and failure handling
insulation from upstream API change
the ability to scale without every team becoming PMS experts

So we adopted Synchronizer API by NexHealth.

Not as a shortcut. As infrastructure. Because whether we admit it or not, that’s what we were attempting to do anyway.

Synchronizer API by NexHealth didn’t replace engineering judgment. It removed undifferentiated integration work from the critical path so our teams could focus on what actually made the product better.

What Changed

Devs stopped rebuilding the same guarantees.
Integration bugs became diagnosable instead of mysterious.
Onboarding timelines stabilized.
Support load dropped.
Product teams stopped planning around unknowns.
Most importantly, the organization stopped compensating.

That’s the signal most teams miss.

If you’re a developer, engineering lead, product owner, or technical stakeholder reading this and thinking: “We’re already doing most of this ourselves.”

You are.
And that’s exactly the point. How's that going?

The question isn’t whether integration guarantees matter. It’s whether they should live everywhere, or somewhere intentional.

Once you see integration work turning into organizational drag, you can’t unsee it.

And once you name it, you can finally decide what to do about it.
The easiest way to understand how teams externalize this work is to look at the Synchronizer API by NexHealth Postman collection.

Developers can fork the collection into their own Postman workspace, which simply means making a private copy they can safely experiment with.

There’s no production impact, no setup to undo, and nothing shared back unless you choose to.

It’s a low-risk way for both technical and non-technical stakeholders to see what the integration contract actually looks like in practice.

You don’t have to commit to anything to explore it, forking the collection is just a way to understand behavior, guarantees, and edge cases before decisions get made.

*https://github.com/synchronizer-api/quickstart
*

Is Multi-Location Scheduling Where Dental PMS Integrations Start to Drift?

CAmador — Fri, 19 Dec 2025 23:08:03 +0000

I hit a breaking point after adding locations, not because anything “broke,” but because scheduling behavior stopped being consistent enough to rely on.

If you’ve ever synced appointment data across multiple dental locations, you’ve probably noticed the API isn’t wrong, the data isn’t missing.

The problem is that “appointment” doesn’t mean the same thing everywhere once you cross locations.

At one location, a reschedule mutates the original record.

At another, it creates a new record and retires the old. Sometimes behavior changes based on timing or role or really nothing. Offices can have multiple statuses that all mean an appointment is cancelled.

From the PMS perspective, this is valid operational behavior. From an integration perspective, it means appointment is no longer a stable object.

I tried to normalize this by inferring intent from timestamps, treating status changes as authoritative or reconciling after the fact.

It usually feels fine, until another location gets added.
_
At what point did you stop treating appointments as stable objects? Did you normalize early, or accept drift and contain it?_

If this is your first time integrating a dental PMS, start here

CAmador — Wed, 26 Nov 2025 21:40:14 +0000

If you’re inheriting a messy dental-PMS stack (multiple offices, multiple record systems, no unified scheduling), this is how to set a clean foundation. This helped our clinic save months on the project due to the multi-timezone, multi-location situation.

I see a lot of clinics build this themselves and have issues when a simple update is pushed out. So I took the fast lane to just bringing everything together.

You might be working with a single dental PMS like Dentrix, Open Dental, Eaglesoft or be at the crossroads of multiples.

Create a Developer Portal Account and generate your test API key.

Once onboarded, you can start building by making requests to https://nexhealth.infoin test environment.

After creating your test API key , make a POST request to /authenticates, passing your key in the Authorization header.

The response will include a bearer token valid for one hour. Use this token to access all other API routes.

All unauthenticated requests will return a 401 status code.

curl --request POST \
     --url https://nexhealth.info/authenticates \
     --header 'Accept: application/vnd.Nexhealth+json;version=2' \
     --header 'Authorization: YOUR_API_KEY'

Successful authentication will result in a response containing a bearer token provided in the response body:

{
    "code": true,
    "data": {
        "token": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIiwic2NwIjoiYXBpX3VzZXIiLCJpYXQiOjE2Mjg3NDMyNzksImV4cCI6MTYyODc0Njg3OSwianRpIjoiNjYxNjY4YWYtMTZkYS00OWFhLTljM2ItNmI0MDNiOTQxZWExIn0.hzbAv-Bx8vhEMXM1sGmAa9tO3WzUyvgBN8aw4tdOrG0"
    },
    "description": "Authenticated",
    "error": []
}

Once you've received your bearer token, make sure you add the string "Bearer" to your authentication headers, as shown below.

--header 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIiwic2NwIjoiYXBpX3VzZXIiLCJpYXQiOjE2Mjg3NDMyNzksImV4cCI6MTYyODc0Njg3OSwianRpIjoiNjYxNjY4YWYtMTZkYS00OWFhLTljM2ItNmI0MDNiOTQxZWExIn0.hzbAv-Bx8vhEMXM1sGmAa9tO3WzUyvgBN8aw4tdOrG0'

Below is a sample request with versioning and authorization code.

curl --request GET \
     --url 'https://nexhealth.info/patients?subdomain=YOUR_SUBDOMAIN&location_id=YOUR_LOCATION&new_patient=false&include_upcoming_appts=false&location_strict=false&page=1&per_page=1' \
     --header 'Accept: application/vnd.Nexhealth+json;version=2' \
     --header 'Authorization: Bearer YOUR_BEARER_TOKEN'

This is the JSON response to the above request.

{
    "code": true,
    "data": {
        "patients": [{
            "id": 143776,
            "email": null,
            "first_name": "John",
            "last_name": "Smith",
            "created_at": "2020-08-12T19:17:22.575Z",
            "updated_at": "2020-08-12T19:25:17.591Z",
            "account_activated": false,
            "middle_name": null,
            "foreign_id": "19",
            "foreign_id_type": "msg-opendental-DataSource-35",
            "requested_access": false,
            "waitlisted_at": {},
            "inst_ids": [],
            "prov_ids": [],
            "config": {},
            "unsubscribe_emails": false,
            "last_import_id": "e872caee-8e2a-40dd-a403-ca7099040b8d",
            "invalid_email": [],
            "inactive": true,
            "last_sync": null,
            "last_sync_time": "2020-08-12T19:25:17.591Z",
            "unsubscribe_sms": false,
        }]
    },
    "description": [],
    "count": 35,
    "error": []
}

Book an appointment will show you how to create appointments and start driving revenue for practices.

I built our scheduling, financial, and patient-experience tools without dealing with PMS-specific logic. If you have an AI receptionist like Dentina (a dev + dentist), this will help with call routing, chat, auto reminders and more.

Once your environment is set up, you can explore deeper workflows like booking appointments or accessing ledger data to power more advanced apps.

Ask me anything, happy to help. I do not work at NexHealth but I do know how they've helped us and feel like there are a lot folks building their own AI receptionist or duct taping things together.

If you did this as well via Synchronizer API or something else, let's hear it.

Multi-Location Dental Integration: Why My “I’ll Just Build It Myself” Plan Imploded

CAmador — Wed, 26 Nov 2025 02:48:42 +0000

Look, I get it.
I really do.

I saw a messy multi location dental PMS and thought, I can slay this dragon.

I’ve merged PRs at 3am that saved production from total collapse.

How hard could a few dental systems be?
Turns out: very.

What I thought was a dragon was actually a hydra whose heads each ran a different PMS, with different schemas, timezones, identity models, and philosophical beliefs about how appointments should exist.

And I, the sweet summer child that I was, thought I could unify it all.
This article is the tale of how that confidence evaporated, how the integration imploded, and why I’m sharing my mistakes.

If you’re somewhere in that same fight right now, consider this your field guide, written by someone who learned every lesson the hard way.

How The First Dental Location Created a False Sense of Security

Every doomed journey begins with something deceptively functional.
For me, it was locations.

I genuinely thought every location would look like this. That was adorable.

{
  "code": false,
  "description": "Description",
  "error": "Error",
  "data": {
    "id": 7,
    "name": "Default",
    "institution_id": 1,
    "street_address": "123 Law St",
    "street_address_2": "85335, North East",
    "city": "New York",
    "state": "NY",
    "zip_code": "54700",
    "country_code": "US",
    "created_at": "2020-06-05T20:16:57.007Z",
    "updated_at": "2020-06-05T20:16:57.007Z",
    "latitude": 37.7775028,
    "longitude": -122.3970603,
    "phone_number": "8888750851",
    "foreign_id": "1",
    "foreign_id_type": "--DataSource-",
    "email": "defaultLocation@nexhealth.com",
    "tz": "America/Los_Angeles",
    "last_sync_time": "2020-06-17T19:23:49.176Z",
    "insert_appt_client": "true",
    "map_by_operatory": "true",
    "set_availability_by_operatory": false,
    "inactive": "false"
  },
  "count": 2
}

Source: https://docs.nexhealth.com/reference/locations-1#/

Clean. Predictable. Rational.

Could I normalize this for every location? Absolutely……not.

The IDs didn’t line up
Timezones fought like my cats at 2am
Entities didn’t share a universal structure
Some fields appear only on Tuesdays. Because Tuesday.

This is where I learned that dental PMS systems each hold their own metaphysical stance on time.
Example A:
"start_time": "2025-01-14T09:00:00.000Z"

Example B:
"start_time": "2025-01-14T09:00:00-08:00"

Same company.
Same appointment template.
Completely different physics.

I wrote a function called: normalizeTimeButGently()

It worked 20% of the time.
Which is… not great.
Especially in healthcare.

Here’s the fun part of multi-location setups:
Each location might run a different PMS version.
Which means I quickly learned:

Location A returned fields B and C
Location B returned fields A and C
Location C returned field A but formatted completely differently
Location D returned nothing but errors unless I queried a hidden legacy endpoint someone swore “no one uses anymore”

My codebase slowly evolved into something that looked like this:
// if location is 2 use schema B
// if location uses PMS v14.2, patch the timezone
// if location matches this UUID, trust nothing
// if location is "Eastside", good luck

This is when I finally admitted the truth:
I didn’t build a unified API. I built a location arbitration layer.

The first location?
Easy.

The second?
Harder. But sure.

The third?

Because each new location brought its own:

data quirks
PMS configuration surprises
naming conventions
timezone philosophies
metadata chaos
and brand-new behaviors no one had documented since the Bush presidency

By the time I onboarded location #4, my “clean internal API” was being held together by conditional logic that read like a choose-your-own-adventure novel.

Except none of the endings were good.

Why My Plan Imploded (Gracefully, Eventually)
I started this process with confidence. I ended it with several thousand lines of normalization code and the kind of humility only multi-location dental data can teach you.

If you’re trying to stitch together multiple PMS systems across multiple locations:

you’re not imagining the chaos
you’re not doing it wrong
and you’re definitely not underqualified

The systems themselves are inconsistent, unpredictable, and occasionally from another timeline. And honestly, none of this is your fault, the legacy systems you’re building on weren’t designed for the scale or complexity you’re dealing with today.

This article is everything I wish someone had told me before I ever tried to build a unified layer for multi-location dental data.

If this saves you even one late night? Or going from six months to 2 weeks? Worth it.

But choose your own adventure.

If you’re wondering how I eventually solved it, the actual approach I used (the one that finally stopped the location drift and version chaos), check out the comments.

Dental Scheduling Systems: A Comparative Study in How Time Should Not Work

CAmador — Tue, 18 Nov 2025 22:17:53 +0000

Nobody gets into health tech because they love scheduling systems.
It just happens to you.

One day, you’re writing elegant RESTful APIs. The next, you’re deciphering an XML blob from 2004 that represents a dental cleaning and has a timezone offset from “Mountain(ish)”.

Every dental practice management system, Dentrix, Eaglesoft, OpenDental, seems to have been built by people who fundamentally disagree on how calendars work.

They all store time differently. They all return availability differently.
And none of them care about your weekend. Not a bit.

After about a month of dealing with this, I realized dental scheduling isn’t a technical challenge.

It’s an endurance sport.

The Before Times: A Brief History of Developer Suffering

Before Synchronizer.io, there were three basic ways to “integrate” with dental PMS systems:

Hope.
Write a few one-off scripts, assume every API call will work, and spend the rest of your life chasing 500 errors like ghosts in a data warehouse.

Glue code.
Do what everyone does: build a 3,000-line scheduler_sync.py that keeps growing until it develops its own consciousness.

Outsource the problem.
Hire a vendor who promises a “universal scheduling API” and quietly hides that it only works on Tuesdays.

Here’s a real example from my old job. We had three clinics.
Each used a different PMS.

I had to merge their appointment data into one “unified” dashboard.

if pms == "dentrix":
    appt_type = record.get("AppointmentCategoryName")
elif pms == "eaglesoft":
    appt_type = record.get("ApptTypeDescription")
elif pms == "opendental":
    appt_type = record.get("ProcDescription")
else:
    appt_type = "unknown"

It worked for three weeks, until one office renamed “Hygiene Visit” to “HYGIENE” in all caps.

The entire sync broke.

That was the day I started using version control for my sanity.

The Brittleness of “Custom Workflows”

Every dental office is a snowflake.

A deeply confusing, HIPAA-compliant snowflake.

They all have their own rules:

Dr. Nguyen only works 7–2 on Mondays but takes lunch at 11:15 “if there’s time.”

Dr. Patel does 90-minute crown preps but never on alternating Fridays.
The front desk blocks out 2 hours every third Wednesday for “admin.”

Try to express that in code and you’ll start questioning linear time.

That’s why every homegrown scheduling integration eventually collapses.

Not because the code is bad, but because every PMS update breaks something subtle: a field changes, a timezone offset drifts, or the API adds a mysterious new parameter like ScheduleKey_Alt.

Then everything downstream falls apart.

Double-booked patients. Missing slots. Angry hygienists.

It’s the kind of bug that doesn’t crash your app, it just ruins someone’s Thursday.

Why simple was just simple

Synchronizer.io by NexHealth does one amazing yet simple thing:

It gives developers a single, consistent API for booking, updating, and syncing appointments across all the major dental PMS systems.

One schema.
One set of endpoints.
One less reason to question your life choices.

Endpoints like:

/appointments

/appointment_slots

/appointment_types

/availabilities

No more “if PMS == Dentrix then do X.”
No more SOAP envelopes or CSV exports named availability_report_final_3.csv.
Just normal REST calls that return normal JSON.

And they actually work.

Step 1: Check Appointment Types

First, you can see what NexHealth appointment types exist for a practice:

curl --request GET \
  --url https://nexhealth.info/appointment_types \
  --header 'Accept: application/vnd.Nexhealth+json;version=2' \
  --header 'Authorization: Bearer YOUR_TOKEN'

Returns something beautifully mundane:

{
  "data": [
    {
      "id": 1758,
      "name": "New patient cleaning",
      "minutes": 30,
      "bookable_online": true
    },
    {
      "id": 1733,
      "name": "Sealant",
      "minutes": 30,
      "bookable_online": true
    }
  ]
}

You could frame it and hang it in your office.

It looks a little something like this:

Finding providers who offer a specific appointment type

To see which providers offer a specific appointment type, you can call GET providers and include appointment types, like this:

curl --request GET \
     --url https://nexhealth.info/providers?subdomain=smiledental&page=1&per_page=5&include[]=appointment_types&inactive=false' \
     --header 'Accept: application/vnd.Nexhealth+json;version=2' \
     --header 'Authorization: YOUR_BEARER_TOKEN'

Step 2: Find Available Slots

Now you ask the PMS for availability.
This is usually where everything breaks.

But with Synchronizer, it’s just:

curl --request GET \
  --url 'https://nexhealth.info/appointment_slots?subdomain=smiledental&start_date=2025-11-14&days=10&lids[]=19617&pids[]=142749492&overlapping_operatory_slots=false' \
  --header 'Accept: application/vnd.Nexhealth+json;version=2' \
  --header 'Authorization: Bearer YOUR_TOKEN'

And you get this back:

{
  "code": true,
  "description": null,
  "error": null,
  "data": [
    {
      "lid": 19617,
      "pid": 142749492,
      "slots": [
        {
          "time": "2025-11-17T09:00:00.000-05:00",
          "end_time": "2025-11-17T09:15:00.000-05:00",
          "operatory_id": 30
        },
        {
          "time": "2025-11-17T09:15:00.000-05:00",
          "end_time": "2025-11-17T09:30:00.000-05:00",
          "operatory_id": 30
        },

It returns actual times that match reality.
Not “possible windows.” Not “estimated availability.”

Just clean, timestamped, bookable slots.
The kind you can send to a frontend without writing an emotional support function.

The response will include providers who have availabilities for the given appointment type.

https://youtu.be/xPPr_1XSn6w
The docs: https://docs.nexhealth.com/reference/appointments-1

Step 3: Book It

When you’re ready to book an appointment:

curl --request POST \
     --url 'https://nexhealth.info/appointments?subdomain=smiledental&location_id=19617&notify_patient=false' \
     --header 'Authorization: YOUR_BEARER_TOKEN_HERE' \
     --header 'accept: application/vnd.Nexhealth+json;version=2' \
     --header 'content-type: application/json' \
     --data '
{
  "appt": {
    "patient_id": 397336299,
    "provider_id": 142749492,
    "operatory_id": 30,
    "start_time": "2025-11-17T09:15:00.000-05:00",
    "end_time": "2025-11-17T09:30:00.000-05:00"
  }
}

Response:

{
  "code": true,
  "description": "Appointment created",
  "error": null,
  "data": {
    "appt": {
      "id": 1115267833,
      "patient_id": 397336299,
      "provider_id": 142749492,
      "provider_name": "Healther McKay",
      "start_time": "2025-11-17T14:15:00.000Z",
      "confirmed": false,
      "patient_missed": false,
      "created_at": "2025-11-14T23:24:50.712Z",
      "updated_at": "2025-11-14T23:24:50.712Z",
      "note": null,
      "end_time": "2025-11-17T14:30:00.000Z",
      "unavailable": false,
      "cancelled": false,
      "timezone": "America/New_York",
      "institution_id": 1748,
      "appointment_type_id": null,
      "checkin_at": null,
      "location_id": 19617,
      "foreign_id": null,
      "foreign_id_type": "nex",
      "misc": {
        "is_booked_on_nexhealth": true,
        "booked_by_api_user_id": 1345
      },
      "last_sync_time": null,
      "patient_confirmed": false,
      "created_by_user_id": 397336277,
      "is_guardian": false,
      "patient_confirmed_at": null,
      "cancelled_at": null,
      "is_new_clients_patient": null,
      "confirmed_at": null,
      "sooner_if_possible": false,
      "operatory_id": 30,
      "deleted": false,
      "checked_out": false,
      "checked_out_at": null,
      "referrer": null,
      "is_past_patient": true,
      "timezone_offset": "-05:00"
    },
    "stripe_client_secret": null
  },
  "count": null

That’s it.
You’ve just booked an appointment across a real PMS.

No manual reconciliation. No hidden CSV exports.

Just a functioning API.

Step 4: Async Updates That Don’t Ruin Weekends

You know what’s worse than a sync job that fails?
A sync job that succeeds wrong.

With Synchronizer API, you don’t have to run background jobs every 15 minutes to “check for changes.”

Instead, it just tells you, via webhooks, when something updates:

{
  "event": "appointment.updated",
  "data": {
    "id": 1822,
    "confirmed": true,
    "start_time": "2025-11-20T09:00:00-08:00"
  }
}

It’s like a push notification for developer sanity.

https://docs.nexhealth.com/reference/postavailabilities

Why This Matters

Dental scheduling is one of those problems that sounds boring until you try to fix it.

Then you realize it’s not simple, it’s structural.

Every PMS is built around a slightly different interpretation of reality.
Synchronizer doesn’t try to change that; it just normalizes it.

You can integrate across systems, build better patient experiences, or automate workflows without rewriting your logic every time a vendor sneezes.

In short: Synchronizer API by NexHealth doesn’t just simplify dental scheduling. It simplifies your part of it.

Which is about as close to heroism as software gets.

The Only “Competition”

There isn’t really another Synchronizer.
The only competition is people trying to build it themselves.

Some developer, somewhere, is duct-taping together API calls between their PMS, an online booking form, and a reminder system, because “how hard can it be?”

It’ll work.
Until it doesn’t.

Then an innocent PMS update changes one field name, and the entire system folds like a lawn chair.

Appointments duplicate, availability disappears, and suddenly no one knows who’s coming in at 9 AM.

Synchronizer API by NexHealth prevents that entire category of pain.
It doesn’t replace developers, it replaces the duct tape.

Because let’s be honest: the only real competitor to Synchronizer.io is hope.

And hope isn’t versioned.

A Clean ROI Story

Shorter wait times
Higher booking completion rates
Fewer no-shows
Less time spent by front desk staff on reschedules

You don’t need a data warehouse to prove the value of “it actually synced.”

You just need to show that your dev team no longer has to maintain a 2,000-line cron job called fix_schedule_please.sh.\

Synchronizer API by NexHealth’s impact is simple: fewer sync failures, cleaner data, and systems that stop pretending to be real-time and actually are.

Conclusion and Parting Thoughts

Dental scheduling is messy, human, and unreasonably complicated.

Synchronizer.io doesn’t change that, it just makes it possible to interact with it like a sane person.

If you’ve ever built an appointment workflow, you know the pain of phantom slots, broken syncs, and that one integration that only fails on Thursdays.

Synchronizer API by NexHealth solves that once, correctly, and permanently.

It’s the kind of infrastructure that, ideally, you never think about again.

And in health tech, that’s the highest compliment there is.

[https://synchronizer.io]

GH Quickstart: [https://github.com/synchronizer-api/quickstart]