Telematics data integration with HTTP Push in IoT Logic

Across industries, telematics applications often need more context than vehicle and device data alone can provide. Say, combine mileage with the last service records from a maintenance system. There are several ways to bring such data together, and the choice affects how much code, infrastructure, and ongoing maintenance the integration requires.

HTTP Push enrichment, recently added to Navixy IoT Logic, provides a direct way to bring external data into telematics processing. Let's take a closer look at how it works, what you can build with it, and what changes on the integration side.

So, what is HTTP Push enrichment?

HTTP Push enrichment allows an external system to send data directly to Navixy IoT Logic, a low-code environment for processing and transforming telematics data from IoT devices and OEM systems.

The external system sends an HTTP request with its data. A configured mapping associates the incoming data with the corresponding tracker and makes the attributes available for processing in IoT Logic.

Tracker telemetry and external data arrive independently.

Let's say a tracker reports:

hardware_mileage = 197450

while a fleet maintenance system sends the mileage recorded at the last service:

{
  "vehicle_ref": "VEH-318",
  "odometer_at_service": 182300
}

Both values are now available in IoT Logic. A flow can calculate that the vehicle has traveled 15,150 kilometers since the recorded service and use the result in further processing.

The maintenance system doesn't become another telemetry source. It provides the information it owns, while the tracker continues to report vehicle data independently.

What external data adds to a telematics flow

Bringing an external value into IoT Logic is useful when that value can change what the flow calculates, decides, or does. Two scenarios show this particularly well.

For a broader look at the business applications behind this approach, see our article on vehicle data enrichment.

Build conditions from two data sources

Some operational rules need both telemetry and information that exists elsewhere.

Let's say a tracker reports that a refrigerated vehicle has entered a depot geofence, while an external system provides:

inspection_required = true

IoT Logic can evaluate both and use the result to trigger the next step in the workflow.

The same pattern can combine location, movement, mileage, sensor readings, or other telemetry with permissions, assignments, maintenance information, operational statuses, and other external attributes.

The external application provides the context it owns. IoT Logic applies that context together with tracker data, so neither system has to contain the complete operational rule.

Trigger a telematics-side action from another system

External data can also initiate a workflow in the other direction.

An application may know that something needs to happen to a vehicle but have no direct communication channel to its tracker. For example, another system could send:

immobilization_requested = true

The request can enter IoT Logic through HTTP Push. The flow can evaluate any additional conditions and, where the configured flow and tracker capabilities allow it, initiate the corresponding device action.

The external application doesn't have to implement the device communication layer itself. It provides the business-level request, while Navixy handles communication on the telematics side.

For solution builders, that creates a useful boundary. A customer-facing application can participate in device-related workflows without also having to implement tracker protocols and command delivery.

Mapping external identifiers to trackers

The source system doesn't have to identify an asset the same way Navixy does. A fleet maintenance system, for example, may already use its own vehicle references:

VEH-318
VEH-319
VEH-320

When configuring HTTP Push enrichment, a suitable parameter from the incoming data can be used as the primary key for mapping those values to trackers:

VEH-318 → tracker 12345
VEH-319 → tracker 12346
VEH-320 → tracker 12347

The maintenance system can therefore continue sending a payload based on its own identifier:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic uses the configured mapping for vehicle_ref to associate the incoming data with the corresponding tracker. This keeps identifier translation at the integration boundary instead of requiring the source application to adopt tracker IDs or another Navixy-specific identifier.

From integration infrastructure to business logic

Before HTTP Push enrichment, external business data could not be brought directly into IoT Logic this way. Doing so could require an integration component between the external application and telematics processing.

Even a relatively simple service may need to receive a payload, identify the asset, prepare the data, and pass it on. The code is only part of the work. The service also has to be deployed, hosted, secured, monitored, updated, troubleshot, documented, and maintained.

HTTP Push moves that part of the integration into IoT Logic. The external system sends the data, configured mappings associate it with trackers, and the flow defines what happens next.

For a solution where a custom component would mainly exist to receive external data and connect it with telematics processing, this can remove an infrastructure component entirely. For a TSP or integrator deploying similar solutions for multiple customers, that also means one less service to deploy and maintain for each implementation.

It doesn't remove integration engineering. Identifier strategy, mappings, attribute schemas, credentials, testing, and lifecycle management still matter. What changes is where much of that work happens: in configuration and business logic rather than in another software service and its supporting infrastructure.

HTTP Push and other Navixy integration mechanisms

HTTP Push, Navixy Generic Protocol, and the Navixy API have different roles.

Mechanism	Role
HTTP Push enrichment	Bring external attributes into IoT Logic and associate them with an existing tracker for processing alongside its telemetry
Navixy Generic Protocol	Connect a source that acts as a telematics source in its own right and supplies its own telemetry
Navixy API	Create, read, update, and delete supported Navixy entities and configuration

The HTTP Push versus NGP distinction is particularly important.

With NGP, the connected system is the telemetry source. With HTTP Push, tracker telemetry already arrives independently, while another system contributes additional information related to that tracker.

This distinction also sets a technical boundary. Core positioning attributes such as coordinates, speed, heading, satellite count, and HDOP cannot be overwritten through HTTP Push enrichment. If another system is the actual source of those measurements, it should be connected as a telemetry source rather than treated as enrichment.

The Navixy API serves another purpose. It provides programmatic CRUD operations for supported platform entities and configuration rather than an alternative input for processing arbitrary external data in an IoT Logic flow.

Custom integration code may still be required in exceptional cases where the available platform mechanisms cannot cover the integration requirements. It shouldn't, however, be necessary simply because a third-party system has data that needs to participate in IoT Logic processing.

Configuration still needs engineering

Moving the transport and mapping layer into configuration doesn't remove the integration contract.

Take a mapping such as:

VEH-318 → tracker 12345

If the tracker is replaced or the external identifier changes, the mapping has to change with it. Stable identifiers therefore become increasingly important as the deployment grows.

Attribute names and types need the same discipline. Names such as:

maintenance_due
maintenance_work_order
odometer_at_service

are easier to maintain than generic status, id, or value fields. And if a flow expects:

{
  "maintenance_due": true
}

changing the value to "yes" changes the contract for the logic consuming it.

HTTP Push uses an API key, so the sending application also needs to protect that credential as an integration secret.

During commissioning, Data Stream Analyzer can help verify that the expected identifier, mapping, attributes, and downstream processing reach the flow correctly.

For larger deployments, mapping lifecycle, failure handling, request limits, credential management, and monitoring should be addressed before rollout. Where current documentation doesn't specify a particular limit or behavior, verify it for the deployment rather than designing around an assumption.

Setting up HTTP Push enrichment

HTTP Push enrichment is configured in the Data Source node in IoT Logic.

Select the trackers that should receive the external data and configure HTTP Push as the software data source. After the flow is saved, IoT Logic provides the HTTP Push URL used by the external application. Requests are authenticated with an API key.

Next, choose the incoming parameter to use as the primary key and configure its mappings to the corresponding trackers:

VEH-318 → tracker 12345
VEH-319 → tracker 12346
VEH-320 → tracker 12347

The external application can then send:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic resolves VEH-318 through the configured mapping and makes the pushed attributes available for processing alongside data arriving independently from the tracker.

For the exact configuration fields and current HTTP Push requirements, refer to the HTTP Push enrichment documentation.

External context becomes part of telematics logic

HTTP Push gives external business data a direct input into IoT Logic. That data can participate in conditions with tracker telemetry or initiate workflows that continue on the telematics side.

For integrators and solution builders, this can also remove infrastructure whose only job would have been to get those external attributes into telematics processing. The engineering effort stays focused on the mappings, conditions, and actions that make the combined data useful.

Have a scenario that combines external data with telematics? Contact our team to discuss how to build it with IoT Logic.