A delivered webhook is evidence, not a receiving advice

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the integration engineer deciding what the tracking feed is allowed to claim.

One thesis: the parcel rails know that a package with a tracking number reached an address, and they do not know what was in it, who owns it, or who took custody — so the pipeline compiles a delivered webhook to corroborating evidence attached to the record, and refuses, as a design law, to mint a recadv reference or a receiving ObjectEvent from it.

What the aggregators are genuinely great at

Credit first, because the refusal only means something if the capability is stated fairly. EasyPost, Shippo, and ShipEngine are the cheapest event feed in our entire connector matrix: one REST integration, self-serve keys, test modes, HMAC-signed webhooks, and normalized status streams across dozens of carriers each. EasyPost's Tracker fires tracker.updated through to delivery with signed_by when the carrier captured one; Shippo's track_updated normalizes to statuses like DELIVERED with a mock carrier for testing; ShipEngine tracks to a status_code of DE. If the question is "where is this parcel, across forty carriers, without forty integrations," the aggregators are the right answer and this layer uses them exactly that way.

The identifier audit

Now the audit that decides what those feeds may claim, run against each aggregator's own documentation. The universal join keys are tracking_code/tracking_number plus carrier — and that is the whole list. No GTIN anywhere in the shipment surface. No GLN; addresses are structured text. No SSCC. The closest thing to product identity sits at the customs line: EasyPost's CustomsItem carries hs_tariff_number, Shippo's customs items carry hs_code and a sku_code, ShipEngine's customs products carry a harmonized code and sku. Tariff grain and SKU grain — export paperwork, not item identity.

Hold that against what a receiving claim requires. A recadv reference asserts a business document: these goods, against this despatch advice, accepted by this party. A receiving ObjectEvent asserts custody: this identified thing crossed this dock. The parcel feed has no what at either grain — no EPC, no GTIN, no lot — no who at any grain, and its where is an address string. Every load-bearing dimension of the claim is absent from the wire.

The two compiles, side by side

The wrong compile, shown so it can be refused explicitly:

{
  "type": "ObjectEvent",
  "action": "OBSERVE",
  "bizStep": "receiving",
  "quantityList": [ { "epcClass": "???", "quantity": 1 } ],
  "bizTransactionList": [
    { "type": "recadv", "bizTransaction": "urn:trk:usps:9400111899560000000000" }
  ]
}

Everything wrong is visible: an invented quantity against an unknowable class, a tracking number wearing a recadv costume, a custody assertion no one made. A downstream consumer cannot distinguish this fabrication from a real goods receipt — which is precisely the property a defensible record cannot afford.

The right compile attaches the same fact as what it is — evidence corroborating an expectation the paperwork already created:

{
  "evidence": {
    "kind": "parcel_delivery",
    "source": "easypost",
    "tracking": "9400111899560000000000",
    "carrier": "USPS",
    "status": "delivered",
    "signed_by": "R GARCIA",
    "at": "2026-07-29T18:41:00Z",
    "corroborates": {
      "bizTransaction": { "type": "desadv", "ref": "urn:epc:id:gdti:0614141.00001.F10442" }
    }
  }
}

The delivery joins the record through the one key both sides share — the tracking number the fulfillment wrote when the shipment was compiled — and it strengthens the desadv expectation without impersonating its close. When the reconcile verb runs, the evidence weighs in: an expectation with a delivered corroboration and no receiving event is a different verdict class than one with neither. The receiving event itself comes only from a surface entitled to assert it — a WMS receiving object, an ERP goods receipt, a scan at the dock.

Evidence-for versus record-of. It is the same law this layer applies to the 214 carrier status in the X12 dialect, and it is the line that keeps the record defensible: nothing on the spine asserts more than its source knew.

The exceptions worth knowing

Two carrier-direct facts from the matrix sharpen the picture rather than soften it. FedEx Ground accepts SSCC-18 ("00") barcodes on labels — an acceptance, which makes it a labeling opportunity for shippers who serialize logistic units, not a data feed; the SSCC still originates in your systems and the ASN rail. And UPS's Quantum View subscription carries manifest-grade inbound and outbound visibility — the closest thing to a native ASN analog in parcel — plus Track Alert webhooks. Richer evidence, better corroboration, account-gated onboarding; still evidence. The grain that would upgrade a parcel feed into a custody record — item identity, party identity, an attested receiver — never appears on the parcel wire, and almost nowhere else either.

The posture, generalized

A pipeline earns trust by what it refuses to fabricate. The aggregators are in the connector matrix because cheap corroboration at forty-carrier scale is genuinely valuable; they compile to evidence because that is what they carry. The executive consequence — exception views where a delivered parcel with no receiving close is a flag, not a silent assumption — is visibility.cloud's layer over the same record.

If your delivery telemetry runs through EasyPost, Shippo, ShipEngine, or a carrier direct, say which — the evidence intake is built per rail, in the order the answers arrive.

---

844 words. The access flow is at /get-access/; the family's event door is epcis.dev.