Does a Calendly Webhook Tell a Clinic That a Patient Rescheduled Rather Than Booked Twice?

No. Calendly does not present rescheduling as a separate webhook event type. The documented pattern is an invitee.canceled event for the old booking followed by an invitee.created event for the new booking. The old and new invitee records provide the link that lets a clinic reconcile one reschedule instead of counting two bookings.

What does Calendly send during a reschedule?

Calendly’s webhook guide shows that an invitee who reschedules causes the original invitee to be canceled and a new invitee to be created. The new payload includes a relationship to the old invitee. The help documentation describes the same relationship from the user’s point of view.

That means an integration should not search only for an event named rescheduled. It should consume the two documented events, persist both payloads in a bounded audit record, and apply a reconciliation rule. If the first event arrives without the second, the appointment should be marked pending reconciliation rather than permanently canceled.

The reschedule webhook comparison shows why vendor-specific event names cannot be generalized. Calendly’s model is its own contract.

How should a clinic join the old and new bookings?

Store the Calendly invitee URI or identifier, the event URI, the event type, the received timestamp, and any old_invitee or new_invitee reference supplied by the payload. Then make the new invitee point to the previous internal appointment or attribution record.

Do not use the patient’s name or time alone as the join key. Two patients can share a name, and a reschedule changes the start time. A stable vendor identifier plus a tenant-scoped internal ID is safer and easier to audit.

Local field	Purpose
vendor_invitee_id	Unique Calendly invitee reference
previous_invitee_id	Old invitee referenced by a reschedule
appointment_id	Internal booking identity that survives time changes
lifecycle_state	Booked, canceled, rescheduled, or needs review
source_attribution_id	Approved marketing source record without clinical detail

What if events arrive out of order?

Webhooks are messages delivered over a network, not a synchronous database transaction. The new invitee can arrive before the canceled event, or a retry can deliver an event more than once. A handler must be idempotent and able to reconcile later.

1. Verify the webhook signature and tenant routing.
2. Record an event ID or deterministic fingerprint before applying side effects.
3. Upsert the vendor invitee record.
4. Resolve old and new references when both are available.
5. Update the internal appointment once, preserving its attribution identity.
6. Send unresolved references to a review queue instead of guessing.

The webhook retry article covers the same need for explicit acknowledgement and retry handling. A 200 response means the receiver accepted the message, not that the booking was reconciled correctly.

How should reporting count a reschedule?

Count one booking journey, not two new patients. Keep a status history that records the original time, the cancellation event, the replacement time, and the final appointment state. If the clinic optimizes Google Ads for booked appointments, the reschedule should normally update the existing outcome rather than create a second conversion.

That reporting rule is an internal measurement choice. A clinic may define separate events for booked, attended, or completed, but each event needs a stable transaction ID and a clear deduplication rule. The booking outcome taxonomy helps keep those states separate.

What data should the webhook handler avoid?

Store only fields needed for scheduling, reconciliation, attribution, and audit. Do not copy free-text intake answers, treatment notes, diagnoses, or payment details into a webhook log. Keep the raw payload in a protected store only when the contract and retention plan require it, and redact sensitive values from ordinary application logs.

A booking integration can prove that a slot changed without exposing the patient’s entire record to a marketing dashboard. The internal appointment ID and vendor reference are usually more useful than a copied patient profile.

FAQ

Does invitee.canceled mean the patient is lost?

Not necessarily. When a reschedule follows, the old invitee is canceled as part of the transition.

Can the new invitee be treated as a new lead?

Only when the clinic’s business rule says so. The vendor relationship normally indicates a continuation of the same booking journey.

What if the old invitee reference is missing?

Hold the event for reconciliation. Do not join by name and time alone.

Should a browser conversion fire twice?

Not for the same internal booking outcome. Use a stable transaction ID and an explicit reschedule rule.

References

• Calendly developer guide: reschedule webhook payloads
• Calendly Help: rescheduled meetings

Not legal advice: This article describes webhook behavior and an integration pattern. Review privacy, retention, and healthcare obligations for the actual clinic and vendors.