A vibration sensor on a pump, a temperature probe in a walk-in cooler, a runtime counter on a compressor — all of them produce a number over time. TeamWork turns that stream of numbers into maintenance work before something breaks.

What a reading unlocks

Every asset in TeamWork can carry one or more meters: a named quantity with a unit, a warning threshold, a critical threshold, and a direction (is high bad, or is low bad?). Once readings start flowing in, four things happen without anyone opening the app:

Condition status. Each meter shows ok, warning, or critical against its thresholds. Assets in trouble surface on the Maintenance dashboard.
Failure forecasting. TeamWork fits a trend across the reading history and projects when the value will cross your warning and critical lines — “critical in 34 days” — so a planner can act while the part is still in stock.
Meter-triggered preventive maintenance. A PM schedule can fire on accumulated units instead of a calendar date. Every 500 runtime hours, TeamWork generates the work order itself.
Compliance history. Every reading is retained and exportable, with the timestamp the sensor reported.

None of this requires a human to write a number on a clipboard.

How sensor data gets in

TeamWork exposes an authenticated endpoint that accepts a reading for a meter:

POST /api/v1/meters/{meter_id}/readings
Authorization: Bearer <your-api-key>
Content-Type: application/json

{ "value": 42.5, "recorded_at": "2026-07-09T14:00:00Z" }

That is the whole contract. Anything that can send an authenticated HTTP request can feed a TeamWork meter. In practice, that means one of three paths.

1. LoRaWAN sensors, via your network server

LoRaWAN devices do not talk to TeamWork directly — they transmit over radio to a gateway, which forwards to a LoRaWAN Network Server (LNS) that decodes the payload. The LNS is what integrates with TeamWork. Every major network server can send an outbound HTTP webhook when an uplink arrives, including:

The Things Stack (The Things Industries / TTN)
ChirpStack
Helium
Senet
AWS IoT Core for LoRaWAN, Actility ThingPark, and other platforms with HTTP integrations

Point that webhook at the readings endpoint for the meter you want to feed. Because each network server wraps the decoded value in its own envelope, you will typically add a short transform between the two — a Node-RED function node, a Zapier step, or a few lines in an existing integration layer — to pull the decoded field out and post it as value. Once configured, the sensor feeds the meter unattended.

2. IoT platforms and cloud-connected sensors

Sensor vendors that run their own cloud — Monnit, Disruptive Technologies, Samsara, SmartSense, and most industrial gateway vendors — all offer a webhook or HTTP-forward rule in their console. The same pattern applies: forward the reading, map the field to value.

3. On-premise gear, via a local bridge

Equipment that speaks Modbus, BACnet, or MQTT on a plant network usually sits behind Node-RED or Home Assistant already. A single HTTP-request node posts to the readings endpoint. The bridge runs on your network, holds your own credentials, and needs no inbound access to your equipment.

What TeamWork does and does not do

We want you to size this accurately before you buy.

TeamWork receives readings. It authenticates them with a scoped, revocable API key, rate-limits them, stores them against the right asset in the right tenant, and drives status, forecasting, and PM generation from them.

TeamWork does not run your sensor network. It does not decode LoRaWAN payloads, provision devices, manage join servers, or connect outward to a broker on your network. Your network server or IoT platform already does those jobs well, and it will keep doing them.

The practical consequence: if your sensors are already reaching a network server or a vendor cloud — which is true of essentially every deployed LoRaWAN fleet — connecting them to TeamWork is a webhook configuration and a field mapping, not a project.

Setting it up

In TeamWork, open the asset and add a meter: name, unit, warning and critical thresholds, and whether high or low readings mean trouble. Note the meter ID.
Under Settings → API, create an API key with the write scope.
In your network server or IoT platform, add an HTTP webhook pointing at POST /api/v1/meters/{meter_id}/readings with the Authorization: Bearer header.
Map the decoded sensor value to the value field. Send recorded_at as an ISO-8601 UTC timestamp if the sensor reports its own reading time; otherwise TeamWork stamps it on arrival.
Watch the first reading land on the meter, then set a meter-triggered PM schedule against it.

Condition monitoring is available on plans that include preventive maintenance. See the REST API documentation for the full endpoint reference, authentication, and rate limits.

See all TeamWork integrations or read more about preventive maintenance.

Start a free trial or connect your existing account.

Sensors & IoT: Feed Condition Data Into TeamWork Meters