How Do I Stop a Booking Integration from Overwriting a Newer Google Calendar Edit?

A booking integration can overwrite a newer Google Calendar edit when it sends an update based on an old copy of the event. Google Calendar exposes an etag for each resource version. Send the previously retrieved value in the If-Match header when updating or deleting an event. If someone changed the event after your read, Google returns HTTP 412 Precondition Failed instead of applying the stale write.

A 412 is a conflict signal, not permission to repeat the same request without the condition. Fetch the current event, compare the changes, and decide which fields can be reapplied. This protects a receptionist’s newer time, status, or note from a background worker that is still holding an earlier event version.

How does a stale booking update overwrite a newer edit?

Consider two actors working on one calendar event. A scheduling integration retrieves the event at version A. A staff member then edits the event in Google Calendar, creating version B. If the integration later sends its full copy of version A as an unconditional update, fields from the staff member’s change may be replaced by the stale values.

The problem is timing, not necessarily a bad payload. Both actors may have made valid changes. The integration simply did not prove that the version it read was still current when it wrote.

Google’s resource-version guide describes conditional modification as the mechanism for this case. The client retrieves an etag, includes that value in If-Match, and asks Google to modify the resource only if the version has not changed in the meantime.

This issue is separate from incremental synchronization. An expired sync cursor requires the recovery covered in Google Calendar 410 Gone during appointment sync. An etag conflict concerns one resource version at write time.

What does If-Match change?

Without a matching condition, the server evaluates the update under the endpoint’s ordinary rules. With If-Match, the client states which event version it intends to modify. Google compares the supplied value with the current resource etag.

If the values match, the modification succeeds and Google returns the new resource version with a new etag. If they do not match, Google returns 412. The older request does not silently replace the newer server state.

Use the etag from the same event version that supplied the fields used to construct the update. Do not fetch an etag in a separate step and attach it to a payload built from an older cache. That would prove only that the separately fetched version was current, not that the payload represented it.

Operational inference: store the event identifier, retrieved etag, and local source version together for the duration of the write. A queue job should either carry that coherent version tuple or fetch and rebuild its intended change immediately before submission.

What should happen after HTTP 412?

Google says clients can retrieve the resource again and reapply their changes. That does not mean every field from the stale copy should be copied onto the current event. Reapplying should mean reconstructing the intended change against the latest server version.

First retrieve the current event. Then compare the integration’s intended fields with the fields that changed on the server. A simple nonconflicting change may be safe to reapply. A changed appointment time, cancellation state, calendar ownership, or another scheduling decision may require an operator or an authoritative source-of-record rule.

Operational inference: classify conflicts by field and source. If the worker intended to add an internal correlation property while staff changed the start time, it may be possible to apply only the property to the new version. If both sides changed the start time, automatic last-write-wins behavior hides a real scheduling conflict.

Set a retry ceiling. A resource that changes repeatedly can produce several 412 responses. After the limit, move the operation to a visible reconciliation queue. Do not remove If-Match to make the error disappear.

Should update, delete, and insert use the same rule?

Google documents conditional modification for updates and deletes. Both operations can include If-Match when they should proceed only against the version previously retrieved.

Insert is different. Google’s guide says conditional modifications are not supported for insert operations. When an API operation allows the client to supply a resource ID, Google instead guarantees that creation succeeds only if no existing entry has that ID.

Do not turn that statement into a universal booking-idempotency claim. The application still needs a documented event-ID strategy, request retry behavior, and reconciliation process. The resource-version guide establishes the conditional-modification boundary, not the clinic’s complete creation contract.

A delete also deserves care. A stale delete may target an event that staff rescheduled or otherwise changed after the integration’s read. Sending the old etag in If-Match makes that later edit visible as a conflict rather than erasing it.

How should event versions be stored?

Store the latest known etag beside the corresponding Google event identifier in the calendar mirror. Replace it whenever a successful retrieval or modification returns a newer resource version. Keep it tied to the correct calendar and event.

An etag is not the appointment’s business status. It cannot tell the integration whether the patient confirmed, attended, cancelled, or rescheduled. It only identifies the version of the Google resource. Keep booking state in its defined system and map calendar changes through an explicit reconciliation rule.

Do not copy event descriptions, attendee details, patient names, or clinical notes into conflict logs. A useful record can contain an approved calendar alias, event identifier or fingerprint, old and current version fingerprints, operation type, fields in conflict, response status, and resolution outcome.

Calendar coverage matters as much as version control. Secondary Google calendars in Jane online booking explains why a correct write to one calendar does not prove that every calendar affecting availability is covered.

When is conditional retrieval useful?

Google also supports conditional retrieval with If-None-Match. A client sends the etag from its current copy. If the resource changed, Google returns the new version. If it did not change, Google returns HTTP 304 Not Modified.

Conditional retrieval can reduce unnecessary data transfer, but it does not replace If-Match at the write boundary. A client may confirm that an event is current and still lose a race before its later update. The write itself needs the version condition.

Google notes special cases in which an etag does not change, including certain read-only changes on a calendarList entry. Do not generalize event-update behavior to every Calendar resource without checking its contract.

When the integration only needs occupancy rather than event fields, review Google Calendar FreeBusy errors and provider slots. Fetching a detailed event and guarding its write solve a different problem from deciding whether a time is busy.

How can the conflict path be tested?

Use a synthetic event in an authorized test calendar. Retrieve the event and save version A. Modify it separately to obtain version B. Then attempt an update with version A in If-Match. The acceptance condition is an HTTP 412 response and preservation of the version B change.

Next, fetch version B, apply only the intended nonconflicting change, send its etag, and confirm the request succeeds with a new etag. Repeat the test for a conditional delete. Keep every title, attendee, description, and identifier synthetic.

Test a true conflict in which staff and the integration both change the appointment time. The application should stop or invoke its approved resolution rule. It should not silently choose whichever write happened last.

Finally, interrupt the job after a 412 and before resolution. On restart, it should fetch the current event again rather than reuse the stale payload. This proves that the queue stores intent and version evidence instead of blindly replaying an obsolete resource.

What should operations monitor?

Track conditional-update attempts, 412 rate, repeated conflicts for one event, resolution time, retry count, and operations sent without If-Match. These thresholds are operational choices. Google does not prescribe clinic-specific alert limits in the resource-version guide.

A rise in 412 responses may mean staff and automation are editing the same fields or that queue latency is making versions stale. Inspect the operation type and conflict fields before changing the policy. Removing the condition would reduce the visible error while increasing the chance of lost edits.

Keep acquisition reporting outside conflict resolution. A calendar edit does not establish a new booking source. The guide to appointment source versus marketing source shows which evidence should remain stable after operational changes.

Frequently asked questions

What does Google Calendar HTTP 412 mean here?

It means the etag in If-Match did not match the current resource version. The event changed after the client retrieved the older copy.

Should the integration retry without If-Match?

No. Fetch the latest event, resolve the conflict, and retry with the current version. Removing the condition can overwrite the newer edit that produced the 412.

Can If-Match protect a newly inserted event?

No. Google says conditional modification is not supported for insert operations. Creation needs its own identifier and retry contract.

Does an etag show whether an appointment was confirmed?

No. An etag identifies a Google resource version. Confirmation, cancellation, attendance, and booking ownership require separate business-state evidence.

References

• Google for Developers, “Get specific versions of resources,” reviewed August 16, 2026, https://developers.google.com/workspace/calendar/api/guides/version-resources.