The pipeline

Every message takes the same path. Knowing the order is what makes the app predictable — and it tells you where to look when something comes out wrong.

The Flow page draws this: sources on the left, the Center in the middle, sinks on the right. The Center node shows its three processing steps — Decrypt, Decode, Build structure — and the buttons on it open exactly the settings described below.

The stages

1. Arrival

The network POSTs to one of your ingest endpoints. The source's adapter checks the payload is genuine — a shared secret, a signature, whatever that provider uses.

Where to configure: Flow → Endpoint & schema, or the integration itself. See Connect a source.

2. Normalisation

A Sigfox callback and a ChirpStack uplink look nothing alike on the wire. Here they become one internal shape, so everything downstream works the same regardless of provider.

This is also where the payload's device identifier is resolved to a device you created. An identifier the Center does not recognise cannot be matched to a profile or a decoder.

Where to configure: nothing to configure — but the device must exist, with the right identifier. See Add your devices.

3. Decrypt and decode

If the device's profile defines encryption, the payload is decrypted. Then the profile's decoder turns the bytes into named readings.

The result splits into two groups that stay separate for the rest of the trip: telemetry (the readings) and meta (signal strength, sequence numbers). They are kept apart deliberately — merged, a key appearing in both would silently lose one of them.

Where to configure: Flow → Decoders, or Profiles. See Decode the payload.

4. Rules

Your ordered rules run top-down. The first one whose condition matches decides what happens: deliver it (optionally to specific sinks), drop it, answer the device with a downlink, or hold it to be merged with a message still to come.

With no rules, every message passes straight through.

Where to configure: Flow → Rules. See Filter with rules.

5. Fan-out

The message is matched to its destinations. If you have wired explicit routes, it goes to the sinks that source is connected to. If you have not, it goes to every active sink in the project.

Where to configure: Flow → Routing. See Route to a sink.

6. Build structure

Each destination gets its own shape, applied per source → sink pair — full envelope, raw provider frame, decoded readings only, or a body you compose field by field.

Where to configure: Flow → Routing, on the pair. See Choose what the sink receives.

7. Delivery

The shaped body is POSTed to the sink. Failures retry with growing backoff. After eight failed attempts the delivery is dead-lettered, where it waits for you to fix the cause and replay it.

Where to look: Dead letters, and Analytics for the counts. See When delivery fails.

At least once, not exactly once

The Center guarantees a message is delivered at least once. A sink that accepts a message but whose acknowledgement is lost will see that message again.

Every delivered message carries an idempotencyKey — stable per inbound message — and that is how your side recognises a repeat. Store it and ignore keys you have already processed.

The one shape where you do not get it for free is the raw provider frame, which by definition carries only the provider's own fields. Such a sink must de-duplicate on those instead — for Sigfox, device plus sequence number.

Reading the pipeline backwards

When output is wrong, this order tells you where to look: