Bolt IoT
Developer ToolsConnect AI agents to the Bolt IoT cloud platform for connected hardware. Agents read analog and digital GPIO values, write control signals to pins, exchange serial data, and check device online status.
What This Integration Enables
Bolt IoT gives a flow the pins. That is the whole proposition, and it is a genuinely different proposition from a device cloud built around named variables. There is no type system here, no permission model on a pin, no sketch-level contract about what a value means. Digital Write sets pin 0 HIGH. What happens next depends entirely on what somebody soldered to pin 0, and the Bolt Cloud has no idea what that is.
For prototyping, teaching hardware, and small deployments where the person writing the flow is the person who built the rig, that directness is exactly right. Nine operations cover the module's remote surface completely. Digital Write and Digital Multi-Write set pins HIGH or LOW, and Digital Read reports a pin's level. Analog Write sends a PWM value between 0 and 255, and Analog Read samples an analog input. Serial Begin, Serial Write, and Serial Read drive the UART interface. Device Is Online checks whether the module is reachable at all. Every operation takes a Device Name, which is the Bolt device identifier such as BOLT13819450, so one connection can address a fleet of modules.
Two behaviours of the underlying API are worth understanding before building anything against it. First, the Bolt Cloud returns HTTP 200 even when a command fails, carrying the outcome inside a JSON body as a success field. FlowRunner's connector inspects that field and raises a step error when it reports failure, passing through the returned message such as an invalid key notice, so a flow does not sail past a rejected command believing it worked. Second, the Bolt Cloud embeds the API key in the request URL path rather than in a header. Keys in URLs turn up in server access logs, proxy logs, and history caches far more readily than header credentials do, which is worth knowing when deciding what that key is allowed to control. Treat it as sensitive and rotate it if it may have been exposed.
There are no triggers. Bolt publishes no event subscription surface, so a flow either calls the module inline as part of a larger workflow or polls it on a schedule with Digital Read and Analog Read. And the module must be online for any GPIO or serial command to reach it, which makes Device Is Online the only pre-flight check the platform offers.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A sensor that finally gets written down
A workshop has a Bolt module reading an analog sensor on a piece of equipment, and until now reading it meant somebody opening the dashboard. A flow runs every ten minutes: Device Is Online, then Analog Read on the input pin, then a row appended to Google Sheets with the timestamp, the device name, and the raw value. Two weeks later the workshop has something it never had before, which is a history. The same flow posts to Slack when a reading crosses a threshold, and because the connector raises an error on a failed cloud response rather than passing an empty value through, a gap in the sheet means the module was unreachable rather than the sensor reading zero.
Talking to the peripheral that is not the Bolt
The Bolt module's UART is often the only route to a device that has no network of its own, such as a weighing scale, a controller, or an instrument with a serial console. A flow calls Serial Begin at the baud rate the peripheral expects, commonly 9600, writes an ASCII query string with Serial Write, waits, and calls Serial Read to pull back up to a set number of characters. The agent parses the response and files the reading into the record it belongs to. Serial is a stream, not a request and response protocol, so the flow owns the pacing and the parsing, and the read is bounded by character count rather than by a message boundary the cloud understands.
An indicator that reflects a system nobody is standing next to
A physical status light in a workshop is genuinely useful when it is honest. A flow polls a build server or a queue depth and drives a small indicator through the Bolt module: Analog Write with a PWM value to vary brightness with queue depth, or Digital Write to switch a lamp on a hard threshold. The rule that makes this work rather than become noise is that only the informational pins are automated. Anything wired to something that moves, heats, or carries load stays behind a person, for the reason the next section sets out.
Human-in-Loop Highlight
The gate belongs on Digital Multi-Write, and it belongs there because of a property unique to that action: it takes two aligned lists, one of pins and one of states, and applies them together. A misalignment between those lists is not a validation error. The API cannot detect it, because both lists are perfectly valid, and neither the cloud nor the module knows that pin 2 was supposed to be the one going LOW. It is simply a different machine state, applied in one call, with no intermediate step to inspect and no undo. Everything Bolt makes easy about direct pin access makes this worse rather than better: there is no property name to sanity check, no type to reject a wrong value, and no permission flag marking a pin as unsafe to write. Digital Read afterwards tells you what level the pin is sitting at, which is not the same as telling you whether the relay behind it closed or whether the thing the relay controls was supposed to be running. So an agent driving live hardware assembles the change and stops before applying it: "Device BOLT13819450, applying 3 pins together. Pin 0 LOW (currently HIGH), pin 1 HIGH (currently LOW), pin 3 LOW (currently LOW). Device online. Confirm this mapping against the wiring." A person who has seen the inside of the enclosure answers, and Digital Multi-Write runs on that answer. This is human-in-the-loop placed where the platform's own safeguards run out: FlowRunner cannot verify a wiring diagram, and it should not pretend the pin numbers alone are enough.
Agent Capabilities
9 actionsDigital GPIO
3- Digital Write Sets a single digital pin HIGH or LOW on the named device. The most direct control action in this connector, and the one whose consequence depends entirely on what is wired to the pin.
- Digital Multi-Write Sets several digital pins at once from aligned pin and state lists. Efficient when a state change spans multiple outputs, and the action with the widest blast radius here, because the two lists are applied together and a misalignment is indistinguishable from an intended change.
- Digital Read Reads the digital value of a pin, returning 0 or 1. Reports the pin's level, which is a useful check but not a confirmation that whatever the pin drives responded.
Analog GPIO
2- Analog Write Writes a PWM value between 0 and 255 to a pin. Used for variable output such as brightness or motor speed rather than a simple on and off state.
- Analog Read Reads an analog value from an analog input pin. The main sensing action, and the one most flows are built around when the module is being used for monitoring rather than control.
Serial
3- Serial Begin Starts serial communication at a chosen baud rate. The rate is sent to the device as given, so it must match the attached peripheral, commonly 9600. Always the first serial call in a flow.
- Serial Write Writes an ASCII string to the serial port. Used to send a query or a command to a peripheral that has no network connection of its own.
- Serial Read Reads incoming serial data up to a set number of characters. Bounded by character count rather than by a message boundary, so the flow owns the parsing.
Device
1- Device Is Online Checks whether a device is connected to the Bolt Cloud. The only pre-flight check the platform offers, and worth calling before any GPIO or serial command, because a command sent to an offline module simply does not arrive.
Frequently Asked Questions
What can FlowRunner do with Bolt IoT?
FlowRunner agents can run Digital Write, Digital Multi-Write, and Digital Read in Bolt IoT, plus 6 more actions.
Does connecting Bolt IoT to FlowRunner require OAuth?
No. Bolt IoT connects to FlowRunner with an API key, no OAuth flow required.
Can Bolt IoT trigger a FlowRunner workflow automatically?
Bolt IoT doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Bolt IoT
$100 in credits. No card required. Connect in minutes.