Connecting IoT devices to Bubble involves receiving data via webhook-based backend workflows or MQTT via a middleware service. This tutorial covers setting up backend workflow endpoints to ingest device data, storing sensor readings in a dedicated Data Type, building real-time dashboards to display device metrics, and triggering automated actions when sensor values exceed thresholds.
Overview: IoT Integration in Bubble
This tutorial shows you how to connect IoT devices to your Bubble app for data collection and monitoring. You will receive device data via webhooks, store readings, visualize them on dashboards, and automate responses to critical events.
Prerequisites
- A Bubble app on a paid plan (backend workflows required)
- An IoT device or service that can send HTTP requests
- Basic understanding of Backend Workflows and Data Types
- Familiarity with Bubble's API settings
Step-by-step guide
Enable backend workflows and create an endpoint
Enable backend workflows and create an endpoint
Go to Settings → API tab and enable Backend workflows. Navigate to the Workflow tab → Pages dropdown → Backend workflows. Create a new API workflow called 'receive_sensor_data'. Add parameters: 'device_id' (text), 'reading_type' (text), 'value' (number), and 'timestamp' (text). Check 'Expose as public API workflow' so your IoT device can send data to it. The endpoint URL will be https://yourapp.bubbleapps.io/api/1.1/wf/receive_sensor_data.
Expected result: A public backend workflow endpoint is ready to receive POST requests from IoT devices.
Create the data model for sensor readings
Create the data model for sensor readings
Go to the Data tab and create two Data Types. First, 'Device' with fields: 'device_id' (text, unique identifier), 'name' (text), 'location' (text), 'status' (text — online/offline), and 'last_seen' (date). Second, 'SensorReading' with fields: 'device' (Device), 'reading_type' (text — temperature, humidity, etc.), 'value' (number), and 'recorded_at' (date). In your backend workflow, add actions to find or create the Device and create a new SensorReading.
Expected result: Device and SensorReading Data Types store incoming IoT data with proper relationships.
Build a real-time device dashboard
Build a real-time device dashboard
Create a new page called 'iot-dashboard'. Add a Repeating Group with type Device showing all registered devices. Display device name, location, status, and last seen time. For each device, show the latest reading using Do a Search for SensorReading where device = current cell's Device, sorted by recorded_at descending, first item. Add a chart plugin to display reading history over time. Bubble's auto-updating searches will refresh the dashboard as new readings arrive without manual refresh.
Expected result: A dashboard displays all devices with their latest readings and historical charts.
Set up threshold alerts
Set up threshold alerts
In your receive_sensor_data backend workflow, after creating the SensorReading, add conditional actions. Add an Only When condition checking if the value exceeds a threshold — for example, temperature > 100. When triggered, create a Notification record for the admin user, send an email alert with device details and the reading value, and optionally send a Slack webhook notification. Store thresholds as fields on the Device Data Type so different devices can have different alert levels.
Pro tip: Add a cooldown mechanism by checking if an alert was already sent in the last hour for this device to prevent alert flooding during sustained threshold breaches.
Expected result: When a sensor reading exceeds the configured threshold, automated alerts are sent to administrators.
Handle device connectivity and data validation
Handle device connectivity and data validation
Add validation in your backend workflow: check that device_id is not empty, value is a valid number, and reading_type matches expected values. For connectivity monitoring, update the Device's last_seen and status fields with every incoming reading. Create a scheduled backend workflow that runs every 5 minutes, searching for Devices where last_seen is more than 10 minutes ago, and setting their status to 'offline'. This gives you device health monitoring alongside data collection.
Expected result: Invalid data is rejected, and device connectivity status is automatically tracked and updated.
Complete working example
1{2 "ENDPOINT": "POST https://yourapp.bubbleapps.io/api/1.1/wf/receive_sensor_data",3 "HEADERS": {4 "Content-Type": "application/json",5 "Authorization": "Bearer YOUR_API_TOKEN"6 },7 "BODY": {8 "device_id": "sensor-001",9 "reading_type": "temperature",10 "value": 72.5,11 "timestamp": "2026-03-28T10:30:00Z"12 },13 "RESPONSE": {14 "status": "success",15 "response": {16 "status": "200"17 }18 },19 "DATA_MODEL": {20 "Device": {21 "device_id": "text (unique)",22 "name": "text",23 "location": "text",24 "status": "text (online/offline)",25 "last_seen": "date",26 "alert_threshold": "number"27 },28 "SensorReading": {29 "device": "Device",30 "reading_type": "text",31 "value": "number",32 "recorded_at": "date"33 }34 },35 "ALERT_WORKFLOW": {36 "trigger": "value > Device's alert_threshold",37 "actions": [38 "Create Notification for admin",39 "Send email alert",40 "Optional: Slack webhook"41 ],42 "cooldown": "1 alert per device per hour"43 },44 "CONNECTIVITY_CHECK": {45 "schedule": "Every 5 minutes",46 "action": "Set status = offline where last_seen > 10 min ago"47 }48}Common mistakes when connecting IoT Devices and Services to Bubble
Why it's a problem: Not securing the backend workflow endpoint with authentication
How to avoid: Require an API token in the request header and validate it in your backend workflow
Why it's a problem: Storing every single sensor reading without archival strategy
How to avoid: Aggregate older readings into hourly or daily averages using a backend workflow, then delete the raw readings
Why it's a problem: Not handling device disconnection
How to avoid: Track last_seen timestamp and use a scheduled workflow to flag devices as offline after a timeout period
Best practices
- Secure your webhook endpoint with API token authentication
- Validate incoming data before storing it in the database
- Aggregate old sensor readings to manage database growth
- Monitor device connectivity with automated status checks
- Set up threshold alerts with cooldown periods to prevent alert flooding
- Use Option Sets for reading types and device statuses for consistency
- Test with sample data before connecting actual IoT devices
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have IoT temperature sensors that can send HTTP POST requests. How do I set up my Bubble.io app to receive this data, store it, and display it on a real-time dashboard?
Help me create a backend workflow endpoint that receives sensor data from IoT devices and stores it in my database. I also want a dashboard page showing latest readings per device.
Frequently asked questions
Can Bubble handle high-frequency IoT data?
Bubble can handle moderate data rates. For sensors sending data every few seconds, use a middleware service to batch readings and send them to Bubble every minute. Direct high-frequency ingestion will consume significant WUs.
Does the dashboard update in real-time?
Yes. Bubble's auto-updating searches refresh data on page elements when new records are created, so dashboard values update without manual refresh.
Can I use MQTT protocol with Bubble?
Not directly. Bubble only accepts HTTP requests. Use a middleware service like Node-RED or AWS IoT Core to bridge MQTT messages to HTTP webhooks that your Bubble endpoint receives.
How do I handle device authentication?
Include an API token in the device's HTTP request headers. Validate this token in your backend workflow before processing the data.
What about storing historical data long-term?
For long-term storage, aggregate raw readings into hourly or daily summaries using a backend workflow, then archive or delete granular data older than 30 days.
Can RapidDev help build IoT dashboards in Bubble?
Yes. RapidDev can set up complete IoT data pipelines in Bubble including device management, real-time dashboards, alerting, and historical data analysis.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation