# The bill of lading went digital and brought an event model with it

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for the in-house supply-chain platform team — the platform engineer who can implement a spec without asking anyone.

One thesis: **ocean freight is the one transport mode whose digital rails
are open standards rather than vendor networks — DCSA publishes its
track-and-trace and eBL specifications as Apache-2.0 OpenAPI on GitHub —
and because UN/CEFACT's multimodal track-and-trace work explicitly adopted
the EPCIS event model, compiling those rails onto the record is a
standards bridge, not a vendor integration.**

## What DCSA standardized, and what it deliberately didn't

The Digital Container Shipping Association exists to do for container
carriers what nobody's commercial incentive would: publish one API shape
for the industry. The specifications live at `dcsaorg/DCSA-OpenAPI`,
Apache-2.0, with reference implementations under the same license — a
platform team can read, vendor, and implement them without a single
commercial conversation. Track & Trace v2.2 is the most adopted line;
v3.0-Beta restructures the event model and makes push subscriptions
optional rather than assumed.

What DCSA deliberately did not build is a hosted API. The standard is the
interface; the data comes from carriers implementing it. That census, from
our verified matrix: **Hapag-Lloyd** runs a self-service developer portal
(api-portal.hlag.com) on DCSA T&T 2.2; **Maersk** offers registration plus
a sandbox at developer.maersk.com; **CMA CGM** ships the DCSA T&T 2.2.0
specification verbatim; **MSC** gates access behind a request form. One
adapter against the standard, N carriers behind it — the implement-once
economics that only exist because the spec is open.

## The three event classes, placed honestly

DCSA T&T defines three event classes: **Shipment events** (document and
booking lifecycle), **Transport events** (the vessel's arrivals and
departures), and **Equipment events** (the container's gate-in, gate-out,
load, discharge). The identifiers are transport-grain and openly
specified: `equipmentReference` (ISO 6346 container numbers),
`carrierBookingReference` and `transportDocumentReference`, voyage
references, and UN/LOCODE-plus-facility codes for places.

Where does that sit relative to the record's custody grain? Exactly where
[carrier evidence always sits](/blog/delivered-webhook-is-evidence/) —
[the 214's lesson](/blog/the-214-is-not-an-event-record/), applied to
containers: an
equipment gate-out at a destination terminal is transport-grain evidence
corroborating a delivery expectation — it names a container, not the
goods, parties, or an attested receiver. The difference from the
parcel rails is that DCSA's events are *structured, open-vocabulary* evidence
with real identifiers, which makes the join mechanical: the container
number and transport document reference on the event match the same
references carried on the despatch-advice side of the record. Evidence
still, but evidence with a spec.

## The eBL, and the compile to `bol`

The second half of the DCSA portfolio is the electronic bill of lading:
the Issuance and Surrender APIs and the PINT interoperability standard
that lets eBLs move between platforms. The eBL is the canonical B/L
object — and CBV 2.0 §7.3
[already reserved its name](/blog/the-standard-already-named-your-paperwork/):
[`bol` is a core business-transaction type](/blog/biztransaction-is-a-core-field/),
defined in the same closed vocabulary as `po` and `desadv`. The compile is
one reference:

```json
{
  "type": "ObjectEvent",
  "action": "OBSERVE",
  "bizStep": "departing",
  "disposition": "in_transit",
  "quantityList": [
    { "epcClass": "urn:epc:class:lgtin:0614141.107346.LOT2026D", "quantity": 1200, "uom": "EA" }
  ],
  "bizTransactionList": [
    { "type": "bol", "bizTransaction": "urn:epc:id:gdti:0614141.00001.MBL773100" },
    { "type": "po", "bizTransaction": "urn:epc:id:gdti:0614141.00001.PO2210" }
  ]
}
```

The transport document reference that DCSA's events carry is the same
reference the `bol` entry names — so every subsequent equipment event
joins the record through an identifier both sides already agreed on.
Core CBV fields, validated against the pinned official EPCIS 2.0 JSON
schema on the way out: superset where the eBL carries more than the
standard models, and conformant always.

## The sentence UN/CEFACT wrote

The deepest fact in this post is one the freight world barely advertises.
UN/CEFACT's Business Requirements Specification for Integrated Track &
Trace in Multi-Modal Transportation (finalized September 2022) states its
lineage outright: **"UN/CEFACT adopted the model of EPCIS, originally
defined by GS1"** — including aggregation events as waypoints. And DCSA's
track-and-trace work is UN/CEFACT-aligned with a published data mapping.

Read the chain end to end: the container carriers' open standard aligns
to the UN's multimodal standard, and the UN's multimodal standard adopted
the event model this record speaks natively. Freight's open rails do not
need to be *translated into* the record's grammar; they were drafted
leaning on it. What remains is engineering, not ontology: DCSA does not
emit EPCIS documents itself, so the compile — reference joins, UN/LOCODE
to GLN bridging for facility identity via
[the resolution layer](https://barcoding.dev), evidence placement — is
the transaction layer's job, which is the job this site describes
end to end.

## Why this lands on a platform team's desk

Because it is the rare transport integration you can scope entirely from
public artifacts. The spec is on GitHub under Apache-2.0; two of the four
major carriers hand out keys self-serve; the event vocabulary is enumerable
before you write a line. Against the gated alternative — visibility
platforms whose APIs exist only inside an enterprise contract, and whose
record is authoritative only because you joined their network — the DCSA
lane is the one your team can implement, verify, and hold to a spec
without asking anyone. The record it feeds is verifiable without joining
anything, which is [the whole family's one sentence](https://epcis.dev/business-transactions-in-epcis/),
and the import story it unlocks —
[paperwork and custody on one spine](https://visibility.cloud/asn-po-context-in-traces) —
is where the executive conversation starts.

Ocean legs in your flows? [Tell us which carriers](/get-access/) — the
adapter's per-carrier gate table grows in the order the answers arrive.

---
Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt