Prevent duplicate reservations when calls or requests repeat

Distinguish duplicate events from separate intentions

Two identical network messages can represent one intended booking. Two similar calls can represent separate guests or a deliberate second reservation. Your integration needs a stable request reference and a documented deduplication rule, not a broad instruction to merge anything that looks similar.

Ask how the rule is scoped: by venue, operation, request or time window. Confirm what happens after the retention window expires. A staff member retrying an old request should not unknowingly bypass the duplicate protection used by the original automated flow.

The unknown-response scenario

A booking system can accept a create request while the response is lost. From the phone service’s perspective the state is unknown. The safe recovery path is to look up the original request or reservation through the supported mechanism, then decide whether another write is needed.

Do not tell a caller there is definitely no booking merely because a screen timed out. Equally, do not promise a confirmed table without a verified accepted record. Define the wording and escalation path for this uncertainty with the restaurant.

Four replay tests

• Submit the same supported test request twice and inspect the resulting number of records.
• Interrupt the acknowledgement after acceptance and recover by reference.
• Replay a successful modification and verify it does not create another reservation.
• Repeat a completed cancellation and verify the booking stays cancelled.

Use the provider’s sanctioned testing approach. This reference is not an instruction to overload a public booking service or bypass its controls. A retry test should be bounded, coordinated and easy to identify as a test.

Keep the incident trail

Record the source event, original request reference, any returned reservation ID, timestamps and verified final state. If staff perform a manual correction, link it to the incident. The record should explain why the correction was necessary and what happened to any unintended duplicate.

A completed incident does not automatically mean the underlying duplicate-prevention problem is fixed. Re-run the failing fixture after a configuration change and keep the earlier failure in the review history. The workbench export can preserve an individual test run for that comparison.

One request, one final reservation

In a provider-approved test, submit a synthetic request, lose the acknowledgement and recover using the original reference. Count final reservations, not just success messages. A second legitimate booking for the same party is a separate intention and must not be merged merely because the details look similar.

The Loman OpenTable integration page establishes the stated booking category. Duplicate-prevention scope, retry windows and lookup behavior still need implementation-specific evidence. Keep that gap explicit in the test pack.