The structure

The pipeline describes what happens to a message, in order. This is the other view: the map — which parts exist, what they talk to, and what is kept.

flowchart TB
  subgraph left["Device networks"]
    direction LR
    SF["Sigfox"]
    CS["ChirpStack"]
    TT["TTN"]
  end

  subgraph center["Una IoT Center"]
    direction TB
    IN["Ingest endpoint<br/>authenticates the payload"]
    NORM["Normalise<br/>one shape, any provider"]
    DEV["Match the device"]
    DEC["Decrypt · decode"]
    RUL["Rules"]
    RTE["Routing · output structure<br/>per source → sink pair"]
    RTY["Delivery<br/>retry · dead letters"]
    IN --> NORM --> DEV --> DEC --> RUL --> RTE --> RTY
  end

  subgraph right["Your systems"]
    direction LR
    BILL["Billing"]
    DASH["Dashboard"]
  end

  UI["Web app — you configure it here"] -.-> center
  left -->|"callbacks"| IN
  RTY -->|"POST"| right
  BILL -.->|"downlink reply"| RUL

Reading it

• Everything enters through one door. Whichever network a device is on, the message arrives at an ingest endpoint and is authenticated there by that source's adapter.
• Normalisation is why the rest is simple. After that step, nothing downstream cares whether the message came from Sigfox or LoRaWAN. It is also what lets one sink receive from several networks and see one consistent shape.
• The shape is decided last, per pair. Two sinks fed by the same source can receive completely different bodies, because output structure is set on the edge, not on the source.
• Only one arrow goes backwards. A downlink is the sink's reply to the delivery it just received — see Respond with a downlink.

What is kept, and for how long

This is the part that surprises people, so it is worth being blunt:

The Center is a pipe, not an archive. If you need reading history, the system on the right is what stores it — which is why it is worth standing one up early.

Where you sit in it

You never touch the middle at runtime. You configure it — projects, devices, integrations, routing, rules — and the pipeline runs on that configuration for every message that arrives afterwards. A change takes effect on the next message, not retroactively; the one exception is a replay, which rebuilds the delivery with today's settings.

Next