OTM Java Toolkit Lands on Maven Central

On 9 July 2025, org.opentripmodel:otm-toolkit version 1.0.1.0 appeared on Maven Central. Eight days after the first official .NET package, and with exactly the same intent: implement OTM without retyping the specification by hand.

One line in your pom.xml, and the standard's entities are in your project.

First things first: what is OTM? The Open Trip Model is the open standard transport and logistics parties use to exchange trip data — trips, consignments, transport orders, vehicles, locations, goods, actions and events — as lightweight JSON over a REST API.

The reason it matters is organisational rather than technical. A shipper talks to several carriers, who in turn talk to several shippers, with a road authority, a customs system and a statistics bureau around them. Without a shared language, every one of those connections is bespoke. Since 2018 OTM has been stewarded by the Stichting Uniforme Transport Code together with TLN, evofenedex and DALTI, and every change is debated in public.

Where the .NET side chose three separate NuGet packages, Java ships a single artifact containing the same three-way split:

• otm.model.entities — the OTM v5 entities as Java classes. Trip, Consignment, Vehicle, Location, Actor, Constraint, Document, Event, and the accompanying enums such as ActionType, Enforceability, EmissionStandard and Fuel.
• otm.profile — validation against an OTM profile, with a ValidationResult containing individual ValidationMessages, each carrying a Severity and a ValidationCode. The first release includes a validator for the transport order profile.
• otm.serializer — JSON serialisation following the OTM conventions, including the camelCase treatment of enums that OTM uses.

Under the bonnet it runs on Jackson for serialisation and on networknt's json-schema-validator for profile validation. Apache 2.0 licence.

Validation is the part that saves the most time. Profiles are how OTM lets a concrete use case define what is mandatory: the transport order profile, the CBS profile for road transport statistics, the carbon footprint profile. The core specification deliberately leaves much open, so 'is this valid OTM' is half a question without a profile.

The artifact is built against Java 21. Both maven.compiler.source and -target are set to 21.

For a greenfield project that is no problem. For plenty of existing logistics systems it very much is. If your TMS or integration layer still runs on Java 11 or 17, you cannot simply add this library — upgrading your runtime becomes the first step, not the last.

It is the kind of detail that appears in no announcement and can move an integration plan by a quarter. Check it before you schedule it.

On 21 October 2025, version 1.0.2.0 appeared. Its main addition is validation against the CBS profile — the profile used to submit road transport statistics to the Dutch national statistics bureau.

That is a telling second release. Not more entities, not more fields, but a second profile. It confirms where the effort in an OTM integration really sits: not in the model, but in the question of what is mandatory in your specific exchange.

The two libraries are clearly built from the same design — the same three-way split of model, profile and serialiser, the same decision not to ship a transport layer. You publish using the HTTP, file or messaging stack you already have.

That last point is a good boundary. The library is about the data model and about whether your message is correct. How the message reaches your counterparty stays your choice, and that is exactly the layer where logistics varies most: one party does REST, the next SFTP, the third a message queue.

Where they differ is packaging. Three NuGet packages let a .NET project pull in only the model types if that is all it needs; the Java artifact is one whole. In practice that matters little, but it is the kind of difference you notice the moment you have to justify a dependency tree.

At Keana, our planning software for green city logistics, every integration with a shipper or carrier is time not spent on the actual problem: bundling transport orders into fewer trips through the city centre, with CO₂ savings you can evidence.

The more of that integration comes from the standard rather than from a per-customer agreement, the faster a new party can plug in. Official libraries in both major ecosystems are a step in the right direction. See the Keana case.

org.opentripmodel:otm-toolkit 1.0.1.0 appeared on Maven Central on 9 July 2025, followed by 1.0.2.0 on 21 October 2025.

One artifact with three parts: OTM v5 entities as Java classes, validation against an OTM profile with severity and error codes, and JSON serialisation following the OTM conventions. Jackson and networknt under the bonnet, Apache 2.0 licence. Version 1.0.2.0 added the CBS profile.

The footnote that matters most: the artifact is built against Java 21. Check your runtime before you schedule it.