OTM Gets an Official .NET Library on NuGet

On 1 July 2025, OpenTripModel.Model was published to NuGet. Shortly after, on 7 July, OpenTripModel.Serializer and OpenTripModel.Profile followed.

That sounds like an ordinary package release. It is not, because it is the first time you can use OTM in .NET without retyping the specification by hand.

What are we talking about — what is OTM? The Open Trip Model is an open standard for exchanging logistics trip data over the web: trips, consignments, transport orders, vehicles, locations, goods and the events around them, as lightweight JSON over a REST API.

The point of OTM is that shippers, carriers, software vendors and road authorities describe the same trip the same way. Without that agreement, every party builds a translation layer to every other party, and the whole sector pays for the same problem. Since 2018 the standard has been stewarded by the Stichting Uniforme Transport Code, together with TLN, evofenedex and DALTI.

A standard is only a standard once it is actually implemented the same way. And that was the gap.

OTM consisted of an OpenAPI specification and a documentation site — on version 5.7 since May 2025. If you wanted to integrate, you wrote your own types, your own serialisation, your own validation. Everyone did that, everyone did it slightly differently, and the differences only surfaced during the first integration test with a counterparty.

A shared library removes exactly that. Not because you cannot write types yourself, but because your types and your counterparty's then come from the same source.

The .NET toolkit is split into three independent packages, and the split is well chosen:

• OpenTripModel.Model — C# type definitions for the OTM v5 entities. Trip, Vehicle, Location, StopAction, associations, enums. Ready-made data structures that follow the specification's entity model one to one.
• OpenTripModel.Profile — validation of a message against a chosen profile: required fields, value constraints such as lengths, patterns and enums, and flagging unknown fields where those are not allowed. Returns pass/fail with reasons.
• OpenTripModel.Serializer — JSON serialisation following the OTM conventions: camelCase, enums as strings, predictable null handling.

The middle one is the most interesting. Profiles are how OTM lets a specific use case define what is mandatory — the transport order profile, the CBS profile for road transport statistics, the carbon footprint profile, the eFTI profile. The core specification leaves much open; the profile makes it concrete.

Which means 'valid OTM' without a profile is half a question. A library that ships profile validation therefore validates against the agreement that actually matters, rather than against the schema in general.

The design is deliberately boring, in the good sense. You build a Trip, attach a Vehicle and a list of actions through the same association types OTM uses in JSON, validate against your profile and serialise.

dotnet add package OpenTripModel.Model

And then just C# objects, with InlineAssociationType<T> for the inline associations OTM defines. No transport layer of its own, no client: you publish through the HTTP, file or messaging stack you already have. The library is about the model, not about how you send messages.

That is a good boundary. A library that also wants to own your transport is a library you cannot get rid of three years from now.

For completeness, because the dates overlap: the repository started on 24 April 2025, and by 27 May 2025 a first package was already on NuGet under the working name otm.model. It was later replaced by the OpenTripModel.* series that appeared on 1 and 7 July.

If you are looking for it: the publisher is FiLogic B.V., and the packages are named OpenTripModel.Model, OpenTripModel.Profile and OpenTripModel.Serializer in full.

The existence of an official library changes the business case for an OTM integration. Not dramatically — you save a few days of typing — but structurally, because you save those days again at every release of the standard, and you save the argument with your counterparty about whose interpretation is right.

The question you should ask yourself: how quickly does such a library follow the standard? A library that lags is worse than no library, because it makes you think you are current. We will come back to that in a later article — the version numbers of these packages later made a telling jump.

For Keana, our planning software for green city logistics, this kind of standardisation is the difference between plugging in and building on. The less of an integration is bespoke, the more time is left for the problem that actually matters: fewer trips through the city centre. See the Keana case.

On 1 July 2025 OpenTripModel.Model appeared on NuGet, followed by OpenTripModel.Serializer and OpenTripModel.Profile on 7 July 2025.

Three packages: model types for the OTM v5 entities, validation against an OTM profile with pass/fail and reasons, and serialisation following the OTM JSON conventions. No transport layer — you keep that yourself.

With it, OTM became something .NET teams install rather than something they retype.