Most healthcare systems still live in “polling world.”
Your app keeps asking, “Hey, did anything change yet?” until one day the server finally says yes.
That’s fine for static data. But in healthcare, where every minute can mean a new appointment, cancellation, or patient update, it’s not enough.
Synchronizer API takes a signal-based approach instead.
You don’t have to ask.
Just listen.
Step 1: Create a webhook endpoint
To build a real-time app, you first register a webhook endpoint that will listen for events.
Javascript
curl --request POST \
--url 'https://nexhealth.info/webhook_endpoints' \
--header 'Accept: application/vnd.Nexhealth+json; version=2' \
--header 'Content-Type: application/json' \
--data '
{
"target_url": "https://yoururl.com/hooks"
}'
Step 2: Subscribing to Events
Next, create a webhook subscription that will notify your app about the events you care about. For example, we can create a subscription for appointment updates.
POST /webhook_subscriptions
Javascript
curl --request POST \
--url 'https://nexhealth.info/webhook_endpoints/id/webhook_subscriptions?subdomain=YOUR_SUBDOMAIN \
--header 'Accept: application/vnd.Nexhealth+json; version=2' \
--header 'Content-Type: application/json' \
--data '
{
"resource_type": "appointment",
"event": "appointment_updated"
}
This tells Synchronizer, “Send updates to this URL when anything changes for appointments.”
You’ll receive a confirmation payload when the subscription is active, and from that point on, your endpoint starts receiving real-time event data.
Step 2: Handling the Event Data
When an event fires, say, an appointment is updated, Synchronizer sends a webhook event payload This will be a POST request to your endpoint with structured JSON describing the change.
Each event type (like appointment.created) includes metadata about what changed.
Here’s a sample notification (from the docs structure):
Javascript
{
"resource_type": "appointment",
"event_name": "appointment_updated",
"event_time": "2024-04-19T05:47:21.214+00:00",
"data": {
"appointment": {
"id": 1136829,
"patient_missed": true,
}
},
"delivery_errors": [
{
"code": "500",
"timestamp": "2024-04-19T05:53:44.844Z",
"message": "500 Internal Server Error",
"attempts": 1
}
]
}
This event payload lets you update your own database instantly, no sync cycles, no guesswork.
Step 3: Checking Sync Health
If you want to confirm your data is still up to date, Synchronizer provides a sync health check endpoint: GET /sync_status
Javascript
{
"code": true,
"description": null,
"error": null,
"data": [
{
"institution_id": 1748,
"sync_source_type": "DataSource",
"sync_source_name": "Practice Management System Integration",
"emr": {
"id": 10,
"name": "eaglesoft",
"display_name": "Eaglesoft",
"type": "onprem"
},
"read_status": "green",
"read_status_at": "2025-10-15T03:49:59.000Z",
"write_status": "green",
"write_status_at": "2025-10-15T03:49:56.000Z",
"locations": [
{
"id": 19617,
"name": "Sunshine Dental Care - Phoenix",
"street_address": "456 Oak Avenue",
"street_address_2": "Suite 200",
"city": "Phoenix",
"state": "AZ",
"zip_code": "85001",
"phone_number": "6025551234",
"email": "info@sunshinedental.com",
"inactive": false
}
]
}
],
"count": 1
}
That single call gives you visibility into how current your connected data is, something most legacy APIs can’t even approximate.
Your Advantage
Once your webhook listener is running, you’ve effectively turned a passive healthcare integration into a reactive system.
Instead of: querying for changes every few minutes, parsing incomplete payloads, and guessing if data is up to date....now you’re reacting in real time, just like modern apps in finance or e-commerce do.
That’s a massive step forward for healthcare engineering.
The Bigger Shift
Synchronizer isn’t just syncing data, it’s signaling change.
That difference matters.
It’s what lets modern tools like AI scheduling assistants, automated reporting dashboards, and smart intake systems actually stay in sync with how care happens in real life.
Healthcare doesn’t stand still.
Your API shouldn’t either.
Top comments (0)