Telematics portal & app

General Information
The External Push is used to export telematics data from the KRONE system so that it can be made available in other systems and contexts.
A release can be created under “External Releases.” Here, you can define the time period, the push package (the fields to be shared), the provider, and the vehicles to be included.
To create a provider, you need the endpoint (URI) to which the data is to be pushed, as well as any authentication credentials required to authenticate with the provider’s system.

Process and Logic
The service sends an HTTP POST request, as described in the /ok endpoint in externalpush.json, to the specified URI that was stored when the provider was created. No SSL handshake takes place for each packet sent. For authentication, the password is SHA-256 hashed and base64-encoded together with the username.
Packages that cannot be delivered are placed by the service in a backup queue to be pushed again at a later time. If there is no successful attempt to send a sharing data record within 3 days, the status of the entire sharing is changed from “RUNNING” to “ERROR,” thereby deactivating the sharing.
To ensure smooth operation, the responses from the customer’s system must conform to the response format defined in the technical documentation (Swagger documentation), as the KRONE system can only interpret responses that meet this format.

An uninterpretable response or no response at all is treated by the system as an error during data reception. The data packets are then moved to a backup queue and resent at the earliest opportunity. If this still fails after 3 days, the push is set to “STOPPED.” As soon as a push has the status “STOPPED”—whether due to a failed transmission or a manual stop initiated by the customer or on their behalf—data is no longer collected and, consequently, cannot be resent.

Miscellaneous (Developer/Provider)
The technical documentation below explains the structure of the data sent to the customer (RequestBody).
The `data` object in the RequestBody contains a customer ID (`externalCustomerIdentification`), which serves as an identifier for the sharing and can be used to uniquely identify the sharing. In addition, the RequestBody contains two free fields (specificFields) that can be populated with customer-specific IDs or other relevant information. However, these freely definable fields can only be defined at the global level—that is, for all vehicles. Definition at the vehicle level is not supported. Furthermore, the `data` object contains the vehicle data (boxdata).
The processing of the data and the analysis of the specific data packets are the responsibility of the recipient. We prepare the data records in advance so that they do not contain any empty fields. However, aside from a few required fields, the data records may differ from one another, as parameters without values are not pushed.

OpenAPI Spec/Swagger
The data specified in the Boxdata schema in the OpenAPI Spec contains only a small sample of the Boxdata fields, as the Boxdata fields sent will vary greatly in practice. It will never happen that all possible fields are filled in and sent. The example is intended to help you understand the design and structure of the data model.

With the new mykrone.blue platform, additional fields have been added to the vehicle data. These fields supplement the existing data set from the KRONE Telematics Portal.

New fields in the “vehicle” object

• VH_ILU_CODE: Vehicle’s ILU code (Intermodal Loading Unit)
• VH_LICENSE_PLATE: license plate number
• VH_EQN: Equipment number
• VH_VIN: Vehicle Identification Number (VIN)
• VH_FLEET_NUMBER: Fleet designation

Primary Identifier: VIN

KRONE recommends using VH_VIN as the primary identifier. The VIN is suitable for uniquely identifying vehicles, deduplicating data records, and linking data across systems. The other identifiers supplement the VIN as attributes but should not serve as the sole key, as license plates and fleet designations are subject to change.

Availability

The extended fields are only transmitted if the customer uses mykrone.blue. Customers who continue to use the KRONE Telematics Portal do not receive these fields.

Processing Guidelines

• Fields that are not transmitted are not empty; rather, they are missing from the data record. Processing should account for optional fields.
• Values should be processed as strings. Spaces in VH_ILU_CODE and VH_LICENSE_PLATE should be normalized before comparisons.
• Unknown fields should be ignored so that future enhancements do not disrupt processing.

If you have any questions about the data structure or about migrating from one portal to another, please contact your KRONE representative.