Your Device Data, Where You Already Work
A network server that keeps your data is not much use. ioX-Bridge pushes every device event straight out as it happens, either to an endpoint you own over HTTP or to your broker over MQTT, in the same JSON either way. If you already have somewhere the data needs to be, that is where it goes.
It pushes rather than waits to be asked, which matters more than it sounds. Polling an API on a timer means either burning requests on nothing or finding out late, and it means building the scheduler that does it. Events arrive when they arrive, so the thing you are building can react instead of checking.
- Uplinks, joins, acknowledgements and location events, delivered as they happen
- HTTP to your own endpoint with your own headers, or MQTT over TLS to your broker
- The same JSON on both routes, so switching later is not a rewrite
- Configured per group of devices, so different customers or sites can go to different places
- Every delivery attempt logged with its endpoint, its status and how long it took
Trusted by teams monitoring critical infrastructure
The part vendors skip
What Happens When a Delivery Fails
Every integration fails sometimes. Your endpoint restarts, a certificate lapses, somebody ships a change on a Friday. The question worth asking a vendor is not whether that happens, it is whether you find out from them or from your customer.
ioX-Bridge logs every delivery attempt: which endpoint it went to, what status came back, and how long it took. Failures are tagged, and each entry opens into the full request so you can see exactly what was sent rather than reconstructing it. That log covers recent history rather than an archive, so treat it as the thing that tells you what broke, not as somewhere your data lives.
Two things worth knowing before you design around it. A paused integration stops delivering rather than holding events for later, so a pause leaves a gap on purpose. And a delivery that your endpoint rejects is not retried on a schedule, which means the receiving end should acknowledge quickly and do its work afterward rather than making us wait on it.
Live delivery log
One shape, every event
What Is Actually in a Message
Every event carries the same four things whichever route it took. If your system can read JSON, there is nothing to translate.
| What | Why you want it |
|---|---|
| Which device it came from | Identity and timestamps, so you can attribute a reading without a lookup. |
| The raw payload | The bytes as the device sent them. Keep them and you can re-decode history later if a decoder turns out to be wrong. |
| The decoded reading | Named values rather than bytes, from the profile assigned to that device. Temperature is called temperature. |
| Signal quality | Strength and noise from the radio, alongside the reading rather than inside it, so you can tell a failing sensor from a failing link. |
Event types cover uplinks, joins, acknowledgements, transmission acknowledgements, status, location and log entries, so you can react to a device coming online as easily as to a reading.
