Skip to content
Stack Developer Resources
Guides
Interface
Old
Resources
Share
Explore

Message Routes

Overview

A device message route defines the path that incoming device data takes through the Leverege Stack's backend services. When a device reports data (like GPS coordinates, sensor readings, or status updates), the message route determines which services process that data and in what order.
Device message routes are configured in Architect and attached to a blueprint (applying to all devices of that type) or to an individual device (for testing or special cases).

How They Work

Message Routes are hierarchical, and can be referenced at the device or blueprint level. When device data arrives:
An ingestor receives an external message format and generally converts it into an inboundDataEventMsg, identifying the device that created the message with a network id triplet. This is then sent to the default-processor topic (where message-processor lives)
Message Processor looks up the Device by its message triplet, and then resolves the Device’s Message Route by checking the device and then its blueprint for a message route id.
Message Processor then routes the message as a routeMsg, where each subsequent service will continue routing the message based on the route spec in the message.
During processing, each service can modify, augment, or choose to not forward the message

Typical Flow

Device → Ingestor → Message Processor → [Route Topics] → Writer → Database
⁠

Why Device Message Routes Matter

Without a message route, device data goes directly to the database. With a message route, you can:
Run business logic - Send data through the Rules Engine before writing
Process data concurrently - Write to the database while simultaneously triggering rules
Add custom processing - Route data through custom microservices for transformations or integrations

Common Patterns

Write Only (Default)
{
"deviceDataEventMsg": ["writer"]
}

Data goes straight to the database. Use when no business logic is needed.
Rules Engine → Write (Most Common)
{
"deviceDataEventMsg": ["rule-engine", "writer"]
}

Data is processed by the Rules Engine first, then written. Required for any rules that trigger on device updates.
Concurrent Processing
{
"deviceDataEventMsg": {
"type": "concurrent",
"routes": [
{ "topic": "rule-engine" },
{ "topic": "writer" }
]
}
}

Data goes to both services simultaneously. Use when rules and writes are independent (This is a rare use-case).

Assigning a Message Route

Create the message route in Architect > Message Routes
Copy the message route ID
Paste it into the Msg Route field on either:
A blueprint's Info page (applies to all devices of that type)
A device's Info page (overrides blueprint setting for that device)
Note: Message routes are typically set on blueprints, not individual devices. Setting on a blueprint automatically applies to all devices of that type.

Troubleshooting

Rules not firing on device updates: rule-engine not in the message route
Data not appearing in database: writer missing or route broken before reaching it
Rules work but custom service doesn't receive data: Custom topic not added to route
⁠

Overview
How They Work
Typical Flow
Why Device Message Routes Matter
Common Patterns
Assigning a Message Route
Troubleshooting
Want to print your doc?
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.