Publishing CRM Meetings to CalDAV With ETags and Receipts

Copying a meeting to a calendar is straightforward until the first timeout, destination change, or concurrent edit. Then the integration must answer a harder question: which object does it own, and which version has actually been confirmed?

The publisher work separates CRM meeting identity from the calendar object's location and observed server version. It also keeps synchronization authority explicit so two background writers do not independently maintain the same objects.

Track identity, location, and version separately

The integration needs several related values:

An ETag is an opaque concurrency token. It should not be reconstructed from a guessed content hash. The server's readback is the authority for the stored object's current ETag.

Make writes conditional

Creation can require that the destination object does not already exist. Updating or deleting an existing object should require the version the publisher actually observed.

Conceptually:

create: write only if absent
update: write only if observed version still matches
delete: remove only the owned, observed version

A rejected precondition is a conflict to investigate. Automatically retrying without the condition would remove the protection and could overwrite someone else's change.

The state also needs ownership checks. Finding an object with a familiar UID does not necessarily authorize taking it over.

Confirm after reading the stored object

The publisher uses receipts to connect an observed calendar result to the CRM's expected snapshot. Confirmation follows a fresh read of the object rather than being inferred immediately from a successful write response.

That matters when calendar storage normalizes serialization. Byte-for-byte source text and the semantic stored event are related but not interchangeable.

The integration work includes explicit fingerprinting and receipt validation. Historical receipts should retain their original meaning instead of being rewritten to match a newer interpretation.

A destination change is a migration

If an account changes its selected calendar, blindly using the new destination can duplicate every previously published meeting.

The dynamic path therefore tracks the destination generation and rejects stale confirmation or a silent destination switch when existing state still points elsewhere. Disconnecting and reconnecting to the same visible destination also needs a new generation to distinguish the configuration lifecycle.

This is still not an atomic transaction between the CRM and CalDAV. Rechecking a generation reduces races; it does not create a distributed lock spanning both services.

The local tests and isolated live paths provide evidence for particular operations, including no-op behavior and conditional changes. Complete recurring-event, invitation, multi-process, and production handoff acceptance remain separate work. A synchronization system becomes easier to trust when it names those limits as carefully as it names its IDs.