Multimodal Tracking API: Architecture, Data Flow, and Integration Guide for Indian Logistics

A shipment leaves the factory by road, transfers to rail at the container depot, moves by coastal shipping to a port, and gets picked up by a truck for last-mile delivery. Each leg uses a different transport mode. Each mode has different tracking infrastructure. And your customer wants a single tracking page showing the shipment — not the vehicle.

This is the multimodal tracking problem. Most Indian logistics platforms solve it by stitching together manual updates, email notifications, and separate tracking systems per mode. The result: visibility gaps at every mode transfer, delayed exception detection, and customer experience that breaks at the exact moments it matters most.

A properly architected multimodal tracking API solves this by unifying signal sources, normalizing data into a single shipment-level view, and exposing it through a consistent API layer — regardless of which mode the shipment is on.

---

What Is a Multimodal Tracking API?

A multimodal tracking API is a unified interface that aggregates tracking data from multiple transport modes — road, rail, coastal shipping, air, and courier — into a single shipment-level view. Instead of querying separate systems per mode, a logistics platform calls one API endpoint and receives normalized tracking events, location data, and ETA predictions for the entire shipment journey.

Key difference: Vehicle tracking vs shipment tracking

---

Architecture: Signal Sources and Data Ingestion

Layer 1: Signal Sources

A multimodal tracking API for Indian logistics must integrate with these signal sources:

Road Transport:

GPS tracking — Fleet GPS devices provide location, speed, and heading at 30-60 second intervals

SIM-based tracking — Cellular tower triangulation for vehicles without GPS devices (critical for India's long-tail transporter network)

FASTag data — Toll crossing events from NHAI's electronic toll collection system, providing route confirmation and timing

VAHAN data — Vehicle registration database for ownership, fitness, and permit validation

Rail Transport:

FOIS (Freight Operations Information System) — Indian Railways' freight tracking system for rake movement and container train operations

Container train operator APIs — Concor, ICD-based operators providing container status updates

Port and Coastal Shipping:

Port community systems — Vessel arrival/departure, container gate-in/gate-out events

Shipping line APIs — Container tracking for coastal and international legs

Courier / Last Mile:

Courier API integrations — BlueDart, DTDC, Delhivery, India Post for last-mile tracking events

Layer 2: Data Normalization

Each signal source provides data in its own format, at its own frequency, with its own event taxonomy. The normalization layer transforms all incoming data into a unified event model:

Unified Event Schema: shipment_id, leg_id, mode (road/rail/sea/air/courier), event_type (departed/in_transit/arrived/delayed/delivered), location (lat, lng, place_name), timestamp, source, confidence score (0.0-1.0), metadata

This normalization is what allows the API to present a coherent timeline to the consuming platform, regardless of which mode the shipment is on.

Layer 3: Shipment-Level Aggregation

The aggregation layer maps vehicle/container events to shipment legs and constructs the shipment timeline:

Shipment creation — Platform creates shipment with origin, destination, and expected mode sequence (road to rail to sea to road)

Leg assignment — Each leg is assigned to a vehicle/container/rake with its tracking source

Event streaming — As normalized events arrive, they are mapped to the active leg

Mode transfer detection — When a leg completes (e.g., truck arrives at rail depot), the next leg activates (rail movement begins)

ETA propagation — ETA is recalculated at each event, factoring in the remaining legs and historical performance

---

Data Flow: How Events Move Through the API

Inbound Data Flow

Signal Source to Ingestion Gateway to Normalization to Event Store to Shipment Aggregator to API Layer to Consumer

Ingestion Gateway — Receives data via webhook push (GPS providers, courier APIs) or scheduled pull (FOIS, port systems). Rate-limited and authenticated per source.

Normalization — Transforms source-specific payloads into the unified event schema. Includes deduplication (FASTag may report the same toll crossing multiple times) and confidence scoring (SIM-based location is less precise than GPS).

Event Store — Time-series store of all normalized events, queryable by shipment_id, leg_id, or source.

Shipment Aggregator — Maintains the current state of each shipment: active leg, last known location, ETA, exceptions. Updated on every incoming event.

API Layer — Exposes the aggregated shipment state via REST endpoints and webhook callbacks.

Outbound Data Delivery

REST API (Pull):

GET /shipments/id — Full shipment timeline with all legs and events

GET /shipments/id/current — Current status, location, and ETA

GET /shipments?status=in_transit&mode=rail — Filtered shipment list

Webhooks (Push):

shipment.departed — Shipment has started a new leg

shipment.arrived — Shipment has arrived at an intermediate or final destination

shipment.delayed — ETA has slipped beyond threshold

shipment.delivered — Final delivery confirmed

shipment.exception — Halt, deviation, or mode transfer failure

---

Integration Guide: Connecting Your Platform

Step 1: Authentication

API keys are scoped per workspace. Rate limits: 100 requests/minute for standard tier, 500/minute for enterprise.

Step 2: Create a Shipment

Define shipment with origin, destination, expected delivery date, and leg sequence (road leg with vehicle + tracking source, rail leg with container + FOIS, road leg with vehicle + GPS).

Step 3: Subscribe to Webhook Events

Configure webhook URL and subscribe to event types: shipment.departed, shipment.arrived, shipment.delayed, shipment.delivered, shipment.exception.

Step 4: Query Shipment Status

GET /shipments/id/current returns: shipment_id, active_leg, mode, location, eta, status, events array.

Step 5: Handle Mode Transfers

When a road leg completes and the rail leg begins, the API fires a shipment.departed event with mode: rail. Your platform updates the tracking UI to reflect the new mode and expected timeline. No separate API call is needed — the API handles the transfer automatically based on the leg sequence defined at shipment creation.

---

Webhook vs Polling: Best Practices

Best practice: Use webhooks for event notifications and 5-minute polling for location breadcrumbs. Your platform must acknowledge webhooks within 5 seconds (HTTP 200) to prevent retry cascades.

---

Common Integration Challenges and Solutions

1. SIM-Based Tracking Confidence

SIM-based tracking provides cell tower triangulation, which is less precise than GPS (500m-2km radius vs 10-50m). The API returns a confidence score (0.0-1.0) for every location event. Your platform should display confidence-appropriately — high-confidence locations on a precise map, low-confidence as approximate zones.

2. Mode Transfer Gaps

When a truck arrives at a rail depot and the container transfers to a rake, there is a 2-6 hour window where neither road nor rail tracking is active. The API handles this by maintaining the last known event and firing a shipment.exception if the gap exceeds the configured threshold (default: 4 hours).

3. FASTag Data Latency

FASTag toll crossing events have 15-30 minute latency from NHAI. The API uses FASTag for route validation and timing confirmation, not real-time tracking. GPS/SIM remains the primary real-time signal for road legs.

4. Courier API Rate Limits

Courier APIs (Delhivery, BlueDart) have aggressive rate limits (10-30 requests/minute). The API caches courier tracking data and refreshes every 15-30 minutes, rather than on-demand. Your platform receives cached data via webhook when status changes.

---

Integration Timeline

---

---

Start Your Multimodal Tracking Integration

Intugines API Suite provides unified multimodal tracking across road, rail, port, and courier — with pre-built connectors for Indian logistics signal sources.

Get API Documentation + Postman Collection — Start Integration