Overview

This document describes the HTTP API exposed by the Web Panel Receiver. It is intended for developers who want to build a custom UI instead of (or in addition to) the built-in designer and runtime panels. For example:

A screenshot of a computer

AI-generated content may be incorrect.

The receiver runs as a local HTTP server. Your UI just needs a browser with fetch and EventSource, or any HTTP/SSE client.

Architecture

A close-up of a sign

AI-generated content may be incorrect.

· Your UI connects to the Web Panel receiver HTTP server — it does not talk to the executable directly.

· State is pushed to your UI via Server-Sent Events (SSE); you send commands via HTTP POST.

File Hosting

Custom panels can be opened in a browser using http:// rather than file:// — avoiding browser restrictions on local file access (CORS, module imports, fetch, etc.).

When running from Rhapsody, the receiver serves everything in the ‘panelDir’ as set through properties of a Web Panel model element.

When running standalone, it serves everything from the panel subfolder of the exported directory (the ‘exportDir’ of the Web Panel model element.

To add custom content, simply place files alongside the generated ones. You may add these to the panelDir or only to the exported bundle. Adding to the panelDir has the advantage of allowing testing from Rhapsody. The Export as Web Panel Bundle automatically copies all of the panelDir content to the panel subfolder of the exportDir.

All standard web asset types are served with the correct MIME type, including HTML, CSS, JavaScript (.js/.mjs), JSON, images (PNG, JPEG, GIF, WebP, SVG), web fonts (WOFF, WOFF2, TTF, OTF), and source maps.

Browsing a directory URL returns an auto-generated index page with clickable links. The /panels endpoint provides a machine-readable list of all user HTML files.

Endpoints

The Web Panel Receiver exposes a HTTP Server (by default on port 8080 but this is configurable in the Web Panel Model Element) with the following endpoints:

Method	Path	Purpose
GET	/events	SSE stream — receive all live updates
POST	/command	Send a command to the C++ executable
GET	/panels	Lists available html files
GET	/fonts	Lists available custom fonts
GET	/layout	Load a saved panel layout
POST	/layout	Save a panel layout
GET	/*	Serve static files from the panel directory

All endpoints include Access-Control-Allow-Origin: *, so cross-origin requests from a file or different port are allowed.

Endpoints are detailed here:

· Events

· Command

· Panels

· Fonts

· Layout

· Static File Serving

· Minimal Custom UI Example

Notes

· Instance keys are always “ClassName:instanceName” — the colon is the separator. instanceName is the raw instance identifier reported by the instrumented executable (format varies, e.g. “#0” or “itsB”) — it is NOT the same as instanceLabel. The human-readable dot-path label is in instanceLabel (e.g. “itsBlockA”). Use instanceLabel as the instanceKey when building layout.json. Use instanceName when sending commands via POST /command.

· Multiple instances of the same class each have distinct instance names (e.g. “#0”, “#1”). Use instanceLabel (from the snapshot) as the human-readable key in layout.json.

· Attribute values are always strings in the API, even for numeric types. Parse them yourself (parseInt, parseFloat, etc.).

· Active states are a set — an instance can be in multiple states at once. Do not assume it is always exactly one.

· Executable disconnect clears all state. Your UI should reset to an empty state on executableDisconnected.

· Commands are not echoed back as SSE events. The C++ executable decides what (if any) notifications to send in response to a command.

· The receiver does not validate commands. If a command is malformed or the executable is not connected, it is silently dropped.