Category: English

NexHealth can disable a webhook endpoint after it continues returning errors for 48 hours. Its webhook documentation says non-2xx responses trigger retries. If those errors continue across that period, NexHealth sets the endpoint’s active state to false and stops sending webhooks to it.

Repair the receiver before reactivation. Confirm HTTPS delivery, request validation, durable acknowledgement, and the endpoint’s response path. Then inspect the endpoint and its needed subscriptions, set the intended resource active through the documented update operation, and reconcile the affected business window independently. Reactivation does not by itself prove that events from the inactive period were replayed.

Why did NexHealth set the endpoint to inactive?

NexHealth’s Webhook Endpoints reference describes a fail-safe for receivers that keep returning errors. A response outside the 2xx range is treated as unsuccessful and retried. If the endpoint continues producing errors for 48 hours, NexHealth changes the endpoint’s active property to false and stops sending webhooks to it.

This is endpoint transport state, not a statement about whether the connected EHR is healthy. A NexHealth sync can be green while the webhook receiver is inactive. It can also be red while the endpoint itself still accepts deliveries. Monitor those boundaries separately.

The article on NexHealth sync-status webhook direction covers the read and write health signals, including the current documentation conflict for write events. Endpoint deactivation answers a different question: whether NexHealth will attempt to deliver subscribed webhook events to a registered URL.

Do not reactivate immediately to silence an alert. If the receiver still returns errors, the incident continues and the same protection can apply again. First identify why the endpoint could not acknowledge accepted requests.

Which responses count as errors?

The mapped NexHealth documentation defines success by the HTTP response class. A 2xx response is successful; a non-2xx response triggers retry behavior. That makes the response path a control boundary. The handler should not return success before it has completed the local step required to avoid losing the event.

The exact durable step belongs to the integration design. It may be a committed database record or an accepted message in a durable queue. NexHealth does not require one storage product in these sources. The important distinction is that an in-memory task is not durable merely because the endpoint returned 2xx.

At the same time, do not hold the HTTP request open while running every downstream workflow. A short receiver can validate the request, store the event safely, return the appropriate response, and let a worker perform the slower action. This is operational guidance based on the documented acknowledgement and retry boundary.

NexHealth’s behavior differs from the contract described in Zocdoc’s HTTP 500 webhook handling. Do not reuse one vendor’s retry assumptions for another vendor.

What should be inspected before reactivation?

Start with the current endpoint record. NexHealth provides an operation for listing webhook endpoints, including active-state filtering, and an update operation for changing an endpoint. Confirm that the URL, environment, secret configuration, and intended active state match the receiver that was repaired.

Then inspect the subscriptions attached to the endpoint. An active endpoint and an active subscription answer separate questions. The endpoint determines whether the destination can receive deliveries. The subscription determines which event stream is attached to that destination. The documented subscription update surface includes its own active state.

Do not assume that toggling one resource silently repairs the other. Record the endpoint identifier, subscription identifiers, environment, previous states, approved change, and verification result. Avoid patient payloads. NexHealth warns that webhook events may contain PHI, while this recovery record needs only technical configuration.

If scheduling behavior is also failing, inspect that path separately. NexHealth appointment acceptance outside working hours explains why API acceptance and valid available-slot selection are not the same proof.

How should the receiver be repaired safely?

Repair the narrow cause before changing active. Confirm the public HTTPS endpoint resolves to the intended service, the route accepts the expected method, the receiver can validate the configured secret, and the durable acknowledgement path works when a dependency fails or recovers.

1. Keep the endpoint inactive while the failing route is under repair.
2. Test request validation with synthetic, non-patient content.
3. Prove that accepted events reach durable storage before acknowledgement.
4. Prove that a rejected request returns the intended non-2xx response.
5. Confirm workers process repeated test events idempotently.
6. Inspect endpoint and required subscription states.
7. Reactivate only the approved resources through the documented update operations.

Do not print a webhook secret or full request body during testing. Store secrets in the approved secret manager and use a technical event fingerprint for correlation. Patient names, contacts, reasons, notes, insurance details, and clinical text do not belong in general observability.

A healthy receiver also needs bounded downstream failure handling. If a worker cannot apply an accepted event, keep the event visible for retry or review. Returning 2xx transfers recovery responsibility to the local system.

Does reactivation replay the missing window?

The mapped endpoint pages explain retries, automatic deactivation, active-state inspection, and reactivation. They do not promise that changing active back to true replays every event that occurred while the endpoint was inactive. Treat replay as unproven unless NexHealth supplies a separate current contract for the event and account.

This does not mean that replay never occurs. It means the reactivation response is not sufficient evidence. Build a bounded reconciliation interval from the last trusted processed event through the point when live delivery is verified again. Compare current source state with local state through approved identifiers.

Do not blindly recreate every appointment or resend every message from that interval. An operation may have succeeded through another path, and unconditional replay can create duplicates. The guide to preventing duplicate appointment reminders shows one downstream effect of applying the same scheduling event twice.

Preserve the original appointment lineage during recovery. An event applied after reconciliation is not a new acquisition. Keep the original source and later technical recovery state in separate fields.

How can live delivery be verified after reactivation?

Use an approved non-production environment or a synthetic event that cannot affect a real patient. After reactivating the intended endpoint and subscription, generate one supported test condition, observe the request at the receiver, verify it passes authentication, and confirm the worker reaches the expected technical state.

A 2xx response proves only that the receiver acknowledged that request. Add evidence from durable receipt and downstream completion. Record the endpoint, subscription, event class, one-way fingerprint, receipt time, response class, processing result, and environment.

Also test repeated delivery. The receiver should recognize an already accepted event or make the resulting state idempotent. It should not create another appointment, notification, or conversion merely because the same technical event arrived again.

If availability is involved, verify it through the appropriate API rather than inferring it from webhook traffic. NexHealth availability with an apparently open EHR calendar covers working hours and appointment-type assignment. Webhook recovery does not repair those inputs.

What should monitoring alert on?

Monitor both delivery symptoms and configuration state. Alert on sustained non-2xx responses, endpoint state changing to inactive, an expected subscription becoming inactive, and absence of expected technical events during a period when the business flow is active. Silence alone is not enough without activity context.

Keep EHR sync health beside, but separate from, webhook endpoint health. A useful dashboard shows endpoint active state, required subscription states, recent response classes, durable processing outcomes, and current read and write sync status. One green indicator should not hide another failed boundary.

Resource identity matters as well. When reconciling availability, do not collapse two operatories into one because they share a time. The article on NexHealth operatory identity for the same available time explains that scheduling scope.

Close the incident only after the receiver is stable, intended resources are active, a controlled live delivery completes, and the bounded gap has been reconciled. The active flag is necessary evidence, but it is not the whole recovery proof.

Frequently Asked Questions

What makes NexHealth retry a webhook?

The mapped documentation says NexHealth retries when the endpoint returns a response outside the 2xx range. Repair the response path rather than assuming an error response will remain harmless.

When does NexHealth disable the endpoint?

If endpoint errors continue for 48 hours, NexHealth sets the endpoint’s active state to false and stops sending webhooks to that destination.

Does setting active to true replay missed events?

The mapped pages do not promise complete replay for the inactive window. Reactivate the repaired resources, verify new delivery, and reconcile the gap independently.

Should webhook payloads be copied into application logs?

No. NexHealth warns that webhooks may contain PHI. Log technical identifiers, validation outcomes, response classes, and processing state without copying patient or clinical content.

References

• NexHealth, “Webhook Endpoints,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/webhook-endpoints.
• NexHealth, “Get Webhook Endpoints,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/getwebhookendpoints.
• NexHealth, “Update a Webhook Endpoint,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/patchwebhookendpointsid.
• NexHealth, “Update a Webhook Subscription,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/patchwebhookendpointsidwebhooksubscriptionssubscriptionid.

A Zocdoc visit reason can remain unbookable even when its ID appears in allowed_visit_reason_ids because excluded_visit_reason_ids takes precedence. If the same identifier appears in both fields, the exclusion wins. When both populated arrays contain the same complete set, the timeslot allows no visit reason and cannot be booked.

Fix the conflict in the slot eligibility data, not in the clinic’s EHR mapping or patient workflow. Retrieve the current Zocdoc identifier, compare both arrays, confirm the intended provider, location, and patient type, then publish a corrected complete provider-day. Do not remove an exclusion merely because its label looks familiar.

Why does the excluded list win?

Zocdoc’s Create Timeslots guide defines the relationship directly. allowed_visit_reason_ids limits which reasons may use a slot, while excluded_visit_reason_ids names reasons that may not use it. When an identifier appears in both, the excluded list supersedes the allowed list.

This is a precedence rule, not a merge conflict that the booking client may resolve. A reason in both arrays is not partly eligible, conditionally eligible, or eligible because the allow list was processed first. The final answer for that reason is excluded.

The rule also explains the most confusing failure case. Suppose a slot’s allowed list contains the same populated set as its excluded list. Every allowed candidate is then removed by the higher-priority exclusion. The slot has no eligible visit reason, so the patient cannot book it through that configuration.

Keep this boundary separate from mapping Zocdoc visit reasons to EHR appointment types. A correct local mapping cannot override a Zocdoc slot exclusion. Eligibility must pass before the integration selects any EHR destination.

What do null and empty arrays mean?

The two fields do not use emptiness in the same way as a populated list. Zocdoc documents a null or empty allowed_visit_reason_ids value as no allow-list restriction. It does not mean that zero reasons are allowed. A null or empty excluded_visit_reason_ids value means that no reason is excluded by that field.

Allowed field	Excluded field	Eligibility result
Null or empty	Null or empty	No restriction from either list
Populated	Null or empty	Only listed allowed reasons qualify
Null or empty	Populated	Reasons qualify except those excluded
Populated	Populated	Apply the allowed set, then remove every excluded reason

Do not normalize null or empty allowed values into an empty mathematical set without preserving this vendor meaning. That transformation can turn an unrestricted slot into an unbookable one. Likewise, do not delete the excluded field during serialization merely because the allowed field exists.

How should the effective reason set be calculated?

Calculate eligibility with one explicit rule. Begin with the reasons permitted by the allowed field. If that field is null or empty, begin with the applicable Zocdoc reasons for the scheduling context. Remove every reason named in the excluded field. The remainder is the effective bookable set for that slot.

This description does not authorize the integration to invent the universe of applicable reasons. Use Zocdoc reference data and the approved provider context. The Reference Data guide supplies Zocdoc-specific IDs, and the glossary defines how allowed and excluded reasons behave. Local labels are reviewer aids, not substitutes for identifiers.

A compact diagnostic record can preserve the slot’s technical identifier, provider, location, patient type, allowed IDs, excluded IDs, and computed result. Keep patient names, contact details, visit notes, and clinical text out of this record. The question is slot configuration, not patient history.

Once eligibility succeeds, the local appointment-type mapping is a separate gate. The article on appointment source versus marketing source explains another separation worth preserving: neither an acquisition field nor a campaign label should change which visit reason a slot accepts.

Why can a valid ID still fail?

A valid Zocdoc ID proves that the referenced visit reason exists in the vendor’s reference data. It does not prove that every provider, location, patient type, or timeslot accepts that reason. Validity and eligibility answer different questions.

Start by retrieving or confirming the identifier through the current reference-data surface. Then inspect the exact timeslot object involved in the failed booking. Compare the reason against both eligibility arrays. A reason may be valid globally yet absent from a populated allowed list, present in the excluded list, or both allowed and excluded.

Do not diagnose this by comparing display names alone. Two labels can look similar while representing different IDs or scheduling scopes. Conversely, a label may change while the integration contract still depends on the ID. Preserve both for review, but make the technical decision with the documented identifier.

If the reason is eligible for the slot but booking still fails, move to the next boundary. Check the clinic-owned mapping, destination availability, and request contract. The guide to availability that looks open in an EHR but returns no slots shows why visible calendar space is not enough to prove end-to-end eligibility.

How should a conflicting slot be corrected?

Correct the source rule that produced the conflict. First decide whether the visit reason should be admitted for the exact provider, location, date, time, and patient type. If it should be admitted, remove the unintended exclusion. If it should not, remove the misleading allowance or leave the exclusion as the governing rule.

1. Confirm the current visit-reason ID through Zocdoc reference data.
2. Locate the exact provider-day snapshot that generated the slot.
3. Compare the reason against both arrays before serialization.
4. Resolve the clinic rule that created the contradiction.
5. Recompute every slot for that provider and date.
6. Validate that each slot has the intended effective reason set.
7. Publish one complete corrected provider-day.

The final step matters because the Zocdoc timeslot operation replaces availability for one provider and date. The article on Zocdoc provider-day replacement behavior explains why sending only the corrected slot can remove valid slots omitted from the request.

Do not treat removal from an exclusion list as harmless cleanup. It changes what patients may book. Require the same operational approval used for provider availability and appointment-type rules, then record the rule version without copying patient data.

What checks should run before publication?

Run a deterministic eligibility check on every generated slot. Confirm that all populated IDs exist in current reference data, detect duplicates, compute the final set with exclusion precedence, and reject a slot whose final set is empty when the clinic intended it to be bookable.

The check should distinguish an intentional restriction from an accidental contradiction. A slot may correctly exclude one reason while admitting others. The failure worth blocking is a mismatch between the approved scheduling rule and the computed output, not the mere presence of an excluded list.

Test the main combinations with synthetic configuration. Cover unrestricted fields, allowed-only, excluded-only, partial overlap, and complete overlap. For partial overlap, verify that only the overlapping reason is removed. For complete overlap, verify that the slot is recognized as having no eligible reason.

Also test the corrected full-day publication. Confirm that unrelated slots remain present and the target reason becomes bookable only where approved. If appointment actions are part of the test, use synthetic records and follow the documented boundary for Zocdoc cancellation and reschedule webhooks.

How should this failure be monitored?

Monitor the effective eligibility result, not only the presence of values in the two source fields. An alert that says “reason appears in allowed list” misses the precedence rule. A useful signal says that a provider-day contains a slot whose computed set is empty or differs from the approved rule.

Record technical scope, list hashes or identifiers, computed count, validation result, rule version, and publication result. Do not place full appointment payloads or patient data in general logs. When the same configuration repeatedly returns, trace the upstream rule generator instead of patching each serialized payload.

After correction, verify the current slot behavior. A successful request proves acceptance of the submitted payload, not that the business rule was correct. Keep the operational verification separate from later appointment status updates such as the Zocdoc no-show reporting window.

Frequently Asked Questions

Does allowed_visit_reason_ids override an exclusion?

No. Zocdoc documents that the excluded list takes precedence. A visit-reason ID present in both arrays remains excluded from that timeslot.

Does an empty allowed_visit_reason_ids array block every reason?

No. The documented behavior treats a null or empty allowed list as no allow-list restriction. Apply any populated excluded list separately.

What happens when both arrays contain the same reasons?

Every candidate admitted by the allowed list is removed by the excluded list. The slot then has no eligible visit reason and is unbookable.

Can an EHR appointment-type mapping make the reason bookable?

No. The local mapping runs after slot eligibility. It can select an approved destination for an eligible reason, but it cannot override Zocdoc’s exclusion rule.

References

• Zocdoc for Developers, “Create Timeslots,” reviewed August 16, 2026, https://api-docs.zocdoc.com/guides/scheduling/create-timeslots.
• Zocdoc for Developers, “Glossary,” reviewed August 16, 2026, https://api-docs.zocdoc.com/guides/glossary.
• Zocdoc for Developers, “Calendar Integration Timeslots API,” reviewed August 16, 2026, https://api-docs.zocdoc.com/apis/calendar-integration-timeslots.
• Zocdoc for Developers, “Reference Data,” reviewed August 16, 2026, https://api-docs.zocdoc.com/guides/reference-data.

A clinic’s Google Business Profile verification video is rejected when it does not show the required evidence in one acceptable recording: the real location, the business’s permanent presence, and the recorder’s authority to manage it. Review the stated issue, clear the clinic of patients and private material, then record a new live video.

The video must be continuous, unique, at least 30 seconds long, and recorded through the Business Profile on a mobile device. Never film patients, other people’s faces, charts, screens, IDs, forms, mail, or sensitive documents. Google permits non-sensitive business documents as management evidence in applicable flows, but a clinic can usually prove control through safe physical access with less privacy risk.

Why was the clinic’s verification video rejected?

Google lists practical rejection examples: the business name was not visible on the storefront, the nearby area was missing, or the recording did not prove authority to operate the business. A polished tour cannot compensate for one missing category. The reviewer needs connected evidence that matches the profile being verified.

Start with the notice under Review issues. Treat each listed problem as a required correction. Keep everything that was clear in the first attempt and add the missing evidence in the new recording. Do not edit the old file or upload a prerecorded replacement. Google requires a fresh live recording through the profile.

A video rejection does not mean the clinic should create another Business Profile. It also does not establish suspension, duplicate status, or ineligibility. Those are different states with different remedies. Verify the exact message before changing the profile’s name, category, or address.

If the profile’s appointment link has a separate problem, use the guide to why Google removed a clinic appointment link. Link review and business verification should remain separate investigations.

What must a storefront clinic show in the new recording?

A storefront clinic should connect three facts in one continuous route. First, show the real surroundings with a street sign, building number, nearby business, or recognizable place. Second, show the clinic’s name on permanent signage. Third, show that the recorder is authorized to manage the location through access that an ordinary visitor would not have.

The name on the permanent sign should match the Business Profile. A temporary paper taped to a door is weak evidence of a permanent presence. If the clinic shares a building, include enough exterior context to locate the correct suite without sweeping the camera across other people’s private activity.

For management proof, prefer a safe physical action. An authorized employee can unlock the clinic entrance or open a staff-only room after confirming that it is empty. Google also allows non-sensitive business documents in applicable cases. If one is needed, inspect every visible field first and exclude personal, clinical, financial, or confidential information.

Clinic structure matters before verification. A medical office may have a location profile and eligible practitioner profiles. Read who controls a Business Profile booking link to understand ownership boundaries, then confirm that the video and account belong to the same entity.

How can a clinic record safely without patients or documents?

Schedule the recording when the premises are closed to patients and visitors. Tell staff not to enter the route. Clear whiteboards, sign-in areas, delivery labels, wall schedules, patient materials, mail, and loose private paper from the camera’s view. Turn monitors off rather than trying to blur them later, since the video cannot be edited.

Walk the route before opening the recorder. Begin outside with location evidence, move to the permanent business sign, then demonstrate controlled access. Keep the camera aimed narrowly. Stop and restart the whole process if a person, private document, screen, or confidential conversation enters the frame.

Do not ask a patient to appear, even with permission. Do not use a patient chart or appointment list as proof that the clinic operates. The official requirement is proof of the business and the recorder’s management authority. Patient information adds no useful verification value.

The same restraint applies after verification. The article on safe clinic responses to Google reviews explains why public profile management should avoid confirming a person’s relationship with the practice.

Can the clinic choose a different verification method?

Not on demand. Google says it automatically determines the methods offered to a Business Profile, based on factors such as business type, public information, region, and business hours. The available options can include video, phone or text, email, live video call, or mail. Some profiles may need more than one method.

Use the options shown in the profile. If video is available and the first recording failed, select Review issues and follow the listed corrections. If another method is offered, the clinic can use that displayed route. Support cannot be treated as a shortcut for inventing an option that the profile does not offer.

Keep verification codes private. Google states that it will not ask the business to share a code. An agency or vendor should receive manager access after ownership is established, rather than controlling the clinic through a personal account or asking staff to forward codes.

Changing the business name, address, or category while troubleshooting can trigger more review or re-verification. Make only corrections that reflect the real clinic. Do not reshape the profile to chase a supposedly easier verification method.

How should the clinic respond to “Review issues”?

Read every reason before recording again. Translate each issue into a visible scene. If the business name was missing, plan a clear view of permanent signage. If the nearby area was absent, add the building number and surrounding context. If management proof was missing, plan a safe staff-only access action.

Then create a short shot list without filming it. The recording itself must remain one unedited sequence. Confirm mobile location, camera, and microphone permissions before starting. Use a stable network and stay inside the Business Profile workflow so the recording can upload from the device.

After recording, review the preview for accidental private material. If anything appears, discard it and record again. Google allows a new attempt when the requirements were not met. A failed first video does not justify accepting privacy exposure in the second.

Google says review can take up to five business days. Wait for the stated result rather than making repeated profile edits during that period. If the second attempt fails, compare the new notice with the shot list and contact support only after the available verification route has been followed carefully.

What does verification prove, and what remains unproven?

Verification gives the clinic ownership of the Business Profile and supports accurate management of its public information. It does not prove that appointment links work, that a scheduling vendor writes to the correct calendar, or that calls and bookings came from a specific marketing source.

After approval, inspect the public profile in Search and Maps. Confirm name, location, phone, hours, website, and appointment action. If a former vendor still controls a link, follow the process for removing a third-party booking link rather than deleting every booking option.

Verification also does not authorize the clinic to send health-related details to analytics or advertising products. Keep URLs, event names, support screenshots, and campaign reports generic. Public profile ownership and data-use permission are separate decisions.

Do not report the video as acquisition proof. A successful verification tells the team that Google accepted the evidence of business control. It does not quantify visibility, calls, directions, appointments, new patients, or revenue.

How can the clinic avoid another verification failure?

Keep the Business Profile under a clinic-controlled account and assign named managers. Record the exact public name, address, category, permanent signage, and ownership contacts in an internal control note. Do not store verification videos in general marketing folders or forward them through informal channels.

Review access when staff, agencies, or vendors change. Re-verification can follow changes to business information, so plan evidence before editing high-impact fields. The physical sign, public profile, website, and booking destination should describe the same clinic entity.

Use a reusable privacy checklist for any future recording: empty premises, clear route, screens off, no people, no sensitive documents, and no private audio. If non-sensitive business evidence is needed, approve it before recording and expose only what the verification requires. The checklist can be retained. The video itself should be deleted through the profile when it is no longer needed and Google offers that control.

If the clinic has multiple locations, keep one evidence set per eligible profile. Do not reuse another branch’s exterior, sign, or staff access. Each verification should establish the location and management authority of the profile in front of the reviewer.

Frequently asked questions

Can the clinic upload a prerecorded or edited verification video?

No. Google requires a live, unique, continuous recording made and uploaded from a mobile device through the Business Profile. If the route fails or private material appears, discard it and make a new complete recording.

Should a patient appear to prove the clinic is operating?

No. Keep patients and all other faces out of the video. Show the location, permanent signage, and safe staff-only control instead. A patient adds privacy risk and is not needed to prove management.

Can the clinic film a license, invoice, or schedule?

A patient schedule should never be filmed. Google can accept non-sensitive business documents such as a license or invoice as management evidence in applicable cases. For a clinic, prefer physical access when it proves control; if a document is necessary, confirm it contains no personal, clinical, financial, or confidential information.

Does video approval guarantee the appointment button will work?

No. Verification establishes control of the profile. The clinic still needs to test the public link, correct location, booking action, schedule write-back, privacy controls, and marketing measurement separately.

References

• Google Business Profile Help, “Verify your business with a video recording”, retrieved August 16, 2026, https://support.google.com/business/answer/14271705?hl=en
• Google Business Profile Help, “Verify your business on Google”, retrieved August 16, 2026, https://support.google.com/business/answer/7107242?hl=en

A Zocdoc appointment can be updated to no_show only after its start time is in the past and while that start is no more than two days old. The Scheduling API documents this rule for PUT /v1/appointments/update-status. Once a record is outside that window, continuing the same request indefinitely is not a supported recovery strategy.

The practical fix is to process post-appointment outcomes promptly, surface stale records for review, and keep local reporting separate from the Zocdoc update result. Do not rewrite “two days” as a different unit or promise a particular error response that the cited guide does not document.

What does the update-status endpoint permit?

Zocdoc’s Appointment Actions guide describes PUT /v1/appointments/update-status as the endpoint for updating a booked appointment after its scheduled time. The documented post-appointment statuses are arrived and no_show.

The glossary defines no_show as a patient who did not appear for a confirmed appointment. That definition matters. A cancellation, reschedule, unconfirmed request, integration failure, or staff uncertainty should not be translated into a no-show merely because the original start time passed.

Use the appointment’s actual state and the source contract. The guide to which Zocdoc cancellation and reschedule changes trigger webhooks covers different lifecycle actions. A webhook about a changed booking is not evidence that a completed appointment should be marked no_show.

Keep the outbound request narrow. The status update needs the identifiers and status required by the API. Operational logs can record a synthetic appointment reference, attempted status, attempt time, response class, and final workflow state. They do not need a name, phone number, visit reason, insurance value, or clinical note.

Why does the no-show update have a two-day window?

The official Appointment Actions guide states the boundary: for a no_show update, the appointment start must be in the past but no more than two days old. This defines when the API action is permitted. The source does not explain a broader policy rationale, so an integration should not invent one.

Treat “two days” as the wording of the contract. Do not silently convert it into “48 hours,” end-of-day logic, clinic-local calendar days, or another threshold unless Zocdoc provides that interpretation for the integration. If an edge case matters, test it in the supported environment or ask Zocdoc for clarification.

The time restriction means status collection cannot be an unbounded background task. A queue that waits through repeated outages may eventually contain an appointment that is no longer eligible for the no-show call. Retrying the same payload forever will not make the appointment recent again.

Operational inference: calculate urgency from the scheduled start and current eligibility, while allowing room for transport failures and human review. Zocdoc documents the boundary, but it does not prescribe the clinic’s queue interval or escalation schedule.

How should arrived and no_show remain distinct?

Both values describe an outcome after the appointment time, but they are not interchangeable. arrived represents attendance; no_show represents the absence defined in the glossary. A delayed front-desk update does not make every unresolved appointment a no-show.

Build the decision from an authoritative operational event. That may be a completed check-in, a staff-reviewed disposition, or another clinic-approved signal. The integration should not infer absence from a missing webhook, a blank field, or a temporary inability to reach the source system.

Likewise, do not use no_show to repair a cancellation or reschedule mismatch. Preserve the appointment lifecycle and investigate its actual transition. The article on preserving original booking source after a reschedule explains why changing operational state should not erase acquisition lineage.

A stale local record can remain classified for internal review even if the vendor update is no longer eligible. That local state must be labeled honestly. “Observed by clinic, not confirmed updated in Zocdoc” is different from “Zocdoc status updated.”

What queue design respects the window?

Store post-appointment candidates with their scheduled start, current local outcome, vendor appointment identifier, and next action. When the approved source confirms a no-show, attempt the update while the documented time condition still holds.

Separate temporary delivery failure from contract ineligibility. A network interruption or retryable server response may justify another bounded attempt. A record that has aged outside the allowed window needs a terminal workflow state and human-visible explanation, not another automatic request.

1. Confirm the appointment start is in the past.
2. Confirm the clinic’s source supports the no_show outcome.
3. Check that the start is no more than two days old.
4. Send the status update with the required vendor identifier.
5. Record success, retryable uncertainty, or stale review as different states.
6. Stop automatic retries when the request is outside its supported window.

Do not assume webhook delivery will recover the task. The analysis of Zocdoc appointment webhooks after an HTTP 500 shows why inbound delivery behavior and outbound status updates need separate reliability controls.

What should happen after the window has passed?

Surface the item as stale. Preserve the clinic’s evidence and the last vendor response, but do not label the external update successful. The cited guides establish the eligibility boundary; they do not promise a specific error code or a late-update exception.

Human review can determine whether the local scheduling record, reporting layer, or support process needs correction. If the vendor record must be changed, follow a documented Zocdoc support path rather than inventing an API workaround or substituting another status.

Do not delete the stale item simply to clear a queue. Keep a technical audit trail with timestamps, synthetic or opaque identifiers, attempt count, response category, and reviewer outcome. Limit access and retention according to the clinic’s approved policy.

Reporting should expose the uncertainty. A dashboard may count a clinic-confirmed outcome separately from a vendor-confirmed update. For rate definitions and denominator choices, see how to calculate no-show rate by booking source. The status API alone does not define the whole metric.

How can retries avoid duplicates and false success?

Make each attempt refer to the same Zocdoc appointment and intended status. Before retrying, reload current local state and check whether a prior attempt already succeeded. A worker that loses its acknowledgement should not create a second local outcome or send contradictory updates without review.

Bound retries by both error class and time eligibility. Authentication problems, invalid identifiers, contract rejection, and a temporary connection failure are not the same condition. Preserve the shortest useful response evidence without copying request content that can expose patient information.

Use a dead-letter or review state for unresolved work. Include the reason that automation stopped, such as “outside documented no-show window” or “current vendor result unknown.” Avoid a generic failure flag that invites an operator to press retry after the action has become ineligible.

If visit-reason mapping is also failing, resolve it as a separate contract. The guide to mapping Zocdoc visit reasons to EHR appointment types explains that boundary. A mapping defect is not evidence that attendance should change.

How should the behavior be tested?

Use Zocdoc’s documented testing data and an approved non-production setup for baseline contract checks. Create only synthetic appointments. The test record should contain a neutral identifier and the minimum scheduling fields needed by the sandbox, never a real patient name, contact detail, visit reason, insurance value, or clinical note.

Test the eligibility function locally with a deterministic clock and synthetic timestamps. Cover a future start, a recent past start, and a start outside the documented two-day condition. Confirm the first and third cases do not call the vendor client and the stale case enters review. Zocdoc’s Testing Data guide does not document a clock-control fixture for this window.

Also simulate a temporary transport failure around the local boundary. Verify the retry uses the same synthetic appointment, does not create a duplicate local outcome, and stops if the deterministic clock moves beyond eligibility. If an end-to-end sandbox test of the outside-window response is required, obtain a supported fixture or procedure from Zocdoc first. Record API response metadata without storing patient payloads.

Finally, test an arrived result separately from no_show. The goal is to prove that the workflow follows an authoritative disposition, not the mere passage of time. Keep any edge interpretation of “two days” out of production until confirmed by documentation or Zocdoc support.

What evidence should operators and reviewers see?

An operator needs scheduled start, local outcome, eligibility result, last attempt time, response category, and next action. A reviewer needs the source rule and a trace showing why automation sent, retried, or stopped. Neither view requires patient or clinical content.

Use clear labels: “eligible and queued,” “vendor update confirmed,” “delivery uncertain,” and “outside documented window.” These labels prevent a locally observed no-show from being presented as a completed external update.

Monitor the age of unresolved candidates so the team can act before they become stale. This is a clinic-defined operational control, not a new Zocdoc guarantee. Report volume and outcome by booking source without changing the original source when staff resolve an exception.

Frequently asked questions

Can no_show be sent before the appointment starts?

No. Zocdoc documents that the appointment start must be in the past for a no_show update. Wait for an authoritative post-appointment outcome rather than scheduling the status in advance.

Does Zocdoc define the no-show window as 48 hours?

The cited guide says the appointment start can be no more than two days old. It does not restate that boundary as 48 hours. Do not substitute an interpretation without confirmation.

Should a stale no-show update keep retrying?

No. Once the request is outside the documented condition, move it to a visible review state. Preserve local evidence and do not claim the Zocdoc status was updated.

Is an unconfirmed appointment automatically a no-show?

No. The Zocdoc glossary describes a no-show as a patient who did not appear for a confirmed appointment. Cancellation, reschedule, uncertainty, and delivery failure require their own states.

References

• Zocdoc, “Appointment Actions,” reviewed August 16, 2026, https://api-docs.zocdoc.com/guides/scheduling/appointment-actions.
• Zocdoc, “Glossary,” reviewed August 16, 2026, https://api-docs.zocdoc.com/guides/glossary.
• Zocdoc, “Testing Data,” reviewed August 16, 2026, https://api-docs.zocdoc.com/guides/testing-data.

Do not assume NexHealth sync-status webhooks reliably announce every change from green to red. For read sync, the Webhook Subscriptions reference documents red-to-green recovery and says green-to-red does not trigger the event. For write sync, the page’s prose says recovery-only while its example shows sync_status_write_change.red with write_status set to red. That contradiction needs NexHealth confirmation before a team relies on write-side event direction.

The safer documented monitoring path is to inspect GET /sync_status and evaluate read_status_at and write_status_at. Those timestamps need context because NexHealth warns that activity outside business hours, especially on weekends and holidays, can make them appear several hours or days old. Webhooks and polling therefore provide different evidence.

What do NexHealth sync-status webhooks actually report?

NexHealth lists separate events for read and write functionality. The documented read event fires when an integration’s read status moves from red to green. The page’s prose assigns the same recovery direction to write functionality, but its write example instead uses sync_status_write_change.red and reports write_status as red.

The source explicitly says the read webhook does not currently trigger from green to red. Its write prose makes the same statement, yet the contradictory example prevents a categorical write-side conclusion. Treat read failure notification as absent and write failure notification as undocumented until NexHealth resolves the conflict.

Do not treat either event as a complete uptime feed. A recovery event can confirm a return to service after NexHealth observes the transition, but it cannot prove when the red state began. A possible write-red event does not establish a complete delivery guarantee either. Detect degraded connectivity through an independent status check.

This differs from appointment delivery behavior. The guide to Zocdoc webhook retry boundaries concerns transport acknowledgement for appointment events. A NexHealth sync-status event concerns EHR integration health. Keep those two kinds of monitoring separate.

Why is waiting for a green-to-red event unsafe?

A webhook-only monitor can remain quiet while reads are red because the missing transition is documented behavior. Write-side silence is also ambiguous because the source conflicts about failure events. It can mean the integration stayed healthy, no relevant event occurred, or a failure was not delivered to the listener.

That ambiguity matters for scheduling. If reads are degraded, the application may not have current appointments or unavailability blocks. If writes are degraded, a booking request may not reach the connected record system as expected. Neither condition should be translated into a positive claim merely because no webhook arrived.

Operational inference: use the status query as the failure-detection input and treat webhooks as supplementary transition signals. Confirm write-event direction with NexHealth before making it a control dependency. This is not a polling interval prescribed by NexHealth. Each team must choose a cadence that fits its booking risk, API limits, business hours, and incident process.

If a status problem first appears as an empty availability response, also inspect the scheduling inputs. NexHealth availability can be empty despite an open EHR calendar when working hours or appointment-type assignments do not qualify. Sync health and availability configuration are related evidence, not interchangeable diagnoses.

How should GET /sync_status be monitored?

The sync-status endpoint can be scoped by institution through subdomain. Its documented query options include read status, write status, and location identifiers. That lets a monitor ask about the exact integration scope used by the booking flow instead of reducing every location to one account-wide light.

Track read and write independently. A location can need fresh read state for availability while also needing working write state for appointment creation or changes. One green value should not hide a red value in the other direction. Display both status and the corresponding last-success timestamp.

Store a technical snapshot rather than a patient payload. Institution alias, location scope, observed read state, observed write state, timestamp ages, request result, and monitor time are enough for the health question. Patient names, contact details, appointment reasons, notes, and insurance data add no value to this test.

A status monitor also should distinguish a successful API response from a healthy integration. An HTTP response can carry a red status. Conversely, a failed status request leaves health indeterminate rather than proving the EHR is red or green. Preserve those states separately in alerts.

How do off-hours delays change alerting?

NexHealth warns that read_status_at and write_status_at can show delays of several hours or days outside business hours, particularly on weekends and holidays. An old timestamp alone is not enough to declare an outage without considering whether the connected practice was expected to generate activity.

This warning does not mean stale timestamps should be ignored. It means the monitor needs context. A timestamp that is normal for a closed office may be suspicious during active booking hours. Use the practice’s documented schedule as an operational input, not a vendor-wide threshold invented for every location.

Operational inference: alert on a combination of state, timestamp age, expected activity, and failed business operations. Keep the rule visible to clinic IT so a holiday schedule can be explained without silencing a genuine write failure.

Working hours themselves have a separate role in availability calculation. The article on NexHealth appointment validation outside working hours explains why an accepted API call and a valid booking slot are different claims. Do not reuse clinic hours as proof that sync is healthy.

What should the booking flow do while status is uncertain?

Make uncertainty explicit. If current EHR reads cannot be established, do not convert missing busy records into free time. If write health is red or unknown, do not present a local request as a completed EHR booking. The safest user-facing state is pending, unavailable, or under review, according to the clinic’s approved workflow.

Do not silently switch to a different calendar or operatory. A fallback may have different scope and may create a duplicate appointment. The discussion of overlapping operatories in NexHealth availability shows why resource identity must remain attached to a time.

Separate read controls from write controls. A practice might decide that existing appointments remain viewable from a recent local mirror while new bookings pause. Another practice may require the whole scheduler to close. NexHealth documents the status surfaces, but the acceptable degraded mode belongs to the clinic and its application.

Show operators which capability is affected. “Integration issue” is too broad. “EHR reads are red; online slots paused” or “EHR writes are indeterminate; requests held for review” makes the state actionable without exposing appointment content.

How should recovery be reconciled after red turns green?

A red-to-green read webhook confirms the documented recovery transition. A red-to-green write event is also consistent with the page’s prose, despite its contradictory red example. Neither proves that every operation attempted during degradation reached the EHR or that the local mirror is complete. Treat a recovery signal as a trigger to start reconciliation, not as automatic closure.

Review the bounded interval between the last trusted success and observed recovery. Compare queued or uncertain technical operations with current EHR state through approved identifiers. Do not replay every request blindly. A booking may have succeeded before connectivity became uncertain, and an unconditional replay could create a duplicate.

Operational inference: make reconciliation idempotent and preserve the original booking lineage. A recovered write should not become a new acquisition event or replace the original channel. The distinction in appointment source versus marketing source remains valid during incident recovery.

Close the incident only when current status is known, affected locations are checked, uncertain operations have an outcome, and availability is based on refreshed state. The recovery webhook is one piece of that evidence.

What controlled test proves the monitoring design?

Use a sandbox or approved non-production integration with synthetic records. Test read and write monitoring separately. The goal is not to force a production EHR outage. It is to prove how the application behaves when the status endpoint reports red, when the endpoint itself fails, and when a recovery event arrives.

1. Capture a known green read and write state for one controlled location.
2. Feed the monitor a controlled red read state and verify availability fails closed.
3. Feed it a controlled red write state and verify new writes remain visibly uncertain.
4. Test an unavailable status endpoint and confirm the state becomes indeterminate.
5. Deliver a red-to-green recovery event and verify reconciliation starts.
6. Confirm no test record contains real patient or clinical information.

Also test off-hours context. A delayed success timestamp during a configured closure should follow the documented alert rule, while an explicit red state should remain visible. Record the exact status inputs and resulting control decision so reviewers can reproduce the outcome.

Frequently asked questions

Does NexHealth send a webhook when read status changes from green to red?

No. The current Webhook Subscriptions reference says the read-status webhook fires from red to green and does not currently trigger from green to red. Use the sync-status endpoint to monitor the failure state.

Are read_status_at and write_status_at outage timestamps?

They are last-success timestamps used to assess sync health, but NexHealth warns they can lag outside business hours. Interpret their age with location schedule and current status rather than treating any delay as a confirmed outage.

Does the write-status webhook report a change from green to red?

The current reference is internally inconsistent. Its prose says the write event reports red-to-green recovery and does not trigger green-to-red, while its example shows a red write event. Ask NexHealth to confirm current behavior and monitor GET /sync_status instead of depending on one interpretation.

Should missing EHR reads be treated as open availability?

No. Missing or indeterminate calendar state is not evidence of free time. Pause or qualify availability according to the clinic’s approved degraded-mode policy until current read health and calendar coverage are established.

References

• NexHealth, “Webhook Subscriptions,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/webhook-subscriptions.
• NexHealth, “View sync statuses,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/getsyncstatus.