Choose one source for the current reservation

When the website, booking provider and staff spreadsheet all show a reservation, the important question is which one controls a change. Three visible copies can be useful. Three competing authorities can produce conflicting promises.

Assign ownership by field

A Costa Rican activity business might use a provider for confirmed capacity and an internal tool for pickup notes. That can work if the connection clearly separates the fields. Staff changing a pickup note should not accidentally restore an old reservation date.

Trace a late update

Use a fictional booking that changes while an integration is temporarily unavailable. When the connection resumes, decide how it identifies the newer information. A timestamp alone may be insufficient if different systems use different clocks or meanings of updated.

Make unresolved work visible

Staff need a clear way to see a failed update and investigate it. The message should identify the record and corrective action without exposing unnecessary customer information. Repeating every request indefinitely is not a recovery plan.

MDN's PATCH reference explains partial record changes, while the chosen provider's actual API controls the integration. Bring the record flow and a delayed-change example to a system-connection discussion before promising that everything will simply synchronize.