₹200 of credit to start · pay by the hour, no plans

Connect a device, put it on a dashboard, and act on what it reports.

Pick a board from the device library, flash it from the browser, and watch its data arrive on a live dashboard. Switch outputs from the same dashboard, update firmware over the air, and get alerted when a value crosses a limit or a device goes offline. We run the MQTT broker, the durable pipeline, and the time-series database.

Start free Read the quick start

Ready-made firmware for ESP32 and ESP8266 boards, a guide for Raspberry Pi, and any MQTT 5 or 3.1.1 client: Linux gateways, Python, Node.js, Go, or mosquitto_pub.

shell

$ mosquitto_pub -h mqtt.iotaps.com -p 8883 \
    --capath /etc/ssl/certs -V mqttv5 -q 1 \
    -i "$DEVICE_ID" -u "$CREDENTIAL_ID" -P "$SECRET" \
    -t "v1/$ORG/$PROJECT/$DEVICE_ID/telemetry" \
    -m '{"schema_version":1,"message_id":"m-0001",
        "metrics":{"temperature_c":21.5}}'

# a moment later, from the API behind the dashboard
GET /api/v1/organizations/…/devices/…/latest
{
  "device_id": "01a10e7f-efd6-76fb-b2a7-3c41d0a95e12",
  "last_message_id": "m-0001",
  "message_count": 1,
  "metrics": {
    "temperature_c": {
      "value": 21.5,
      "received_at": "2026-10-05T10:15:30.412Z"
    }
  }
}

What happens to a message

Each step is a checkpoint with its own metric. A PUBACK tells your device the broker has the message; it does not yet mean the data is stored.

Broker-acknowledged

The broker checks the credential, the client ID, and the topic, then sends PUBACK for QoS 1.
Platform-accepted

Ingestion validates the envelope and fsyncs it to a durable stream before it acknowledges the broker delivery.
Persisted

One database transaction writes the event, latest state, and usage counters. A repeated message_id stops here.
Live

The committed event is pushed to open dashboards over Server-Sent Events. History stays the source of truth.

What is in it

Everything listed here works today. Things that do not exist yet are on the roadmap.

Device library: Templates for ESP32 and NodeMCU ESP8266 boards, Raspberry Pi, and generic MQTT clients, each with setup guides, a pinout, and a ready-made dashboard. The add-device wizard puts your Wi-Fi and credential into the sketch. Organizations can keep their own templates too.
Flash from the browser, update over the air: In Chrome or Edge, write the firmware over USB from the device page; the Wi-Fi and a new credential go to the board over the serial port, never to our servers. Later updates go over the air, checked by size and SHA-256.
Dashboards: 27 widget types: charts, gauges, value displays, tank and battery levels, a GPS map, a terminal, switches, sliders, buttons, colour pickers, numeric inputs and a joystick. Dashboards belong to the organization or to one project and can be shared to view or to control.
Commands to devices: Switches, sliders and buttons send commands over MQTT. The widget shows when the device reports the new value, and the last command is kept for a device that reconnects.
Datastreams: Declare a device's values once, as virtual pins V0–V255 or named keys, with a type, range, unit and choices. Widgets pick them up with the right options; values can be numbers, booleans or text.
Pins and modules: On the NodeMCU firmware, choose what sits on each pin from the console: relays, LEDs, buttons, PIR, DHT and DS18B20 sensors, and more. The board restarts with the setup and reports the I2C chips it finds. No code to write.
Alerts: Rules on a threshold, a device going offline, missing data, a widget's limits, or events such as a failed update. Notifications in the console, by email, as browser push, and to signed webhooks, Slack, Discord or Microsoft Teams.
Live presence: Online and offline within seconds, from the device's own status and the broker's last will, on every device list and page.
Durable ingestion: Messages are written to a durable stream before the broker delivery is acknowledged. Retries with the same message_id are stored once within seven days. A payload that breaks the contract is rejected with a reason code you can see on the device page.
History and aggregates: Raw points for ranges up to 24 hours; min, average, and max buckets up to 90 days. History is kept for 1 to 90 days, as each organization chooses.
Teams and project access: Organization roles, or access to selected projects and devices with a role per project: viewer, operator, developer, project admin, or a custom set. Teams, end dates on access, and an audit log of every change.
Secure sign-in: Email and password, Google, or GitHub, with a second factor on every account: a passkey or an authenticator app. Row-level security scopes every query to one organization.

Connect a device

One topic per device and a small, versioned JSON envelope. The console fills in the IDs when you create a credential; for ESP32 and ESP8266 boards the Essaar Arduino library handles the connection, commands and updates for you.

Full contract and limits · API reference

mosquitto_pub -h mqtt.iotaps.com -p 8883 --capath /etc/ssl/certs \
  -V mqttv5 -q 1 -i "$DEVICE_ID" -u "$CREDENTIAL_ID" -P "$SECRET" \
  -t "v1/$ORG_ID/$PROJECT_ID/$DEVICE_ID/telemetry" \
  -m '{"schema_version":1,"message_id":"m-0001",
       "metrics":{"temperature_c":21.5}}'

import json, uuid
import paho.mqtt.client as mqtt  # paho-mqtt 2.x

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=DEVICE_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(CREDENTIAL_ID, SECRET)
client.tls_set()  # system CA store
client.connect("mqtt.iotaps.com", 8883)
client.loop_start()

message = {"schema_version": 1, "message_id": str(uuid.uuid4()),
           "metrics": {"temperature_c": 21.5, "fan_on": True}}
client.publish(TOPIC, json.dumps(message), qos=1).wait_for_publish()

import mqtt from "mqtt";  // mqtt.js 5.x
import { randomUUID } from "node:crypto";

const client = mqtt.connect("mqtts://mqtt.iotaps.com:8883", {
  clientId: DEVICE_ID, username: CREDENTIAL_ID, password: SECRET,
  protocolVersion: 5,
});

client.on("connect", () => {
  const message = { schema_version: 1, message_id: randomUUID(),
                    metrics: { temperature_c: 21.5 } };
  client.publish(TOPIC, JSON.stringify(message), { qos: 1 },
                 () => client.end());
});

Limits and test results

Limits are part of the contract. The last two rows come from our own failure tests, not from a load test of your workload. Devices, messages, history and members are billed by the hour; see pricing.

Payload size: 64 KiB per message
Metrics per message: 64: numbers, booleans or texts
Deduplication window: 7 days, on device ID + message_id
History retention: 1 to 90 days, chosen per organization
Revocation: Live session closed in under 1 s after a credential is revoked
Restarts: No lost or duplicated messages across processor, database, and Redis restarts

Where it stands

What you can use today, what is being built, and what comes later.

Works today

Device library and add-device wizard
USB flashing and over-the-air updates
Dashboards with 27 widget types
Commands, datastreams, pins and modules
Alerts by email, push and webhooks
Project access, teams and custom roles
Hourly billing with Razorpay
White-label for Enterprise

Being built

Android app
CSV export
API keys for server-to-server access

Later

Fleet provisioning with claim codes
Client spaces for integrators
Device twins

Questions

Something else? Write to support@iotaps.com.

Is this a broker, a database, or a dashboard?

All of them, run as one service: a TLS MQTT broker with per-device access control, an ingestion pipeline, a time-series database, and on top of it a web console with the device library, dashboards, commands, alerts, and a REST API.

Do I have to write firmware?

Not for the boards in the device library. Flash the ready-made firmware from the browser, or open its sketch in the Arduino IDE or PlatformIO with your Wi-Fi and credential already filled in. On the NodeMCU you then choose sensors and relays per pin in the console. Any other device only needs an MQTT client and the JSON envelope.

How do I hear about problems?

Alert rules watch values, offline devices, missing data and firmware updates. Each rule notifies the members you pick in the console, by email and as browser push, and can post to webhooks, Slack, Discord or Microsoft Teams.

What happens to messages when something fails?

Accepted messages wait in a durable stream until they are committed. Processing resumes after an outage, redeliveries are deduplicated by message_id, and messages that can never be stored go to a dead-letter queue for review instead of being dropped.

How is our data kept apart from other customers?

The broker limits each credential to its own topic, the API checks your membership on every request, and row-level security in the database scopes every query to one organization.

Can we get our data out?

Yes. History, latest state, and recent messages are available through the REST API today. CSV export is being built.

What will it cost?

There are no plans: each organization pays by the hour for its devices, messages, stored history, members, projects, dashboards and alert rules, from credit it adds, and every new account starts with ₹200 of credit. Enterprise is a white-label platform on your own domains. See pricing.

Try it with your own devices

Every new account gets ₹200 of credit to start, no card needed.

Start free Sign in