Choose the source of truth
Decide which system owns each kind of record and which systems receive a copy. Map customer, product and order identifiers before moving fields. If both sides can change the same value, define conflict rules rather than letting the latest arrival silently overwrite the business record.
Handle an order webhook that arrives twice
A storefront sends an order to accounting, but the acknowledgement is lost. The same event arrives again. A stable external ID and a recorded processing result let the receiving system distinguish a retry from a new sale.
| Incoming event | Processing rule |
|---|---|
| New order ID | Validate required fields, create once and save the mapping |
| Known order ID, same version | Return the recorded result; do not create another invoice |
| Known order ID, newer correction | Apply an explicit adjustment rule and keep both versions in history |
{
"event_id": "evt_order_1042_v2",
"order_id": "order_1042",
"version": 2,
"type": "order.updated"
}Account for retries and delayed events
Connections can fail after an action succeeds but before confirmation returns. Use identifiers and processing history to avoid duplicate orders or entries. Consider events arriving out of order and decide how the integration determines the current state. A connector should expose failed items rather than silently dropping them.
Make reconciliation a normal operation
Give staff a way to compare important counts or amounts between systems and investigate mismatches. Agree retry, correction and escalation procedures with the operational owner. A pilot should include failures and historical imports, not only a single successful example created for a demonstration.
Before you proceed
- Document identifiers and ownership for each shared record.
- Test duplicate, late and failed events.
- Give exceptions a visible queue and a responsible person.
