Reference · built on requestConnectorFleet & telematics

Trackunit

Construction equipment assets, operating hours, location, CAN faults, alerts, and site events from Trackunit Iris.

Request accessPricing ↗

About

Trackunit is a telematics platform for construction equipment. Its Iris APIs cover assets, machines, telematics devices, locations, CAN faults, alerts, sites, service management, operators, and emissions, with a GraphQL API, REST APIs, and an AEMP ISO 15143-3 feed for OEM data. IrisX adds webhooks, a data lake, and Automation Studio on top.

Through Fibric, an operator reads operating hours, fault codes, and site entries and exits, then proposes an alert configuration, an asset note, or a service assignment for your approval. Nothing changes in Trackunit Manager until you approve, and every approved change is recorded once.

This is a reference listing. It documents what Fibric would read from Trackunit and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Assets and their telematics devices through GET /v2/assets and POST /v2/assets/query at https://iris.trackunit.com/api/asset
  • Latest position per asset through GET /v1/locations and GET /v1/locations/{assetId} in the Locations API
  • Machine faults by SPN, FMI, and SA through POST /faults, POST /faults-summary, and the unit active faults endpoints in the CAN Faults API
  • Cumulative operating hours, idle hours, fuel used, fuel remaining ratio, DEF remaining, and fleet snapshots through the AEMP ISO 15143-3 endpoints
  • Alert configurations through GET /v1/configurations in the Alerts API
  • Webhook events for critical alerts (alerts.asset.on and alerts.asset.off), fault codes, service status, site entry and exit, and device health
  • Time series and data lake queries through the GraphQL API, metered in complexity points

Proposed actions

  • Target capability: propose a new or changed alert configuration through POST and PATCH /v1/configurations in the Alerts API
  • Target capability: propose an asset note or a hide/unhide change through PATCH /v2/assets/note and PATCH /v2/assets/hidden
  • Target capability: propose attaching or detaching a telematics device through /v2/assets/{assetId}/telematics-devices
  • Target capability: propose service plan assignments or a booking cancellation through the Service Management API

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Predict a failure from fault history

    CAN faults arrive with SPN, FMI, and source address, alongside cumulative operating hours. The operator ranks machines by repeat faults and hours since service and proposes a service assignment for a fleet manager to approve.

    With Predictive Maintenance

  • Cut idle time on rented machines

    AEMP idle hours and operating hours show which assets run without working. The operator proposes an alert configuration and a note on the asset for the site supervisor.

    With Idle Watch

  • Act on a critical alert

    An alerts.asset.on webhook names the asset and the alert. The operator checks active faults and location and proposes a stop-work note or a service booking, then closes the loop on alerts.asset.off.

    With Vehicle Fault

  • Refuel before a machine runs dry

    Fuel remaining ratio and fuel used in the preceding 24 hours come from the AEMP feed. The operator proposes a refuel visit for machines that will not last the shift.

    With Fuel Reserve

Requirements

  • A Trackunit Manager account and an API Key created in the API Keys application; each account can hold up to 10 active keys
  • Scopes on the API Key that cover the endpoints the operator will call; a token may request only a subset of them
  • An IrisX subscription for webhooks, which are only available to IrisX customers
  • For the AEMP ISO feed, the OEM ISO identifier of each machine
Authentication
An API Key from the API Keys application with a client_id and client_secret, exchanged at https://auth.trackunit.com/token/v2 with grant_type client_credentials for a Bearer token that lasts 20 minutes.

Limits

  • Access tokens expire after 20 minutes and there is no refresh token; re-request with the same credentials
  • A single GraphQL query is capped at 50000 complexity points, and the 10-minute budget depends on your subscription
  • AEMP ISO responses return at most 100 records per page and answer 429 when the request rate is exceeded
  • Webhook deliveries are retried 8 times, from immediately to 10 hours apart, then marked Failed for replay from Trackunit Manager

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Trackunit ↗

Questions and answers

How do I get an access token?
Create an API Key in the API Keys application, which gives a client_id and a client_secret shown once. POST them to https://auth.trackunit.com/token/v2 with grant_type client_credentials and the scopes you need. The response carries a Bearer access_token with expires_in of 1200 seconds.
Which events do webhooks send?
Critical alerts as alerts.asset.on and alerts.asset.off, fault code events matching what Trackunit Manager shows, service management status changes, site entry and exit, and device health events with open, resolved, or cleared states. Webhooks are available to IrisX customers and are signed per endpoint through Svix.
Is there a standard equipment feed?
Yes. The AEMP ISO API at https://iris.trackunit.com/public/api/aemp/v2 follows ISO 15143-3: a fleet snapshot per page, single-element snapshots, and time series such as CumulativeOperatingHours, CumulativeIdleHours, FuelRemainingRatio, DEFRemaining, Faults, and Locations by OEM ISO identifier.
Ask about Trackunit

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Trackunit through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy