Losant is an application enablement platform for connected products. Each application holds devices with up to 256 typed attributes (Number, String, GPS, Boolean, Blob) that report state over MQTT, REST, or a workflow. The REST API at api.losant.com serves the last state and the composite state per device, time-series and last-value queries across devices by id, tag, or query, events with a level and a state of new, acknowledged, or resolved, and data tables with row queries. Webhooks give an application fixed HTTP endpoints that trigger workflows; state and command streams arrive as Server Sent Events.
An operator on Fibric reads state and events and proposes the device command, the event update, or the table row for your approval.
This is a reference listing. It documents what Fibric would read from Losant 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
Last known state per device through GET /applications/{APPLICATION_ID}/devices/{DEVICE_ID}/state, with limit, start, end, and duration
The composite last complete state of a device through GET .../devices/{DEVICE_ID}/compositeState, narrowed by attributes
Time-series data across devices through POST /applications/{APPLICATION_ID}/data/time-series-query with start, end, resolution, aggregation, and attributes
The last value of one attribute across devices through POST .../data/last-value-query, selected by deviceIds, deviceTags, or deviceQuery
Events with level, state, subject, message, and deviceId, and the first new event ordered by severity
Data table rows through GET .../data-tables/{DATA_TABLE_ID}/rows and POST .../rows/query with $and, $or, and $nor conditions
Live state and command streams as Server Sent Events through .../devices/{DEVICE_ID}/stateStream and .../commandStream
Proposed actions
Target capability: propose a command through POST /applications/{APPLICATION_ID}/devices/{DEVICE_ID}/command
Target capability: propose creating an event, or updating matching events' state with the asynchronous PATCH
Target capability: propose adding rows through POST /applications/{APPLICATION_ID}/data-tables/{DATA_TABLE_ID}/rows
Target capability: propose a device data export through POST .../devices/{DEVICE_ID}/export with a callbackUrl
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Work the event queue
Read events in state new, ordered by level. Propose which to acknowledge and which need a person, then the PATCH that updates their state once you approve.
Compare each device's last state time with its expected interval, using the last-value query across a device tag. Propose the check with the composite state attached.
When a queried attribute crosses your threshold, propose the command payload for that device. You approve; the command goes out once and the outcome is written to a data table row.
A Losant application containing the devices, events, data tables, and webhooks in scope
An application API token whose scope covers the endpoints used; all.Application is the default scope
Content-Type and Accept headers set to application/json on every request
A webhook in the application with basic authentication filled in, if Losant workflows should push into Fibric
Authentication
A Bearer token in the Authorization header: an application API token created through POST /applications/{APPLICATION_ID}/tokens with a name, expirationDate, status, and scope list, shown once at creation.
Limits
Device state is accepted at 30 messages per 15 second window per device; each state payload is at most 256KB
Event creation is limited to 15 calls per 15 second window per application
Webhooks accept 100 calls per 10 second window and 100 concurrent connections per application, with a 256KB payload; a workflow reply must come within 60 seconds
Reported state may be dated no more than 30 days in the past or 24 hours in the future
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.
Two documented ways. Poll the state, time-series, last-value, and event endpoints on api.losant.com, or attach to a device's stateStream and commandStream over Server Sent Events. Losant webhooks point the other way: they are endpoints that trigger workflows, which Fibric can call.
What token does Fibric use?
An application API token, created through POST /applications/{APPLICATION_ID}/tokens with a name, expirationDate, status, and a scope list that defaults to all.Application. The token value is returned once at creation. A user token with all.User grants full account access and is broader than needed.
What are the rate limits?
Device state: 30 messages per 15 second window per device, 256KB each. Event creation: 15 calls per 15 second window per application. Webhooks: 100 calls per 10 second window and 100 concurrent connections per application. Multipart file uploads are capped at 10MB.
Ask about Losant
Ask about the capabilities and requirements in this listing.
This connector listing is developed, published, and supported by Fibric. It describes integration with Losant 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