The /peers/* endpoint is a dynamic dispatcher that lets you invoke any peers method through HTTP. It is the bridge between the REST world and the full peers API — instead of writing one HTTP route per method, the gateway parses the URL and forwards the call to the corresponding peers module.
This means every method documented in the peers reference is reachable through /peers/* without any extra setup.
/peers/{peer}/{module}/{method}
| Segment | Description | Typical value |
|---|---|---|
peer |
Target peer name on the mesh | supervision (the main gateway process — almost always this) |
module |
Module exposed by the peer | gateways, loggers, system, accounts, logics |
method |
Method to call on the module | writeValue, getLastValue, getGateways, … |
Example — write a value to a KNX address:
curl -b cookies.txt -X POST \
'https://gateway.example.com/peers/supervision/gateways/writeValue?address=4/7/25&value=1'
This is exactly equivalent to calling gateways.writeValue('4/7/25', 1, callback) from a peers client.
The dispatcher converts query string parameters and request bodies into the positional arguments expected by the peers method.
For GET, every query parameter becomes a named argument. The dispatcher tries to parse JSON values automatically (numbers, booleans, arrays, objects).
# gateways.getGateway(12, callback)
curl -b cookies.txt 'https://gateway.example.com/peers/supervision/gateways/getGateway?gateway=12'
# gateways.getLastValue('4/7/25', callback)
curl -b cookies.txt 'https://gateway.example.com/peers/supervision/gateways/getLastValue?address=4/7/25'
For POST, you can either pass the arguments as a JSON body or use query parameters as on GET.
# gateways.writeValue('4/7/25', 1, callback)
curl -b cookies.txt -X POST \
-H 'Content-Type: application/json' \
-d '{"address":"4/7/25","value":1}' \
'https://gateway.example.com/peers/supervision/gateways/writeValue'
You can also pass positional arguments directly in the URL path after the method name. They are appended to the argument list.
# Equivalent to writeValue('4/7/25', 1, callback)
curl -b cookies.txt -X POST \
'https://gateway.example.com/peers/supervision/gateways/writeValue/4/7/25/1'
This form is convenient when the argument is a single primitive — for complex objects, use the JSON body form.
The default response is a JSON envelope:
{ "result_field" : "..." }
On error:
{ "err" : "error message" }
?format=jsonForce standard JSON output. Use this when your client is a strict JSON parser that does not handle the few peers-specific extensions (Buffer, Date, …).
?format=json-no-evalSame as format=json but encodes types in a way that does not require any post-processing on the consumer side. Recommended for cross-language clients.
?streaming=1Some peers methods invoke their callback multiple times as a stream — loggers.query is the canonical example. When you call them through /peers/*, set streaming=1 to receive an NDJSON response: each chunk of data becomes one line, terminated by \r\n.
curl -b cookies.txt -N \
'https://gateway.example.com/peers/supervision/loggers/query?streaming=1' \
-H 'Content-Type: application/json' \
-d '{
"address" : "4/7/25",
"start" : "2026-04-07T00:00:00Z",
"end" : "2026-04-08T00:00:00Z",
"aggregate" : "15m"
}'
For loggers.query specifically, the dispatcher emits a JSON array ([, then each row separated by ,, then ]) instead of NDJSON — this matches what most cloud consumers expect.
If the exact method name does not exist on the target module, the dispatcher tries a few common prefixes based on the HTTP verb:
| HTTP method | Prefix tried |
|---|---|
GET |
get<Method> |
POST |
insert<Method> |
PUT (treated as path) |
update<Method> |
So GET /peers/supervision/gateways/Gateway?gateway=12 resolves to gateways.getGateway(12, …) even though there is no method called Gateway. This is mostly useful when wiring the dispatcher behind a RESTful URL scheme — you don't have to encode the verb prefix in the URL.
If neither the literal name nor the prefixed variants match, the response is 400 with { "err": "Unknown method ..." }.
# gateways.writeValue
POST /peers/supervision/gateways/writeValue
Body: {"address":"4/7/25","value":1}
# gateways.getLastValue
GET /peers/supervision/gateways/getLastValue?address=4/7/25
# gateways.readValue
GET /peers/supervision/gateways/readValue?address=4/7/25
# gateways.getGateways
GET /peers/supervision/gateways/getGateways
# gateways.getAddressesByGateway
GET /peers/supervision/gateways/getAddressesByGateway?gateway=12
# gateways.insertRoute
POST /peers/supervision/gateways/insertRoute
Body: {"from":"4/7/25","to":"%M1","type":"write"}
# gateways.restartGateway
POST /peers/supervision/gateways/restartGateway?gateway=12
# loggers.query — set streaming=1
GET /peers/supervision/loggers/query?streaming=1
Body: {"address":"4/7/25","start":"...","end":"...","aggregate":"15m"}
For high-volume queries, prefer the dedicated /loggers/data endpoint which has been optimized for federation across multiple connectors.
| Use case | Best choice |
|---|---|
| Historical queries with site federation | /loggers/data |
| Live value subscriptions | /loggers/live |
| Pushing writes from the cloud | /loggers/function |
| Anything else (gateways, addresses, routes, system, accounts, …) | /peers/* dispatcher |
The dedicated endpoints are tuned for cloud federation and high throughput. The dispatcher is the catch-all for everything else — it gives you the entire peers surface without needing a per-method REST route.