HTTP In Node-RED: Build an API and Receive ESP32 POST Data
Node-RED can expose an HTTP endpoint that receives JSON from another device. This can be useful when a sensor sends a periodic reading, a browser posts form data or a flow needs to accept a small event. MQTT is often a better fit for ongoing many-to-many telemetry, while HTTP is useful for request/response operations and integrations where an endpoint is expected.
This tutorial creates a POST route in Node-RED, validates a small sensor payload, returns an HTTP response and explains how an ESP32 can send a request. Begin on a trusted local network. A self-made endpoint is not automatically secure because it is hard to guess or because it uses a custom path.
1. Create the HTTP route
Add an HTTP In node and set its method to POST and URL to /api/sensor. Connect it to a Function or Change node, then to an HTTP Response node. Every handled HTTP In request should reach a response path; otherwise the client may wait until it times out.
HTTP In starts a flow with information about the request. The body may be parsed as JSON depending on Node-RED's configuration and request content type, so inspect the payload with Debug before building validation around it. Set the ESP32 request's Content-Type to application/json.
2. Validate the request before using its data
A request body from a device is untrusted input. Validate its structure, data types, sensible ranges and required fields. Do not accept any arbitrary object and forward it straight to a database or to relay logic.
The Function example below shows a minimal lab guard that checks a shared key from Node-RED's environment and verifies a numeric temperature field. Configure SOLDERHUB_API_KEY as a server-side environment variable, not as a value in an exported flow. This simple header check is not a substitute for TLS: plain HTTP can expose the key on an untrusted network. Use an authenticated HTTPS endpoint or a secure reverse proxy for real deployments.
3. Return a predictable response
Connect the Function output to HTTP Response. The example returns 401 for missing/incorrect key, 400 for invalid data and 200 when the value is accepted. Keep the response concise and do not echo secrets. If you add database writes, do not report success until the write result has been checked; include a separate error branch for storage failures.
Deploy the flow and test the route from a tool such as curl on the Node-RED host or trusted LAN. Use a non-sensitive test token and test both valid and invalid bodies. A request with an incorrect key should not pass through the same storage/control path as a valid request.
4. Send JSON from an ESP32
After confirming the Node-RED route locally, the ESP32 can use HTTPClient to post data. Replace the URL and credentials locally. Use the Node-RED host's LAN address if the device is on the same network; 127.0.0.1 would refer to the ESP32 itself. This example uses plain HTTP for a trusted local-lab demonstration only.
5. Return to the data path and test failure cases
After the endpoint receives JSON, it can route validated measurements to Dashboard 2.0, MQTT or a database. Add timestamp and device identity fields if several devices will call the endpoint. Decide how requests are authenticated and rate-limited, how duplicates are handled, and how clients should retry if the server times out.
Test a valid request, missing API key, wrong key, malformed JSON, missing field, out-of-range reading, unavailable server and Wi-Fi drop. A successful HTTP status only confirms the operation that your flow actually performed; it does not prove downstream hardware or data storage succeeded unless that is explicitly checked.
Security checklist
- Do not expose the Node-RED editor to the internet without authentication and network protections.
- Do not treat a custom URL path as authentication.
- Avoid sending shared API keys over plain HTTP outside a trusted isolated lab.
- Use HTTPS/TLS via a supported Node-RED setup or secure reverse proxy for untrusted networks.
- Keep keys in server configuration, not public flow exports or screenshots.
- Validate request method, headers, body schema, numeric ranges and request frequency.
- Restrict what a valid request can do; sensor upload credentials should not automatically authorize relay control.