Modbus to REST API
When the receiving system is an HTTP API rather than a broker, the Gateway posts the same normalized values to your endpoint, with the authentication it expects and a retry policy that does not lose data on a bad afternoon.
Typical use case
An existing web application, an ERP or a data platform already has an ingest endpoint. Rather than adding a broker to the architecture, the gateway posts straight to it.
[
{ "device": "Main Meter", "tag": "Voltage_L1", "value": 230.5, "unit": "V", "quality": "GOOD", "timestamp": "2026-03-04T09:21:14.250Z" },
{ "device": "Main Meter", "tag": "Current_L1", "value": 12.8, "unit": "A", "quality": "GOOD", "timestamp": "2026-03-04T09:21:14.251Z" }
]Configuration approach
Endpoint and method
POST, PUT or PATCH to a URL, with any headers the API requires.
Authentication
API key, bearer token or basic authentication. Credentials are held in an encrypted store on the runtime, never in the project file or the deployment package.
Batching
Send one value per request, or collect several into one JSON array to cut request volume.
Reliability
Timeouts, retries and Store & Forward. A failed POST is buffered and replayed rather than dropped.
Questions engineers ask
Is the payload shape fixed?
The runtime publishes a standard envelope with the device, tag, value, unit, quality and timestamp, individually or grouped per device. A JSON template node on the wire reshapes it into a payload of your own, from the value, tag, device, unit, quality and timestamp.
Build a Modbus to REST API gateway
Create a project, define the device and its tags in the Edge Logic Editor, and download a runtime to test at the plant.