Link a Sendcloud parcel to an online store order through a controlled identity hierarchy: workspace and provider account first, followed by a stable external order reference, then supporting characteristics. Never match solely on name, postcode or amount. With zero or multiple candidates, automatic processing stops because an incorrect tracking link is harder to fix than a missing one.
Why parcel identity becomes difficult
One order may have several parcels, a later delivery may exist as a linked order and different online stores may use the same visible order number. A carrier account can also contain shipments from several channels. The question is therefore not “which shipment looks similar?”, but “which local order and fulfilment step demonstrably created this parcel identity?”.
When creating a parcel, immediately record the relationship between workspace, online store order, provider account and external parcel ID. Retain that identity for later tracking webhooks. A webhook containing only a parcel ID then need not search broadly across customer data. This aligns with Connect as the integration layer: identity travels with the process step.
The identity hierarchy
- Workspace. Accept only the account and webhook configuration belonging to the active organisation.
- External parcel ID. First look up the previously stored exact parcel identity.
- Stable order reference. Use a reference retained by both sides while the parcel ID is still being recorded.
- Account and shop. Restrict every fallback to the correct sales channel.
- Supporting characteristics. Use a date or postcode only for confirmation, not as the primary key.
- Ambiguity. Stop, show candidates and let an authorised employee decide.
Also distinguish parcel, label and order. A reprinted label need not mean a new parcel; a later delivery may, however, create a second parcel for the same original customer request.
Fictional example: two parcels to one address
Fictional example: office supplier HelderWerk receives two orders from the same company on the same day, both for the same reception desk and with identical amounts. Matching by name, postcode, date and total would be arbitrary. When the parcels were created, however, order references HW-4401 and HW-4402 were stored along with two parcel IDs.
A tracking webhook for the second parcel finds exactly HW-4402 within the correct provider account. Only that order receives the tracking event. When an old parcel from a migrated account arrives without a known identity, the system applies no update and creates an investigation task. This fictional example shows that “many matching fields” still do not form a reliable primary key.
Acceptance test for parcel matching
| Test case | Expected outcome |
|---|---|
| Two orders, same customer and amount | Exact reference selects the right one |
| One order, two parcels | Both identities remain separate |
| The same order number in two stores | Separate account and workspace scope |
| Unknown parcel ID | No order update; investigate instead |
| Repeated webhook | Same event without a duplicate customer message |
Show in Desk parcel ID, order reference, current status and the origin of the link. Staff then need not guess based on customer names. For the full order and ERP journey, the integration checklist provides additional design questions.
Plan a separate migration route if parcels already exist in Sendcloud before the new integration starts. Do not automatically import every historical shipment. Choose a defined period, restrict it to the correct account and build a report showing exact matches, missing orders and ambiguities. Have a sample of automatic matches checked before releasing tracking events. Old parcels may refer to cancelled or recreated orders; that history needs different treatment from a new parcel created by the current workflow itself.
Also define what staff may do when there is a mismatch. Manual linking must retain both identities, the reason and the actor, and must stay within the same workspace. Unlinking must not silently erase earlier customer notifications. If a parcel is demonstrably linked incorrectly, first correct future events, then separately assess which tracking information already sent needs correction. Parcel identity remains reliable technically and for customer service.
Distinguish retrying from creating a new parcel too. A failed label request may turn out to be safely retrievable, while a genuine partial delivery deliberately needs an additional parcel. Have the interface show existing provider identities and parcel statuses first. For “new parcel”, ask for a reason and the associated order lines. This prevents a support employee creating a second shipment under time pressure when only the first needed retrieving again.
Want to track parcel and order identities throughout your fulfilment chain? Ask Yindle to prepare a matching and migration plan.