The Weble IoT Universal Gateway exposes its capabilities through two complementary APIs. They cover the same underlying system — gateways, addresses, routes, historical data, accounts, and process control — but target different kinds of clients.
| Peers API | REST API | |
|---|---|---|
| Transport | WebSocket (socket.io) | HTTPS |
| Auth | POST /auth (bootstraps the client) |
POST /auth/rest (returns a session) |
| Surface | The full system: every module, every method | A curated subset: loggers, peers dispatcher, streaming, system |
| Best for | Browser UIs, Node.js integrations, deep automation | Cloud, mobile apps, third-party HTTP clients |
The native API of the gateway. Every internal subsystem talks to every other through the peers protocol — drivers, the routing engine, the logic module, the web server, and the UI all share the same primitives. External clients load a small JavaScript runtime via POST /auth, which gives them direct access to every module method as if they had require()'d it locally.
Use the peers API when you need the full surface area, when you want to listen to live events, or when your client can run JavaScript.
→ Open the Peers API documentation
A focused HTTP/JSON veneer over the same modules. It is the API used by the Weble Cloud to query historical data, push live updates, forward write operations, and manage remote gateways. It does not require any special runtime — any HTTP client in any language works.
Use the REST API when your client cannot load JavaScript, when you want a simple cross-language integration, or when you only need a small subset of operations.
→ Open the REST API documentation
Neither API is publicly accessible by default — both require authentication at the entry point, and the WebSocket / HTTPS transport must be wrapped in TLS when reachable from outside the local network. Keep the gateway behind a firewall or VPN if it is exposed beyond a trusted environment.