Cortex in depth
The Cortex chapter shows the canvas where you see devices, groups, and data destinations. This chapter goes deeper: what you can actually configure on an endpoint, what destination types exist, and how you monitor a route and keep it error-free.
Groups and routing
A Group combines several devices so you can forward them together to one or more destinations, instead of wiring up every device individually. You drag devices onto a group, assign or remove them, and then connect the group to one or more endpoints.
If a routing rule refers to a group or destination that has since been deleted, it's no longer drawn on the canvas. That's the cue to look for orphaned rules in the routing settings when data unexpectedly stops arriving.
Destination types for endpoints
When creating an endpoint, you choose one of the following types:
- Webhook — an HTTP call to a URL you specify.
- MQTT Forward — delivery to your own MQTT broker.
- AMQP — delivery to your own AMQP broker.
- REST Pull API — the platform makes the data available so your system actively fetches it, instead of it being delivered.
- Pallax Analytics — forwarding into this platform's own Analytics chapters (see Dashboards).
- Custom Endpoint — your own protocol and your own payload format, when none of the preceding types fit.
For each route you also set the Data Format: raw data only, decoded values only (see Decoder), or both together.
What you configure per endpoint
Every endpoint has its own configuration area with several tabs:
- Output schema — the format the data arrives in at the destination.
- Sandbox — a test environment to check a configuration before it goes live.
- Authentication — the credentials the platform uses to sign in at the destination.
- Draft vs deployed — a comparison between a saved draft and the currently active configuration.
- Route metadata — additional information about the route itself.
On top of that come reliability settings: a Retry Policy for failed deliveries, a Dead Letter Queue for messages that still don't arrive even after retries, a Circuit Breaker that pauses a persistently failing delivery instead of retrying it endlessly, Alerts for delivery problems, and a Rate Limit for delivery frequency.
Observing and checking a route
- Delivery History shows you past deliveries for this route.
- Latency shows how long a delivery takes on average.
- Delivery Logs list the individual delivery attempts with their outcome.
- Pipeline Health Check checks the entire route in one pass.
- Inject test payload sends a sample message you choose through the route, without waiting for a real device uplink — useful for checking a new configuration before real device data flows through it.