Reference · built on requestConnectorSensors, meters & gateways

Blues Notehub

Devices, events, sessions, fleets, and routes from Notehub, the cloud service Blues Notecard hardware syncs to.

Request accessPricing ↗

About

Notehub is the cloud service that Blues Notecard modules sync to over cellular, satellite, LoRa, or Wi-Fi. A project holds devices, fleets, environment variables, and routes. Each Note a device adds to a Notefile arrives as an event with its body, the time it was captured, and a tower, GPS, or triangulated location. The Notehub API at api.notefile.net reads all of it and can queue Notes and signals back to a device.

An operator on Fibric reads events and device health and proposes the Note, the signal, or the environment variable for your approval.

This is a reference listing. It documents what Fibric would read from Blues Notehub 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

  • Project devices through GET /v1/projects/{projectOrProductUID}/devices with last_activity, voltage, temperature, fleet_uids, tags, tower_location, gps_location, and dfu state
  • Events through GET /v1/projects/{projectOrProductUID}/events, filtered by device, fleet, Notefile, or captured or uploaded date, and paged by cursor from events-cursor
  • Event fields file, body, when, received, best_lat, best_lon, best_location_type, rssi, rsrp, rat, bars, voltage, and temp
  • The latest health log, session, and events per device through the /latest endpoint; health-log entries of type boot or dfu_completed
  • Sessions and journeys per device; journeys derive from events carrying journey and jcount, capped at the 100 most recent
  • Routes with their type and disabled flag, and route logs per route or per event through /events/{eventUID}/route-logs
  • Project, fleet, and device environment variables and the environment hierarchy that resolves them

Proposed actions

  • Target capability: propose queuing a Note to a .qi or .qis Notefile through POST .../devices/{deviceUID}/notes/{notefileID}, with a body or a payload up to 256 bytes
  • Target capability: propose a signal to a connected Notecard through POST .../devices/{deviceUID}/signal
  • Target capability: propose setting device or fleet environment variables through PUT .../environment_variables
  • Target capability: propose adding a device to fleets through PUT .../devices/{deviceUID}/fleets
  • Target capability: propose an http route through POST /v1/projects/{projectOrProductUID}/routes with fleets, a Notefile filter, and throttle_ms

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

What you can build

  • Watch a cold chain from the event body

    Filter events to the sensor Notefile and compare body.temperature with the limit for that fleet. When a reading crosses it, propose the alert and the Note that changes the sampling interval.

    With Cold Chain Excursion, Reefer Excursion

  • Find the device that stopped syncing

    Read last_activity and voltage for every project device and the boot entries in its health log. Propose the ticket for a device past its expected sync window, with its last tower location.

    With Sensor Health, Data Freshness

  • Prove where a shipment went

    Pull the device's journeys and the best_lat, best_lon, and best_location_type on each event. Attach the path to the delivery record for approval.

    With Delivery Proof, Route Deviation

Requirements

  • A Notehub project addressed by its ProjectUID or ProductUID; reads need the viewer project role, writes need developer
  • A personal access token with an expiration you set; it carries the same permissions as your Notehub account
  • Devices provisioned to the project, addressed by DeviceUID or by serial number with the sn: prefix
  • To move events out in volume, a route of a listed type such as http, mqtt, aws-sqs, or snowflake
Authentication
An Authorization: Bearer header carrying a personal access token created under API Access in Notehub; project-scoped OAuth client credentials from /oauth2/token still work but are no longer recommended and expire after 30 minutes.

Limits

  • 7 API requests per minute, up to 10,200 per day, per billing account without charge; beyond that, 429, and Enterprise plans raise the limit
  • The /latest endpoint refreshes at the end of each session, or every 15 minutes for devices in continuous mode
  • Get Device Journeys returns at most the 100 most recent journeys, with has_more set when the cap is hit
  • Without a route to your endpoint, Fibric polls the API, so the request limit sets the read cadence

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 Blues Notehub ↗

Questions and answers

How do events get from Notehub to Fibric?
Two ways. Poll GET /v1/projects/{projectOrProductUID}/events or events-cursor, which counts against the 7 requests a minute per billing account. Or create a route of type http that sends each event to a URL you set, filtered by fleet and Notefile, with throttle_ms and a timeout per request.
Can Fibric send data to a Notecard?
Yes, in two forms. A Note queued to a .qi or .qis Notefile is delivered on the device's next sync; the binary payload is limited to 256 bytes. A signal sent to a connected device is received with hub.signal. Each one is proposed for approval before it is sent.
What does the API rate limit allow?
7 requests per minute and up to 10,200 per day per billing account without charge. Exceeding it returns HTTP 429. Batch Jobs cover bulk operations, and Notehub Enterprise plans carry higher limits.
Ask about Blues Notehub

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 Blues Notehub 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