In this day and age more and more information about logistics and traffic is shared over the Internet between various parties. To make this communication easier the Open Trip Model specification was created. It is a lightweight data model used to exchange real-time logistic trip data on the web, and to make it easier for shippers, carriers, software vendors, OEMs, and truck manufacturers to create new multi-brand applications and services.
To learn more about the what, the why and the how see the OTM documentation website.
Found any bugs on this page? Or have any feature requests for OTM? Create a new ticket on the OTM5 change requests Github page
Version 5.7 (released on 2025-05-23)
Version 5.6 (released on 2023-11-17)
owner as a new type of actor role. See 78.routeEntityConstraint and deprecate routeConstraint. See 80.Version 5.5 (released on 2023-02-07)
Consignment vs Goods constraints. See 42.fuel on vehicle an enum instead of a free string. See 51.emissionStandardConstraint as a possible constraint. See 52.transportOrder as a field on Consignment to enable the two-way relationship. See 59.eori as a possible contact detail option. See 60.valueBoundConstraint as a possible constraint. See 61.refuel as a possible action. See 62.accessConstraint as possible constraint. See 69.Version 5.4 (released on 2022-05-09)
TransportEquipmentConstraint. See 46.averageFuelConsumption to vehicle. See 48.contextEvents on entities. See 49.sequenceNr to all action types. See 50.cancelled on action results and receiverAbsent as 'reason' type. See 53.actors to all event types. See 55.description to all constraint types. See 56.Version 5.3 (released on 2021-12-16)
relatedConsignments in consignments. See 32.temperatureConstraint as a possible constraint type. See 37.Version 5.2 (released on 2021-09-09)
transportEquipmentSubType for example to indicate what type of pallets you use. See 19.timeWindowConstraint to replace startDateTimeConstraint and endDateTimeConstraint. See 6.operationalBase as a location type. See 22.Version 5.1 (released on 2021-06-01)
emission to Vehicle. See 13.transportMode to Trip and Move. See 12.grossWeight to Goods. See 11.mobilePhone as contact detail option. See 5.lastModified field to each entity. See 2.Version 5.0 (only documentation changes)
Stop action.TransportEquipment (i.e. a trailer).https://otm-api-spec.redocly.app/_mock/api/5.7/otm/api/v5/sensors/{UUID}
https://example.com/api/v5/sensors/{UUID}
curl -i -X GET \
'https://otm-api-spec.redocly.app/_mock/api/5.7/otm/api/v5/sensors/{UUID}' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'Returned the entity with the provided UUID
Uniquely identifies this entity. A URI can be assigned by the client to indicate where more information can be retrieved. Note that every entity always has a unique EntityId. However since, OTM5.2 it is not required to send it in the request. One can be generated for you by the server.
Name of the entity. For display purposes and search only.
The last modified date of this entity. If none is given the creation date is used instead.
The context events provides some optional information about the events that can provide additional information on the current state of this entity.
For example: your system might send ETA information for the arrival of a vehicle on a location. To make it clear what caused this ETA to be updated, we can include some information about what caused this ETA update by including an event as context. If your ETA update was caused by a location update, this event can be included as context. If the ETA was caused by a traffic accident on the route of the vehicle, you can include that event in the context.
Sometimes more than one sensor can be associated with a single entity. This is the case e.g. in cooled trailers that are divided into compartments with different temperatures, where each compartment has its own sensor. The placement member can be used to identify where a sensor is placed. Parties using OpenTripModel to exchange sensor data may wish to agree on a standardized naming, but this is too specific to describe in the standard.
The actors associated with this sensor, for instance the owners, the producers or the users of this sensor.
In the context of a Sensor, only sensorValueConstraints really make sense. You can use such a constraint to model a sensor of which the measured value must be within certain bounds at all times.
ℹ Note that constraints can be nested and combined using the
andConstraint,orConstraintandnotConstraint.
{ "id": "6666f00c-1332-472c-aff9-bc11b3d53296", "name": "Temperature sensor in trailer x", "placement": "Compartment 1", "sensorType": "accelerometer", "actors": [ { … } ] }
https://otm-api-spec.redocly.app/_mock/api/5.7/otm/api/v5/sensors/{UUID}
https://example.com/api/v5/sensors/{UUID}
curl -i -X DELETE \
'https://otm-api-spec.redocly.app/_mock/api/5.7/otm/api/v5/sensors/{UUID}' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'Uniquely identifies this entity. A URI can be assigned by the client to indicate where more information can be retrieved. Note that every entity always has a unique EntityId. However since, OTM5.2 it is not required to send it in the request. One can be generated for you by the server.
Name of the entity. For display purposes and search only.
The last modified date of this entity. If none is given the creation date is used instead.
The context events provides some optional information about the events that can provide additional information on the current state of this entity.
For example: your system might send ETA information for the arrival of a vehicle on a location. To make it clear what caused this ETA to be updated, we can include some information about what caused this ETA update by including an event as context. If your ETA update was caused by a location update, this event can be included as context. If the ETA was caused by a traffic accident on the route of the vehicle, you can include that event in the context.
Sometimes more than one sensor can be associated with a single entity. This is the case e.g. in cooled trailers that are divided into compartments with different temperatures, where each compartment has its own sensor. The placement member can be used to identify where a sensor is placed. Parties using OpenTripModel to exchange sensor data may wish to agree on a standardized naming, but this is too specific to describe in the standard.
The actors associated with this sensor, for instance the owners, the producers or the users of this sensor.
In the context of a Sensor, only sensorValueConstraints really make sense. You can use such a constraint to model a sensor of which the measured value must be within certain bounds at all times.
ℹ Note that constraints can be nested and combined using the
andConstraint,orConstraintandnotConstraint.
https://otm-api-spec.redocly.app/_mock/api/5.7/otm/api/v5/sensors
https://example.com/api/v5/sensors
curl -i -X PUT \
https://otm-api-spec.redocly.app/_mock/api/5.7/otm/api/v5/sensors \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"id": "6666f00c-1332-472c-aff9-bc11b3d53296",
"name": "Temperature sensor in trailer x",
"placement": "Compartment 1",
"sensorType": "accelerometer",
"actors": [
{
"entity": {
"id": "45db6ed0-28a7-4e4a-baba-3d5f8d171103",
"name": "Logistics manager",
"contactDetails": [
{
"value": "Simon Isaac",
"remark": "Wants to be called '\''Sim'\''.",
"type": "firstName"
},
{
"value": "Macan",
"type": "lastName"
},
{
"value": "+312012345678",
"remark": "private cellphone of the CEO",
"language": "nld",
"type": "phone"
},
{
"value": "simon@macan",
"type": "email"
},
{
"value": "NL74BANK5890469479",
"type": "iban"
},
{
"value": "NL000099998B57",
"type": "vatCode"
}
]
},
"associationType": "inline"
}
]
}'The same entity
Uniquely identifies this entity. A URI can be assigned by the client to indicate where more information can be retrieved. Note that every entity always has a unique EntityId. However since, OTM5.2 it is not required to send it in the request. One can be generated for you by the server.
Name of the entity. For display purposes and search only.
The last modified date of this entity. If none is given the creation date is used instead.
The context events provides some optional information about the events that can provide additional information on the current state of this entity.
For example: your system might send ETA information for the arrival of a vehicle on a location. To make it clear what caused this ETA to be updated, we can include some information about what caused this ETA update by including an event as context. If your ETA update was caused by a location update, this event can be included as context. If the ETA was caused by a traffic accident on the route of the vehicle, you can include that event in the context.
Sometimes more than one sensor can be associated with a single entity. This is the case e.g. in cooled trailers that are divided into compartments with different temperatures, where each compartment has its own sensor. The placement member can be used to identify where a sensor is placed. Parties using OpenTripModel to exchange sensor data may wish to agree on a standardized naming, but this is too specific to describe in the standard.
The actors associated with this sensor, for instance the owners, the producers or the users of this sensor.
In the context of a Sensor, only sensorValueConstraints really make sense. You can use such a constraint to model a sensor of which the measured value must be within certain bounds at all times.
ℹ Note that constraints can be nested and combined using the
andConstraint,orConstraintandnotConstraint.
{ "id": "6666f00c-1332-472c-aff9-bc11b3d53296", "name": "Temperature sensor in trailer x", "placement": "Compartment 1", "sensorType": "accelerometer", "actors": [ { … } ] }
An Actor models a legal entity. A legal entity is an individual, company, or organization that has legal rights and obligations. The use of Actors is optional, and is not necessary to use OpenTripModel. Actors can be used e.g. to group all locations that belong to an organisation, or to address an OpenTripModel message to a specific person or organisation.
Events - like actions - model dynamic entities that couple various static entities at a certain moment in time. Events are used for either real-time updates, or updates on earlier provided data. Notice that in both event types these are updates on earlier provided data, whereas actions are usually used together with the entities they dynamically couple.
There are various kinds of events that fall into the two earlier mentioned kinds.
Real-time updates:
Both real-time and projected/realized events
Updates on earlier provided data:
Actions are dynamic entities that are able to couple together various static entities at a certain moment in time. For instance a Load action couples together a Consignment and a Vehicle at the moment the Loading happens.
There are various types of Actions:
Goods are the items to be transported as part of a consignment. Goods can be divided into two sub-types of goods, depending on the use case and the level of detail. Goods either consists of items, describing the actual goods to be transported. Or a transport equipment, which is equipment used to carry the actual goods to be transported. Transport equipment is (usually) a means to an end, not something that needs to be transported on itself, such as pallets.
Note that goods can either be or contain dangerous goods. OTM uses the official specification of ADR to describe in what manner and how dangerous those goods are. The used descriptions in the OTM documentation are extracted from document ADR2021_Vol1e_0.pdf. The official documentation is always leading and should be consulted.
In many logistic operations documents are an important part of the data flow. Documents can serve multiple purposes, such as proving some package was delivered with help of a photo, or some scanned document that establishes that the transferred goods are accepted on handover. Documents in OTM come in two flavors, either you provide the content of the document directly as a base64 encoded string, or you provide a link to the document where it can be accessed online.
Constraints can do different things, depending on the context they're used in:
Location, access to the location is only allowed if the given constraint applies.Trip, constraints can be used to define constraints that have to be met during the trip, e.g. if the temperature in a refrigerated trailer has to stay below a given maximum during the trip.Shipment, constraints can be used to e.g. define minimum or maximum temperatures for shipments, or date time constraints for delivery.Since OTM5.2 the timeWindowConstraint is supported which allows you to give (optionally) both the start and end time of the window between which something needs to occur. This replaces the old style where you had to use an and constraint in combination with the startDateTimeConstraint and endDateTimeConstraint. Since the new solution is shorter and simpler the startDateTimeConstraint and endDateTimeConstraint are deprecated.
Note that constraints can be nested and combined using the andConstraint, orConstraint and notConstraint.