Skip to main content

Endpoint as gateway

Endpoint can be set up as the server, not just a client. A fleet of sensors or small microcontrollers on the local network can publish to Endpoint, which aggregates, filters, buffers, or transforms the data before pushing it upstream. This is the classic edge-gateway pattern.

What makes this straightforward on Endpoint:

  • Full .NET and Python stacks that host standard HTTP and MQTT servers out of the box.
  • Full TLS 1.3 with the operating system's certificate trust store, so no hand-managed cert pinning per client.
  • SD-card and eMMC storage to buffer telemetry while the uplink is down, then drain the backlog when it returns.
  • A real SQLite database for local caching, deduplication, and temporary persistence.
  • Standard async I/O, so one gateway process serves multiple concurrent connections.

Common building blocks​

  • HTTP / REST API: host with ASP.NET Core minimal API on .NET, or FastAPI / Flask on Python.
  • MQTT broker: MQTTnet includes a broker component in the same package as the client; drop it into any .NET application.
  • WebSocket server: standard System.Net.WebSockets.WebSocket on .NET, websockets on Python.
  • Local store: SQLite for deduplication, buffering and short-term state.

Example shape​

A typical Endpoint gateway runs three things concurrently in one process: a north-facing uplink (MQTT or HTTPS to the cloud), a south-facing server (the API or broker that sensors talk to), and a worker loop that drains the local queue toward the cloud whenever the uplink is healthy. All three share the same TLS stack, the same connection pool, and the same SQLite instance.

See MQTT for the specific protocol details on each side.