The connection timed out. Someone clicked again. The second receipt arrived, but nobody is sure whether the first request already changed the customer's record. That uncertainty belongs in the design, not in the incident channel.
Every integration needs three distinct identifiers kept side by side: the business request (what the customer asked for), its revision (which version of that request this is), and each delivery attempt (each time the message was sent). Two delivery events can carry one business intent. Without the distinction, a retry becomes a second change.
For example, consider a change request with two delivery attempts. One receiving record shows it applied. The other attempt's result is unknown. Sending the change again risks applying the same business effect twice. The correct move is narrower: inspect the destination system's evidence first, confirm whether the original intent took effect, and only then decide whether another effect is needed.
A later legitimate revision must be distinguishable from another delivery of the same request. Design the receiving service to recognize repeats, and document exactly how it handles them. Test a timeout in a permitted training setup before production teaches you the lesson.
Be careful with false comfort: adding a local identifier does not prove the provider deduplicates, and not every API supports the same mechanism. The unresolved state stays visible, with an escalation path, until the destination confirms.
Choose one integration this week. Ask what evidence would prevent the same business change from being applied twice, and where your team would look first.