Platform Documentation

Endpoints & Devices is where data from your hardware enters NEQTO.ai. An Endpoint holds the connection settings and credentials your hardware uses. A Device is one piece of equipment sending data. An Attribute is one measurement from that device, such as temperature, humidity, or battery. Stored device data can then be used in dashboards, alerts, analytics, and maps.

Data reaches NEQTO.ai in two ways. Most devices publish to a Device Endpoint, as shown above. A device can also be created from an Integration, which pulls in data from an external cloud service instead of receiving it from the device. Either way it becomes a Device with auto-mapped Attributes. Every device is labelled by its Source (Endpoint or Integration) so you can tell the two apart; see the Source column on the Devices list below.

Quick start

Use these steps to connect a device and confirm its first reading.

• 1
  Open an application and go to Device Endpoints. Click Add Device Endpoint and pick a connectivity type: MQTT, HTTPS, or WSS.
• 2
  Copy the credentials shown on the final step (Stream ID, host/URL, port, username, password, and the CA certificate). Use Download details to save them all, or copy each value with its own copy button.
• 3
  Open How to connect a device and use the recommended neqtoai-std example or another supported JSON shape. No hardware yet? Create a Demo endpoint and use the built-in Simulator instead.
• 4
  After NEQTO.ai processes the first valid message, the Device appears and mappable readings become Attributes. Open the device’s Device Data tab to confirm the stored values before using them in a dashboard or alert.

Device endpoints

An Endpoint holds one protocol and authentication configuration. Devices that publish through it are linked to it and appear in its details.

Connectivity types

You choose the type when you create the endpoint, and it cannot be changed afterward.

Each type also has an Authentication Type. For MQTT the choices are “MQTT with TLS (Recommended)” (a security token over a TLS connection) or “MQTT with no TLS” (username and password). For HTTPS and WSS the choices are “Basic Authentication” (username and password) or “None”. The older fully unencrypted HTTP and WS variants have been retired, so only the secure HTTPS and WSS types are offered.

Create an endpoint

Click Add Device Endpoint. You first choose how to set it up: Create Device Endpoint (a new one), Create Demo Device Endpoint (for the Simulator), Use an existing Device Endpoint (shown only when you already have one), or Create Aruba Device Endpoint (the HPE Aruba integration). Choosing Create Device Endpoint opens the form below.

• 1
  Enter a Device Endpoint Name (required, up to 100 characters). The name must be unique within the account. You can also add a description of up to 500 characters.
• 2
  Pick the connectivity type (MQTT, HTTPS, or WebSocket) and, where there is more than one option, its authentication type. The connectivity type is fixed once created. To change it, you create a new endpoint.
• 3
  If you have permission to manage applications, you can assign the endpoint to applications so the right teams can see it.

Endpoint access is permission-based. Viewing, creating, editing, and deleting endpoints are separate permissions at the account or application level, so an action may be hidden even when you can open the list.

Sending data: payload guidance

NEQTO.ai accepts flexible JSON payloads and provides neqtoai-std as the recommended, most predictable envelope. Every endpoint has a built-in How to connect a device helper that shows this example tailored to your endpoint’s protocol, with supported alternatives, a field reference, and troubleshooting tips.

MQTT topic options

For an MQTT endpoint, the topic shown in the endpoint details is the recommended NEQTO.ai topic. You can publish to that topic as before, or use one of the supported vendor-native topic shapes below. Use the same endpoint username and password or security token; you do not need to change the endpoint configuration.

Names in braces are placeholders: replace them with your values. For example, losant/{deviceId}/state could be losant/freezer-17/state. The trailing {...} shown for Azure means that an optional vendor suffix is accepted; do not publish the braces literally.

When a supported topic contains a device identifier, that value becomes the device’s External ID and takes precedence over device_id in the payload. Without a topic identifier, NEQTO.ai can use a stable top-level or nested payload identifier, or the endpoint’s only linked active device. Literal channel segments such as state, SENSOR, and up are case-sensitive.

MQTT topics may be at most 512 characters. A device identifier captured from a supported topic may be at most 128 characters. Control characters are rejected in topics and topic-derived identifiers; printable vendor punctuation and Unicode are accepted.

Third-party names identify compatible topic formats only and do not imply affiliation with or endorsement by those third parties.

Recommended payload example

This neqtoai-std JSON is the recommended starting point. Equivalent supported JSON shapes are accepted. Reading keys are your own sensor names and may be top-level or nested under any object wrapper; you do not need to encode units into the names.

{
  "payload_format": "neqtoai-std",
  "timestamp": 1716806400000,
  "device_id": "AA:BB:CC:AA:BB:02",
  "data": {
    "temperature":     { "value": 22.4, "unit": "c" },
    "humidity":        { "value": 62.3, "unit": "%" },
    "battery_percent": { "value": 82,   "unit": "%" },
    "rssi_dbm":        { "value": -55,  "unit": "dBm" }
  }
}

Envelope fields

At the top level, envelope field names match case-insensitively after underscores and hyphens are removed. Common device-ID aliases include device, mac, serial, sn, dev_eui, imei, and external_id. Timestamp aliases include ts, time, datetime, reported_at, and epoch. Wrapper names are not special; nested objects and arrays are inspected for readings and stable identifiers.

Reading fields

• Sensor reading: { "value": <number | string | boolean>, "unit": "<unit>" }.
• Unit: free-form text, up to 50 characters. Common units: °C, °F, %, hPa, V, A, W, dBm, m/s, kWh, lux, ppm. Use "state" for on/off or categorical values.
• Scalar / categorical: a plain string, number, or boolean, for example "status": "normal". NEQTO.ai attempts to classify it and infer a measurement unit or "state". If it cannot find a valid mapping, the message reports that no readings could be extracted.
• Naming: field names are your own labels. You do not need to put the unit in the name; NEQTO.ai classifies each reading automatically.
• Mixed: you can mix the reading and scalar forms in the same payload.

Multiple devices through one endpoint

One endpoint can carry many devices. Give each message a stable, unique device identifier in a supported MQTT topic or payload (for example, device_id, serial, or a strong nested identifier). Without an identifier, automatic fallback only applies when exactly one active device is linked to the endpoint.

A top-level JSON array can carry a batch of device objects. NEQTO.ai processes each array item as a separate reading, so each item should contain or inherit an unambiguous device identity and valid measurement fields.

Structured timestamp (neqtoai-std only)

With payload_format set to "neqtoai-std", you can use this object instead of an epoch timestamp. The offset uses the ±HHMM convention. Use valid calendar and offset values; unsupported values may be rejected or resolve to a different date than intended.

"timestamp": {
  "year": "2026", "month": "05", "day": "26",
  "hour": "14", "minute": "30", "second": "00",
  "offset": "+0900"
}

How to deliver it

Troubleshooting

Managing endpoints

Each row in the Device Endpoints table has an actions menu. Click the ⋮ (three-dot) icon in the Actions column on the right of the row to open it. This menu contains the actions your permissions allow, including Edit and, for demo endpoints, Simulator.

• Search the list by endpoint name.
• View Details re-opens the credentials summary and lists every device currently publishing to the endpoint.
• Simulator opens the built-in Simulator (shown only for demo endpoints, inside an application, and only when you have the Simulator view and execute permissions). See below.
• Edit changes only the name and description. Connection settings stay fixed.
• Delete disables the endpoint and its credentials, stops its demo simulator if applicable, and removes the endpoint’s device and application links. It does not delete the Device records. A device linked through another source can remain usable, but a device that relied on this endpoint stops receiving through it. Deleted endpoints cannot be restored in the UI; create a new endpoint and update the hardware with its new credentials.

Real-time ingestion feedback

While an endpoint’s details or one of its linked device pages is open, notifications in the top-right show how new messages move through ingestion. They let you confirm a new connection or see why a message failed without refreshing the page.

The stages

A payload that ingests cleanly reports these stages as it moves through processing:

Each stage announces itself once per visit. A device publishing every few seconds would otherwise fill the screen, so later messages do not repeat successful stages. Reopen the endpoint or device page to see a fresh set.

Message received. Deciphering the format. is specific to MQTT. Over HTTPS and WSS, feedback starts at Deciphering the message format, which means the same thing.

When a message is rejected

A rejected message produces a full-size error notification. Repeated failures with the same reason on the same endpoint are deduplicated, so a recurring problem does not produce a new notification for every message.

Devices

A Device represents one piece of equipment. NEQTO.ai can create it from the first identified payload, or you can create it manually to register hardware before it begins sending data.

The list view

• Connectivity shows next to each device name: green Wi-Fi when connected, red when not.
• Source shows how each device entered NEQTO.ai: an Endpoint badge for devices that publish to a Device Endpoint, or an Integration badge (with the integration’s name beside it) for devices pulled in from an external service through an Integration. This column is shown by default.
• Search by name, and filter by tag from either the toolbar Tags filter or the Tags column header.
• Switch between Enabled and Disabled devices with the toggle. Disabled devices are ones you have soft-deleted.
• Sort by most columns, including Last connected to surface quiet devices.
• Choose your columns with the Columns control. Several (External ID, Vendor, Model, Account, Notes, Profiles, and Systems in application scope) are hidden by default, and your choice is remembered per application.
• Profiles shows how each device’s data is parsed: EnOcean (with its EEP), BLE, or STD. This column is hidden by default.
• Dashboards opens Related dashboards for that device, listing every dashboard with a widget showing it and how many widgets on each. Check it before you change or remove a device. The same view is on the row’s actions menu. Device list and alert list widgets do not count as showing a device; the Dashboards page covers the rest.

Add a device manually

Select Create a Device above the Devices list if you have create permission. In the form, External ID, Device Name, Vendor, Model, and at least one Tag are required. You can also enter firmware, firmware version, gateway, notes, and an image, or use Scan QR Code to fill available details. Device names are limited to 100 characters, and External IDs to 255.

Device Edit page

Click a device row, or choose View Details or Edit from its actions menu, to open Device Edit. You can review the device on this page and, with edit permission, change its settings. It has these tabs:

How connectivity status is decided

The same tab lets you turn connectivity alerts on or off and choose in-app, email, SMS, and payload-push behavior. SMS requires a phone number on the recipient’s profile and SMS opt-in. These controls are read-only without device edit permission.

Connectivity changes update the Devices list and the device page while those screens are open; you do not need to refresh them.

Searching for a device

The device pickers on alerts, widgets and maps search as you type. An empty result and a search that could not run are two different things, and they say so. Search failed. Please Retry. means the lookup never completed, which is not evidence that the device is missing. Retry it before you conclude anything about the device.

Organizing devices

• Tags are key:value labels (for example floor:3 or site:warehouse-A) you can filter the whole list by. See the Tags section for managing them.
• Vendor and Model are device metadata you can show as columns and sort by; use Tags when you want to filter or group devices.
• Add to application from a device’s actions menu (on the main Devices list) to control which teams see it.

Disabling, restoring, and deleting

Disable is reversible; Permanently Delete is not. Disabling an active device moves it to the Disabled list and keeps its External ID reserved. Switch the list toggle to Disabled to find it. From there, choose Enable to restore it, or Permanently Delete to remove it and release its External ID. Permanent deletion is available only after the device is disabled.

Enabling a device rechecks the account’s device limit and whether the same device name is now in use on one of its linked endpoints. If either check fails, the device remains disabled until you resolve the conflict.

When an External ID is already in use

A device’s External ID is unique across your account, so creating a second device on an identifier that is already taken is refused. You meet this most often when creating a device from an integration’s sample, or through the API.

A disabled device can cause a less obvious collision. Disabling keeps the External ID reserved, but disabled devices are hidden from the default list. The error names the disabled device and gives both options: enable that device, or permanently delete it to release the identifier.

Attributes

An Attribute is one mapped measurement from a device, such as temperature, humidity, battery, or occupancy. Attributes supply the named values used by widgets, alerts, and analytics.

What you can edit

This screen does not change the detected JSON path or raw Attribute Name. To change how an Attribute is presented, open its actions menu and choose Edit:

• Display Name: a friendly label (required, up to 255 characters), for example rename t1 to “Supply air temp”.
• Units: the unit shown with the value (up to 50 characters), for example °C, %, or hPa.

The underlying Attribute Name is fixed and shown read-only on the edit form.

Display Name and Units are account-scoped: a change applies everywhere that attribute appears across your account, for every user (the raw unit sent in the payload stays as the fixed mapping key; only the display unit shown in the UI changes). Permission to edit Attributes can be granted at the application level as well as the account level.

Location fields do not turn the Maps feature into a geographic map. NEQTO.ai Maps use image overlays with manually placed pins; see the Maps documentation for setup.

Demo endpoints and the simulator

A Demo endpoint lets you generate data without hardware. Use its Simulator to test payload mapping, dashboards, alerts, and anomaly detection.

• 1
  Create a demo device endpoint from within an application (Device Endpoints, Add Device Endpoint, Create Demo Device Endpoint).
• 2
  Open the endpoint’s Simulator action. Select Start Gateway to connect its custom-device gateway to the endpoint.
• 3
  Select Add Device, choose a Device Template, enter a unique Device Name for this endpoint, and set Interval (s). A device added while the gateway is running starts immediately. If you add it while the gateway is stopped, Start Gateway starts it with the other devices.
• 4
  Confirm that the simulated device links to the main Devices list and that its Attributes appear. The status beside the device changes from waiting, to renaming, to linked when that process completes.

Many templates use time-of-day curves rather than uniform random values. Supported temperature and humidity fields rise and fall across the day, and the people-counter template produces more activity during business hours. Other fields use their template’s ranges and behavior rules.

• Device controls: start, pause, resume, stop, or delete each custom simulated device, and change its publish interval.
• Edit default ranges: change numeric minimums, maximums, units, and generation behavior, or change the allowed choices for text fields. You can reset fields to the template defaults.
• Quick Fill Presets: fill values for conditions such as a temperature spike, high humidity, open contact, current spike, or people-count burst, then send them on demand.
• Custom fields: add numeric or text fields. A field can be sent once or set to auto-publish on every device tick after it has a valid value.
• Send Raw Payload: validate, format, and send a specific JSON object through the demo endpoint. Replace the sample timestamp of 0 with a current valid timestamp, or remove it to use receive time; otherwise ingestion rejects it as too old.

The Simulator header shows the device cap and minimum interval enforced for your current plan. The current plan limits for custom devices are:

For a custom plan or if the displayed values differ, use the live cap and interval shown in the Simulator header.

Limits and operational details

These limits affect endpoint configuration, ingestion, and connectivity monitoring. Plan-specific device and payload allowances are shown in Billing; use the live values shown for your account.

• Keep device identity stable. Use a supported topic identifier or payload field such as device_id. If the chosen identifier changes, NEQTO.ai treats the hardware as a new device.
• neqtoai-std is recommended, not required. It selects the most predictable path directly; payloads without payload_format are detected and normalized automatically.
• Endpoint type is permanent. Decide MQTT, HTTPS, or WSS up front.
• Quiet devices look offline. Match each device’s connectivity timeout to how often it actually reports.
• Keep payload structures consistent. Reusing the same field paths and value forms lets later messages reuse existing Attribute mappings. A changed structure may require new fields to be classified.
• MQTT ingestion monitors for stalled broker delivery. If the worker remains connected but stops receiving messages, it restarts its broker session automatically. This requires no device configuration change. Delivery of messages sent during the interruption still depends on the device’s MQTT QoS and session settings.