IoT Engine speaks to Impinj, Zebra, Urovo and TLS hardware natively — fixed readers and handhelds alike — then hands your application one clean, normalized stream of tag data over a single cloud API.
One integration. Any reader. No vendor SDKs in your codebase.
Protocol translation, device management and data normalization — in one middleware layer.
Readers in. Normalized events out. Your software never touches a vendor protocol.
The problem
RFID hardware is not interchangeable. Each vendor ships its own SDK, its own protocol and its own quirks — and every one of them ends up hard-wired into your application.
Impinj speaks LLRP. Handhelds ship Android SDKs. Each one is a separate integration your team builds, tests and maintains.
Once a vendor is wired into your code, swapping hardware or adding a second brand means rewriting the integration.
A portal reader and a handheld gun produce different payloads for the same tag — so your app carries the logic to reconcile them.
Readers emit thousands of duplicate reads a minute. Turning that into "this pallet arrived" is work your team shouldn't own.
Warehouses and yards have dead zones. Without local buffering, reads that happen offline are reads you lose.
New site, new hardware mix, new custom development — and integration cost scales with every deployment.
What IoT Engine is
IoT Engine sits between the readers and your software. It handles the vendor protocols, the device fleet and the messy data — so your application only ever sees one clean interface.
Native support for Impinj, Zebra, Urovo and TLS readers — fixed and handheld — over each vendor's own protocol, so you don't have to learn any of them.
Every read becomes the same event shape regardless of which brand or form factor produced it. Deduplicated, filtered and timestamped before it reaches you.
Your software connects once — REST, webhooks or a live stream. No SDKs, no drivers, no reader-specific code in your stack.
Provision, configure, monitor and update every reader across every site from one place — whichever vendor made it.
Reads are buffered locally when the link drops and replayed in order once it returns. Nothing is lost in a dead zone.
Add a reader, a brand or a whole facility without touching the application you already shipped.
Hardware coverage
IoT Engine supports the major RFID vendors natively — across both fixed infrastructure and handheld devices. Mix brands and form factors freely; your software won't know the difference.
Speedway and R-series fixed readers and gateways over LLRP — portals, dock doors and conveyor lines.
FX-series fixed readers and RFD-series handheld sleds, unified under one event model.
Fixed readers alongside rugged Android handheld terminals — covering both the portal and the picker.
Bluetooth handheld readers for field, asset and inspection workflows away from fixed infrastructure.
Always-on portals, dock doors, conveyors and zone antennas — high-throughput read streams, filtered and deduplicated before they hit your API.
Guns, sleds and rugged terminals used on the move — session-aware, offline-tolerant and reporting into the same event stream as your fixed estate.
Connectivity
Whether the tag was read by a fixed Impinj portal or a TLS handheld two buildings away, your software receives the same event, in the same shape, through the same endpoint.
// The same payload — whichever reader produced it. { "event": "tag.observed", "epc": "E280 1160 6000 0208 1FBA 2C1D", "site": "dublin-dc-01", "zone": "dock-door-4", "reader": { "id": "rdr-8842", "vendor": "impinj", // or zebra | urovo | tls "type": "fixed" // or handheld }, "rssi": -52, "count": 1, // deduplicated for you "observed_at": "2026-07-17T09:14:02Z", "buffered": false // true if replayed from offline }
How it works
Point your Impinj, Zebra, Urovo or TLS devices at IoT Engine. No firmware forks, no custom drivers.
Fixed readers stream continuously; handhelds report as operators work — online or off.
Vendor payloads become one event schema — deduplicated, filtered, timestamped and enriched with site and zone.
Pull it over REST, receive it by webhook or subscribe to the stream. One integration, permanently.
Where it runs
The pattern is always the same: several reader brands, fixed and handheld side by side, and software that needs one clean source of truth.
Dock-door portals plus handheld cycle counts, feeding one live inventory picture into your WMS.
Backroom, floor and fitting-room reads unified — stock accuracy without a per-store integration.
Work-in-progress tracked across lines and cells, with handhelds covering what fixed readers can't reach.
Asset, consumable and instrument tracking across wards — auditable, and resilient to patchy coverage.
Questions
Impinj, Zebra, Urovo and TLS natively — covering both fixed readers and handheld devices. The connector layer is built to be extended, so if you run something else, ask us.
It sits between your readers and your business software. It translates each vendor's protocol, manages the device fleet, and turns raw tag reads into consistent events — so your application integrates once instead of once per reader brand.
Through one cloud API. Query REST endpoints, receive webhooks pushed to your WMS or ERP as events happen, or subscribe to a live stream. Every vendor and form factor produces the same event schema.
Yes. Reads are buffered locally when connectivity is lost and replayed in order once the link returns, so reads that happen in dead zones aren't lost.
Where we are
RFID estates don't sit in one country, and neither do we. Our teams in Ireland, India and the UAE cover deployments across Europe, the Middle East and Asia.
Get started
Tell us which readers you run and what your software needs. We'll show you the same tag event coming off every one of them.