Asset Tracking API: From Raw Pings to Real Decisions

An asset tracking API connects physical-world signals (GPS coordinates, RFID scans, Bluetooth beacons, sensor readings) to the software your team actually depends on. That sentence sounds straightforward. In practice, it hides about seven layers of architecture where most integrations quietly fail.

I’ve watched operations teams spend months wiring a tracker feed into a dashboard, only to realize the dashboard shows dots on a map while nobody can answer the one question that matters: “Where is that container right now, and what should we do about it?”

The asset tracking market is projected to reach $28.97 billion in 2026, growing at nearly 12% CAGR through 2034. The API layer is where that investment either produces measurable returns or becomes an expensive map with blinking dots. This guide covers what an asset tracking API actually does, how the architecture changes depending on whether you track shipments or reusable assets, where hidden costs accumulate, and what security gaps create real physical risk.

What an Asset Tracking API Actually Does (and Doesn’t)

An asset tracking API is a software interface that lets external applications read, write, or subscribe to information about physical assets: their location, status, custody, condition, or movement history. It sits between the sensing infrastructure (tags, trackers, readers) and the business systems that need to act on that data, whether that’s an ERP, a WMS, a CMMS, or a BI tool.

The definition matters because “asset tracking API” describes very different products depending on who built it and what problem they were solving:

• Custody APIs record who has an asset and when it changed hands. Snipe-IT’s checkout endpoint assigns a laptop to a user or location. No GPS involved.
• Position APIs deliver coordinates and timestamps. AWS Location Service ingests device positions and exposes them through batch read/write endpoints with geofencing capabilities.
• Event APIs standardize what happened to an asset across organizations. GS1’s EPCIS 2.0 uses REST and JSON-LD to exchange visibility events (shipped, received, inspected) in a shared business vocabulary.
• Telematics feeds stream vehicle statistics, locations, and diagnostics through cursor-based pagination and scoped bearer tokens.
• Indoor positioning APIs map assets to floors, rooms, and zones, delivering both historical data and live WebSocket/UDP streams.

The mistake is treating these as interchangeable. A custody API won’t tell you where an infusion pump is on a hospital floor. A GPS feed won’t tell you who checked out a calibration tool. And neither will automatically trigger the right action when an asset crosses a geofence or sits idle for 72 hours.

That gap between data delivery and operational action is exactly where most API integrations stall.

Shipment Tracking vs. Asset Tracking: The API Gap Most Teams Miss

This is the distinction I keep coming back to in every client conversation. Shipment tracking answers one question: “Where is this thing between point A and point B?” Once it arrives, the job is done. The API can stop reporting.

Asset tracking answers a fundamentally different question: “Where is this thing across its entire lifecycle?” That includes outbound transit, dwell time at the destination, return logistics, maintenance cycles, reuse, and eventual retirement. The API never stops reporting because the asset keeps moving.

When you’re managing a container pool, a fleet of ULD in aviation, or ground support equipment at an airport, the tracking need doesn’t end at delivery. It restarts. Your container sits at a customer site for 12 days when the agreed dwell time was 5. Your ULD disappears into another airline’s network. Your ground power unit hasn’t moved in three weeks, and nobody flagged it for maintenance.

These aren’t just business problems. They’re API architecture problems:

• A shipment API can use event-based reporting (departed, arrived, delivered) because the lifecycle is linear and finite.
• An asset API needs continuous or periodic position updates because the lifecycle is circular and indefinite. It also needs status transitions (in-use, idle, in-maintenance, in-transit, missing) that a shipment model doesn’t account for.
• Shipment APIs typically index by shipment ID or tracking number. Asset APIs must index by asset ID and maintain history across multiple trips, custodians, and locations.

CMA CGM’s DCSA Track & Trace API, for instance, delivers transport and equipment events through a GET /events endpoint. It handles shipment milestones well. But if you need to know that your reusable container has been sitting empty at a port for two weeks after delivery, you need asset-level visibility that most carrier APIs weren’t designed to provide.

If your container pool feels invisible after delivery, that’s the gap asset tracking closes.

The Full Stack: Sensor to Decision in Seven Layers

An API endpoint is the visible surface. Underneath it, seven layers determine whether the data you receive is fresh, accurate, complete, and actionable.

AWS’s reference architecture for tracking assets and locating devices illustrates this clearly: IoT sensors connect through AWS IoT Core, positions flow to Amazon Location Service, Lambda handles processing, S3 handles storage, and geofencing plus visualization happen on top. Each layer is a separate service with its own pricing, limits, and failure modes.

The layer that gets the least attention is usually layer 3 (connectivity) and layer 6 (storage). Most teams obsess over the API specification while ignoring what happens when a tracker enters a tunnel, a warehouse with poor cellular coverage, or an aircraft cargo hold over the Atlantic. If the device can’t store and forward, you lose data silently. If your retention window is 30 days and your asset cycle is 90, you’re missing two-thirds of the history.

The technology choice at layer 2 also determines more than you’d expect. Mid Cheshire Hospitals NHS Foundation Trust tracks 450 mobile devices with active tags providing continuous positioning, while 5,900 passive tags handle identification and audit. Active tracking solves “Where is this pump right now?” Passive tracking solves “Is this trolley accounted for?” Two different questions, two different sensing approaches, feeding two different API payloads.

Delivery Mechanisms: REST, Feeds, Webhooks, and Streams

Not all data should travel the same way. The mechanism you choose shapes latency, reliability, infrastructure cost, and complexity.

Geotab’s GetFeed mechanism is a well-documented example of incremental feed design. It provides a toVersion token as a checkpoint. You persist that token only after successfully processing the returned records. If your process crashes mid-batch and you’ve already saved the token, you skip records permanently. If you never save it, you reprocess everything. Neither is acceptable at scale without deliberate design.

A practical integration often combines mechanisms: REST for lookups, webhooks for events, and a nightly feed sync as a safety net. The mistake is picking one and assuming it covers every workflow.

The Cost Math Most Teams Discover Too Late

API pricing looks simple in a sandbox with 10 test devices. It gets complicated with a real fleet.

AWS bills position writes per position and reads per API request. Batch reads can retrieve up to 100 devices per request. A time-based filter stores at most one position per 30-second interval; distance-based filtering stores positions only after movement exceeding 30 meters.

Let me make this concrete. A fleet of 1,000 assets reporting once per minute generates 43.2 million position writes per month. Drop that to once every 10 minutes: 4.32 million. A 90% reduction in write volume that directly affects your bill, your storage, and your processing load.

But reporting frequency is not just a cost lever. It’s a freshness decision. Can your operations team tolerate 10-minute-old position data? For a container sitting at a depot, yes. For ground support equipment moving between aircraft gates, probably not. For an MRO tool needed on a work order right now, definitely not.

The costs most teams miss entirely:

• Cellular data roaming on a tracker that crosses three countries racks up charges that can dwarf the hardware cost per unit.
• Data normalization across different devices reporting in different units, formats, and intervals. Somebody builds and maintains that translation layer.
• Long-term storage when the platform retains data for 30 days but you need 12 months for cycle-time analysis. That’s a secondary data pipeline you now own.
• Integration maintenance as APIs evolve. Samsara explicitly labels its older Vehicle Locations endpoint as legacy and recommends migration to the Vehicle Stats API. Someone on your team owns that migration, every time it happens.

Budget for the total system. Not the API subscription line item.

When Connectivity Disappears: Offline and Edge

Most API documentation assumes the device has a network connection. In asset tracking, that assumption fails constantly. Containers on ocean vessels. Equipment in mining tunnels. Pallets inside metal-walled warehouses. ULD in aircraft cargo holds during flight.

This is where device firmware matters as much as the API. A tracker that can store and forward (buffer positions locally, then transmit in batch when connectivity returns) produces a complete history with gaps in timeliness. A tracker that drops data when offline produces a partial history with no gaps visible to the API consumer. The second scenario is worse because it looks clean.

Edge computing adds another option: process data locally before it reaches the cloud. A gateway at a warehouse dock can read RFID tags, resolve asset identities, compute dwell times, and push only aggregated events upstream. This reduces bandwidth, lowers cloud costs, and keeps the system functional when the WAN link goes down.

For aviation and maritime operations, where assets routinely enter connectivity blackouts, the store-and-forward capability of the physical tracker is a more important specification than the API’s real-time streaming feature. A device like the Thingfox T2 (DO-160 airfreight approved) is designed for exactly this environment: it needs to keep working when the network doesn’t.

When you’re evaluating an asset tracking API, ask the vendor what happens when the tracker goes dark for 48 hours. If the answer is “the API won’t show any data for that period,” you have a sensing and connectivity gap that no API design can compensate for.

Authorization Is Not Authentication: Security with Physical Consequences

In most software, a security vulnerability means leaked data. In asset tracking, it can mean someone remotely controls a physical device.

CISA’s advisory on the MiCODUS MV720 GPS tracker identified hard-coded authentication credentials and insecure direct object references. Successful exploitation could expose routes and real-time locations and enable fuel-cutoff commands or alarm disarming on vehicles. The vendor reportedly fixed the vulnerabilities, and no public exploits were confirmed. But the lesson stands: tracking APIs that also expose device commands need a fundamentally different security posture than read-only data feeds.

The OWASP API Security Top 10 lists Broken Object Level Authorization as the number one risk. Every endpoint that receives an object ID must verify the authenticated user has access to that specific object. A valid token is not enough. If your API returns data for asset ID 4827 to anyone who knows the number, you have an authorization problem, not an authentication one.

Practical checklist for asset tracking API security:

• Encrypted transport (TLS) on every connection, no exceptions
• Scoped credentials where a read-only token can never trigger write or command access
• Object-level authorization on every endpoint, every call
• Webhook signature verification (HMAC or equivalent) so you trust incoming event payloads
• Strict separation between read access and command execution
• Retention controls and audit logs: who accessed what, and when

The governance layer is equally real. The FTC’s January 2026 final order against GM/OnStar settled allegations of collecting and selling geolocation data without adequate consent, carrying a 20-year compliance obligation. Permission to collect tracking data and permission to share it are two separate controls. If your API feeds location data to partners, customers, or analytics vendors, make sure that permission architecture exists before the data starts flowing.

Real Deployments, Real Numbers

Theory is useful. Evidence is better. Four deployments that show what an asset tracking API integration produces when the layers above actually work together.

USPTO: 115,000 IT assets, $1.1M saved

The U.S. Patent and Trademark Office deployed RAIN RFID across more than 115,000 IT assets. Impinj reports nearly $1.1 million in savings, nearly 80% lower property-custodian labor, and a 99.9% reduction in asset loss since 2016. This is a custody and identification deployment: passive tags scanned by readers, feeding an asset register. No GPS. No real-time map. The value came from knowing what you have and who has it.

GE Aviation MRO: from 36 person-hours to 15 minutes

At GE Aviation’s maintenance, repair, and overhaul facility, 12 people spent three hours each manually prioritizing over 2,000 work orders daily. After RTLS deployment, that task dropped to 15 to 20 minutes per person. The vendor reports ROI in three months, a twelvefold productivity increase, and 15% higher capacity. The key design decision: the API connected location data to work-order status. Not to a standalone map screen. An API that feeds a workflow beats an API that feeds a dashboard.

SITA + Apple: 90% fewer truly lost bags with active location sharing

SITA’s 2026 Baggage IT Insights report found that truly lost bags carrying an AirTag decreased by 90% when passengers shared location through WorldTracer. Airlines using the integration saw 26% shorter delayed-bag recovery times, with 29 airlines now on the platform. The design point here: passengers control the sharing, links expire, and the consumer data feeds into an existing operational recovery workflow. This is permissioned data integration, not a universal enterprise API. Transfer issues still accounted for 39% of all mishandling in 2025, proving that location sharing doesn’t automatically fix broken handoff processes.

Hapag-Lloyd: trackers installed, API visibility still maturing

Hapag-Lloyd launched Live Position in May 2024 with tracking devices on more than two-thirds of its dry-container fleet. The company described API integration and ETA prediction as further milestones. The distinction matters: installing physical trackers, exposing customer visibility through a portal, and delivering machine-readable data through API endpoints are three separate deliverables with three separate timelines. When evaluating any vendor, ask which of those three you’re actually buying.

The pattern across all four: an asset tracking API creates value when it connects location or identification data to the specific action the organization needs to take. A feed without a workflow is a cost center.

What’s Shifting Right Now

Three developments are reshaping the asset tracking API landscape in 2026.

Ambient IoT at production scale. Wiliot’s October 2025 announcement described battery-free IoT Pixels deployed across 500 Walmart locations, with a target of 90 million Pixels by the end of 2026. Battery-free, Bluetooth-based sensing that feeds location, temperature, humidity, and dwell-time data into a cloud intelligence platform. If the target is met, it changes the economics of item-level tracking. The open question is whether reader infrastructure and integration costs create an acceptable cost per useful event. The target is not yet a confirmed deployment count.

Bluetooth Channel Sounding. Announced with Bluetooth Core 6.0 in September 2024, Channel Sounding enables phase-based fine ranging with sub-meter accuracy. It improves indoor positioning but does not replace building-wide RTLS deployment. Think of it as a new tool in the sensing layer, not a fix for the other six layers.

Privacy enforcement with real teeth. The GM/OnStar FTC order carries a 20-year compliance obligation and a 5-year prohibition on certain data disclosures to consumer reporting agencies. This is not abstract privacy discussion. It’s enforcement that makes consent architecture and data governance a product requirement from day one.

One more shift worth tracking: platform retirement is real. Microsoft retired Azure Maps Creator on September 30, 2025, with affected workloads and application data deleted. Long-lived physical assets need integrations built with data exportability and vendor replaceability baked in from the start.

The shared direction across all four trends: richer data from more sources, with correspondingly higher demands on architecture, governance, and integration resilience.

If you’re building asset tracking integrations for aviation, MRO, container logistics, or ground support operations, the gap between a raw location feed and a system that drives action is exactly where we spend our time. Take a look at our asset tracking devices, or reach out at info@datanetiot.com.

Frequently Asked Questions

What is an asset tracking API?

A software interface that lets external applications access data about physical assets: their location, custody, condition, or movement history. It connects the sensing layer (GPS trackers, RFID readers, BLE beacons) to business systems like ERP, WMS, or CMMS. The API delivers the data; it doesn’t create the location fix. That’s the hardware’s job.

Does an asset tracking API include the tracking hardware?

Rarely. The API is the software layer; hardware (tags, trackers, readers, gateways) is typically separate. AWS consumes device data through IoT Core. Traccar receives positions through device protocols. Evaluate device compatibility, battery life, connectivity options, and environmental certifications before committing to an API platform.

What’s the difference between REST, webhooks, and streaming for asset tracking?

REST handles on-demand queries and administrative lookups. Webhooks push event notifications (geofence entry, status change) to your system when something happens. Streaming (WebSocket or UDP) delivers continuous live positions for real-time dashboards. Most production deployments combine two or three mechanisms for different use cases within the same system.

How much does an asset tracking API cost at scale?

Beyond the subscription fee, budget for position write/read charges, cellular data and roaming, data normalization, long-term storage past the platform’s retention window, and ongoing integration maintenance. A fleet of 1,000 assets at one-minute reporting generates 43.2 million writes per month. Dropping to 10-minute intervals cuts that by 90%, but freshness requirements should drive that decision, not cost alone.

Can asset tracking APIs work in areas without connectivity?

The API is cloud-based and requires internet access. The critical variable is the tracker’s firmware: devices with store-and-forward capability buffer positions locally and transmit them when connectivity returns. Without that feature, data is silently lost during blackouts. Edge gateways can also process and buffer data locally, reducing dependence on continuous WAN connectivity.

What security risks are unique to asset tracking APIs?

Broken Object Level Authorization (OWASP’s top API risk) is especially dangerous here because asset tracking APIs can expose real-time physical locations and, in some implementations, enable device commands like fuel cutoff or alarm control. Use scoped tokens, verify object-level access on every call, validate webhook signatures, and strictly separate read permissions from command permissions.