One thesis: the GLN is the only identifier that natively appears at all three layers of a supply-chain record — the event, the transaction, and the e-invoicing network — which makes it the join key the whole stack gets for free, and its near-total absence from the commercial API middle is the single most expensive gap in the landscape.
The GTIN answers what. The GLN — Global Location Number, thirteen digits, same GS1 mod-10 check as a GTIN-13 — answers where and who: a legal entity, a function within one, a physical location, or a digital location. Resolve one:
$ barcoding resolve 0614141000005 --json
{ "scheme": "gs1.gln", "canonical": "0614141000005",
"check": "mod10 pass",
"sgln": "urn:epc:id:sgln:0614141.00000.0" }Arithmetic, worked: weight the first twelve digits alternately 1 and 3 left to right — 0+18+1+12+1+12+1+0+0+0+0+0 = 45; check digit (10 − 45 mod 10) mod 10 = 5. Valid. Pure, local, pinned tables — the registry page is /schemes/gln.
What earns the GLN this post is not its grammar. It is where it shows up.
One shipment, three appearances
Take one physical fact — a case shipped from a plant to a DC — and follow the same GLN through the three layers that record it.
Layer 1: the EPCIS event. CBV 2.0 §7.4 defines source/destination types for exactly this — owning_party and location — carried in the event's sourceList and destinationList:
"sourceList": [
{ "type": "owning_party", "source": "urn:epc:id:pgln:0614141.00001" },
{ "type": "location", "source": "urn:epc:id:sgln:0614141.00000.0" }
]Layer 2: the transaction. The ASN that announces the same shipment — an X12 856 — names its parties in N1 loops: ship-from and ship-to entities, with the identification-code qualifier UL declaring that the code which follows is a GS1 GLN. In original prose, an N1 loop for our ship-to reads: entity identifier ST, code qualifier UL, code 0614141000005. Same thirteen digits the event carried. (The segment layout itself is X12's licensed text — Stedi's open reference documents the 856 segment by segment; it is linked here, never reproduced.) The transaction layer is transactions.dev's beat in this family — the trace carries its paperwork.
Layer 3: the network address. In Peppol e-invoicing, the electronic address scheme 0088 is the GLN — the same identifier, now routing the invoice as an endpoint ID. The number that named the dock in the event and the ship-to in the ASN is the address the money document travels to.
One identifier, three wire formats, zero mapping tables. When the event's sourceList, the ASN's party loop, and the invoice endpoint all carry 0614141000005, the question did the paperwork, the shipment and the money all involve the same party? is a string comparison. That is what "the join the stack gets for free" means — and no other identifier in the record can do it.
The finding: the middle of the stack dropped it
Here is the verified state of the commercial API landscape, from a connector-by-connector survey of parcel, ecommerce, WMS, ERP and POS APIs (2026-07): almost nothing outside the GS1-native vertical SaaS and the standards rails carries GLN at all. The parcel APIs carry a tracking number and a carrier string — party identity is a free-text address. The major ecommerce platforms: free-text addresses, no GLN. No WMS in the surveyed set exposes GLN (or SSCC). Small-business accounting APIs carry no location identity beyond text. The exceptions prove the rule's shape: the big ERPs kept it — SAP holds business-partner GLNs, one mid-market ERP carries customer/vendor GLN fields in its base app — and the EDI/Peppol/GS1-XML standards rails are GLN-native end to end.
So the stack's edges — the standards below, the enterprise systems above — speak GLN, and the entire commercial integration middle went mute on it. Every integrator rediscovers this the same way: the trace says sgln:0614141.00000.0, the WMS says "Dock 4, 123 Industrial Pkwy", and joining them is your problem, per shipper, forever. That re-keying tax is the bridge burden, and it is permanent until party identity is carried, not inferred from address strings.
Grain discipline: the join key is not a stamp
One law keeps the GLN honest inside the family's record, and it is the same law the two-grains post applies to people and agents: events never stamp org identity. The GLN in a sourceList names a party role in that event — owning party, source location. Which organisation that is in your legal sense is derived at read time from grant chains, never written onto the event — because companies reorganize, sites change hands, and a record with a stale org stamped in is wrong forever, while a derived one is merely re-derived. The GLN is a join key. It is not an org chart.
resolve and verify on GLNs run today, local and free, like every pure verb on this site. The network half — party, which takes a GLN or company prefix and returns the licensee name and issuing MO where the data is licensed to say so — is keyed: the access flow asks which systems you join and which parties you need named, and provisioning follows the list in order.
The compressed version for your next integration review: the GTIN is the what, the GLN is the where and the who-in-the-org-grain sense — it already lives in the event standard, the ASN and the invoicing network — and any system in your stack that stores parties as address strings is discarding the only free join in the record.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.