Integration surfaces

Use this page to choose how each customer system talks to Cyberwave. One table covers every surface. The sections after it cover MQTT connection details and PLC, MES and WMS patterns.

All surfaces at a glance

Surface	Use it when	Auth	Reference
REST API (`https://api.cyberwave.com/api/v1/...`)	Request/response work from any language: create twins and environments, provision organizations, workspaces and members, trigger workflows, read alerts, manage edges	`Authorization: Bearer <token>` (the `Token` prefix is also accepted)	API overview · REST reference
Python SDK (`pip install cyberwave`)	Python services and scripts. Wraps REST and MQTT.	`CYBERWAVE_API_KEY`	Python SDK · C++ SDK
CLI (`cyberwave`)	Provisioning scripts, edge management, CI	Stored login, `CYBERWAVE_API_KEY`, or `--token`	CLI
MQTT (`mqtt.cyberwave.com`)	Real-time telemetry and commands from a non-Python service, or a custom driver	API token as password. See Connecting to MQTT.	MQTT reference
Workflow triggers (`webhook`, `mqtt`, `schedule`, `email`, `event`, `manual`)	Start a no-code automation from an external event	REST or SDK trigger: API token. Webhook: not documented.	Workflow nodes · MQTT trigger
Workflow outputs (`http_request`, `send_email`, `send_mqtt`, `send_ros2`, `send_alert`)	Push results out of a workflow to an external API, email, a twin topic or ROS 2	Configured on the node	Workflow nodes
Execution ingress (MQTT)	Report runs of your own external process as workflow executions, so they appear on the Cyberwave timeline	Broker-level (MQTT credentials)	Execution ingress
A2A partner API (`POST /api/v1/a2a`)	An external agent submits a natural-language task and follows it over SSE	Workspace-scoped API token with the `a2a` scope key	A2A partner API
MCP server (`https://mcp.cyberwave.com/mcp`, or self-hosted over stdio)	AI agents and IDEs (Claude, Cursor, any MCP client) operate environments, twins and workflows	`Authorization: Bearer <CYBERWAVE_API_KEY>`	MCP server (early access)
ROS 2 (`BaseROS2Driver`, `send_ros2` node)	The robot already speaks ROS 2. Bridge its topics into a twin, or publish typed messages from a workflow.	Runs as a driver under Edge Core with the driver’s API key	BaseROS2Driver · UR Sim tutorial
Custom driver (Docker image under Edge Core)	Any device with its own protocol: vendor SDK, serial, CAN, fieldbus gateway	`CYBERWAVE_API_KEY` injected into the container	Writing compatible drivers
Zenoh–MQTT bridge (`cyberwave.zenoh_mqtt`)	Forward selected local Zenoh channels to cloud MQTT, with a file-backed queue while offline	MQTT password = API key	Zenoh–MQTT bridge
Cloud nodes (`cyberwave-cloud-node`)	Run inference, training or simulation on your own GPU machines, commanded by the platform	`CYBERWAVE_API_KEY`	Cloud node (early access)
Live video (WebRTC)	Consume a twin’s camera in your own app. There is no RTSP, HLS or WHEP output.	API token or user MQTT credentials for signaling	Consume live video
Docker registry (`registry.cyberwave.com`)	Distribute private driver and model images	API key via credential helper or `docker login`	Docker registry (Enterprise)

For long-lived integrations, use a service token scoped to the customer’s workspace, not a personal token. See API tokens.

Connecting to MQTT

These values come from the Python SDK (cyberwave/config.py, cyberwave/mqtt/__init__.py, cyberwave/mqtt_identity.py).

Setting	Value
Host	`mqtt.cyberwave.com`
Port	`8883`, MQTT over TLS. The SDK turns TLS on automatically for this port and verifies the server certificate.
Browsers	`wss://mqtt.cyberwave.com` (MQTT over secure WebSocket)
Password	Your API token
Username	`cwh_` followed by the SHA-256 hex digest of the token. The SDK derives it for you. The broker refuses a username that does not hash to the token.
Protocol	MQTT 3.1.1 by default. MQTT 5 with `CYBERWAVE_MQTT_PROTOCOL=5`.
Client ID	Must be unique per connection. Keep it within 23 bytes for MQTT 3.1.1.
Topic prefix	None in production. Other deployments may prefix every topic (`CYBERWAVE_MQTT_TOPIC_PREFIX`).
Authorization	Checked per topic against the token’s access to the twin or workflow. For WebRTC signaling, subscribing needs read access and publishing needs write access.

import hashlib
import os
import ssl

import paho.mqtt.client as mqtt
from paho.mqtt.enums import CallbackAPIVersion

token = os.environ["CYBERWAVE_API_KEY"]
username = "cwh_" + hashlib.sha256(token.encode("utf-8")).hexdigest()

client = mqtt.Client(callback_api_version=CallbackAPIVersion.VERSION2, client_id="mes_bridge_01")
client.username_pw_set(username=username, password=token)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_message = lambda c, u, msg: print(msg.topic, msg.payload)

client.connect("mqtt.cyberwave.com", 8883)
client.subscribe("cyberwave/twin/<twin_uuid>/position")
client.loop_forever()

In Python, the SDK does all of this for you. Use Cyberwave() with CYBERWAVE_API_KEY set.

PLC, MES and WMS

Status today: Cyberwave ships no built-in OPC UA, Modbus or VDA5050 driver. Some older pages list these protocols as supported. That means you can bridge them with a driver you write, not that a driver exists. The SDK has an AMR edge-node base class (cyberwave.edge.AMREdgeNode) with adapter hooks and VDA5050 configuration fields. No VDA5050 adapter ships with it. These patterns are possible with the pieces that exist:

MES or WMS starts a robot task

Build a workflow whose actuation nodes move the twin (twin_control, send_joint_commands, send_controller_command). Start it from the business system through REST or the SDK:

from cyberwave import Cyberwave

cw = Cyberwave()  # reads CYBERWAVE_API_KEY
run = cw.workflows.trigger(
    "acme/workflows/pick-order",
    inputs={"order_id": "SO-1042", "bin": "A3"},
)
run.wait(timeout=300)
print(run.status, run.result)

cw.workflows.trigger calls POST /api/v1/workflows/{uuid}/trigger, so any language can do the same over REST. A webhook trigger node is the alternative when the business system can only send an HTTP call. Its URL and authentication are not documented yet.

Report results back to the business system

End the workflow with an http_request node that calls the MES or WMS API. Alternatively, have your integration service poll the run (run.wait() / GET /api/v1/workflows/executions/{execution_uuid}), or subscribe to the twin’s MQTT event topics.

Read or write PLC tags

Write a custom driver: a Docker image that Edge Core runs next to the cell. Inside it, use an OPC UA or Modbus client library of your choice and map tags to the twin’s MQTT topics. For small jobs, a code node runs your own Python on the edge worker. Keep the PLC as the source of truth for interlocks.

Robot on ROS 2

Use BaseROS2Driver to forward ROS 2 topics into the twin with little code, and the send_ros2 workflow node to publish typed messages back. Start from the UR Sim tutorial.

Cyberwave does not replace the cell’s safety system. Keep e-stops, safety interlocks and safety-rated stops in the PLC and the robot controller. The tutorials say it plainly: software-only stops are for convenience, not safety.

Next steps

Cyberwave for integrators

Architecture, data flows and deployment options.

Network and firewall

Hosts and ports for each surface.

Writing compatible drivers

Build a driver for a device Cyberwave doesn’t support yet.

Workflows

Triggers, actions, and where each node runs.

Get started

AI agents

AI models

Control

Learn

Run on edge or cloud

Platform

For integrators

Help

All surfaces at a glance

Connecting to MQTT

PLC, MES and WMS

Next steps

Cyberwave for integrators

Network and firewall

Writing compatible drivers

Workflows

​All surfaces at a glance

​Connecting to MQTT

​PLC, MES and WMS

​Next steps

Cyberwave for integrators

Network and firewall

Writing compatible drivers

Workflows

All surfaces at a glance

Connecting to MQTT

PLC, MES and WMS

Next steps