An integration needs to recognise a repeated attempt without mistaking a genuinely new request for a duplicate. That means keeping an identity for the customer and a separate identity for the action being performed.
If a transfer times out, clicking “send again” can be the wrong response. The other system may already have saved it.
One customer, two real requests
Imagine a fictional customer who books a service on Monday, then makes another booking on Friday. Both should be attached to the same customer, but Friday's booking must not overwrite Monday's.
Now imagine Monday's booking is delivered twice because the first reply never reaches the sending system. That is one intended booking with two delivery attempts. It should produce one result.
Ask your developer how those cases are distinguished. Customer name, email and date alone may not be enough. A stable booking or enquiry reference gives the connection something specific to follow.
Keep a record of the operation
A useful transfer record ties together:
- The source record and its business account.
- The action intended, such as creating a booking or adding a note.
- A reference reused for attempts at that same action.
- The destination record reference, once confirmed.
- Whether the result is waiting, confirmed, failed or uncertain.
The account matters. A booking reference that is unique within one branch may also exist in another branch. The integration must not confuse them.
Staff do not need to inspect technical logs to use this. They need a clear status and a safe next step when the outcome is unclear.
Ask what the provider supports
Some APIs accept an idempotency key, a reference that lets the receiving system recognise retries. Xero's idempotent requests guide documents its behaviour and a limited retention period. A key is not a permanent replacement for your own transfer history, and a changed request is not automatically the same operation.
Incoming notifications can also repeat. Shopify's delivery verification guide describes delivery identifiers for detecting duplicate webhook deliveries. Recognising the notification and preventing the resulting business action twice are related but separate responsibilities.
Test a lost reply
In an authorised test environment, ask for a demonstration where the destination saves the record but the sender does not receive a clear success response. Then retry the same operation through the intended recovery process.
Check the actual destination records. There should be one result for that intended action, with the sender able to identify it. Also submit a second, genuinely different booking for the same customer and make sure it remains separate.
Include an old retry, a changed payload and two simultaneous attempts. The provider's rules may require review or a fresh status check rather than another blind write.
If a duplicate already exists, pause the relevant transfer before correcting it. Merging or deleting business records can affect linked work. Decide which result is valid, retain an explanation and repair the matching rule that allowed the duplicate in the first place.