OTM 5.8: A Vehicle May Finally Have More Than One Fuel

OTM 5.8 shipped on 13 March 2026. The date is stated explicitly in the documentation's changelog, and twelve change requests closed that day.

The common thread is notable: this is largely a clean-up release. Duplicate definitions removed, inconsistencies straightened out, and one substantive change that deprecates a field added with much enthusiasm four years earlier.

For newcomers: what is OTM? The Open Trip Model is the open standard for exchanging logistics trip data — trips, consignments, transport orders, vehicles, locations, goods, actions and events — as lightweight JSON over a REST API.

Why it matters: in transport everyone talks to everyone, and without a shared language every connection is bespoke. Since 2018 OTM has been stewarded by the Stichting Uniforme Transport Code together with TLN, evofenedex and DALTI. Every change is proposed and debated in the open, which means you can read back why each field exists — and, as this release shows, why it sometimes disappears again.

In OTM 5.4, May 2022, the vehicle gained the fields fuel and averageFuelConsumption. Singular, because a truck ran on diesel and that was that.

That no longer holds. A hybrid vehicle has multiple fuels, each with its own average consumption, and the draft Kernset Primaire Data specifies exactly that functionally.

So 5.8 replaces fuel, otherFuelType and averageFuelConsumption with a single field, fuels: a list in which each fuel carries its own average consumption. The old fields are deprecated, not removed — the usual approach in OTM, and the reason your integration does not fall over on release day.

Two additions in the same corner:

• emissionStandard gains the value Z. The Dutch vehicle authority uses emission classes 0 through 6 and Z, the latter mainly for electric vehicles. Without it you could not classify an electric truck correctly — precisely the vehicle for which low-emission zone access is most favourable.
• The carbon footprint profile updates its fuel list: diesel becomes fossile diesel (B0) and biodiesel (HVO) is added. If you calculate CO₂ per litre, that distinction is not semantics but a different answer.

The second substantive change concerns what goes wrong at the unloading bay.

Since 5.7 an action can succeed, fail, partially succeed or be cancelled, with a reason attached. But for a consignment with multiple goods — the classic case: a pallet of donuts and a pallet of sandwiches — 'partially succeeded' was all you could say. Which part went unsaid.

5.8 makes it possible to reference entities from a result and to specify sub-results. The overall result is then 'partially succeeded', and beneath it each good states whether it was unloaded or not.

That is the difference between a notification a planner has to chase and a notification a system can act on.

In 5.7 the actor was thoroughly reworked with the company and person types. As tends to happen with thorough reworks, sharp edges remained, and 5.8 files them off.

• roles was missing from the actor entity itself. The field did appear when you reached actors via a vehicle or location, but not in the actor's own definition. Confusing, and a well-known source of integrations that worked against one endpoint but not another.
• The difference between actors[].entity.role and actors[].roles is now explained explicitly instead of guessed at.
• The actor description differed per endpoint. Reading api/v5/actors/{uuid} gave you different fields than looking at the actors on a location.
• The circular polymorphic pattern between actor, person and company has been straightened out.

The rest of the release is the kind of work nobody claims but everybody notices:

• Duplicate definitions removed — the same entity or field was defined in several places in the specification, such as unit of measure.
• actions on the vehicle — you can now attach actions to a vehicle without the detour through a trip. For instance to record that a trailer is attached.
• actions on the consignment inside a transport order — a standalone consignment could have a list of actions, the same consignment inside a transport order could not. A gap in the specification, not a design choice.
• entityType was missing from the sub-types of goods — items and transportEquipment lacked the discriminator that tells them apart. For anyone generating from the OpenAPI specification, that was broken on contact.
• Volume on transport equipment and goods — not every customer has length, width and height to hand, but they often do have volume.
• CBS profile: Trip.vehicle was declared as an array in the JSON schema while the core specification expects a single vehicle. That broke validation for anyone using the official schema.

This release also changed how the documentation site is laid out. The separate 5.6 and 5.7 versions were removed and replaced by a single 5.x, on the reasoning that versioning minor releases separately serves no purpose.

And a changelog appeared. A small event with large practical value: until then, 'when did version X ship' was a question you could only answer by walking through change requests and commits.

One thing is worth noting, and it is exactly the risk that was foreseeable at the libraries’ version jump.

At the moment 5.8 appeared, the latest OTM .NET package sat at 5.7.1.1 — released in August 2025. The Java toolkit sat at 1.0.2.0 from October 2025, and therefore also speaks 5.7.

That is not a disaster: the deprecated fields keep working, so an integration on 5.7 keeps functioning against a counterparty on 5.8. But it does mean the new capabilities — fuels, sub-results per good, emissionStandard: Z — do not come out of the standard library on day one. Anyone who needs them writes that part themselves for now.

The lesson is the same as with any standard: your library's version number tells you what it speaks, not what the standard has since learned to do.

If you integrate on OTM today, three things belong on your list.

Check whether you do anything with fuel. fuel and averageFuelConsumption still work, but fuels is the shape new counterparties will send, and the only shape that describes a hybrid correctly.

Check whether you generate from the OpenAPI specification. The missing entityType in the goods sub-types and the Trip.vehicle schema in the CBS profile are exactly the kind of faults that quietly produce wrong types in generated code.

Revisit your exception handling. Sub-results per good are the first time you can see programmatically which part of a consignment did not arrive.

At Keana, our planning software for green city logistics, that last one touches rescheduling directly: a half-unloaded consignment calls for a different follow-up than a refused one. And fuels touches the core of what the product is judged on — demonstrable CO₂ reduction, per vehicle, per trip. See the Keana case.

OTM 5.8 shipped on 13 March 2026 with twelve change requests closed.

The core: fuel, otherFuelType and averageFuelConsumption on the vehicle are deprecated in favour of fuels, a list carrying a separate average consumption per fuel. emissionStandard gains the value Z. Action results can reference entities and carry sub-results per good. The actor is straightened out after the 5.7 rework. And a series of specification faults is fixed, including the missing entityType in the sub-types of goods and the Trip.vehicle schema in the CBS profile.

Alongside that, the documentation site moved to a single shared 5.x version instead of a page per minor — and, at last, gained a changelog.