Concepts

Messages & deliveries

What is stored, for how long, and what "at least once" costs you.

Two words that look interchangeable and are not.

  • A message is one payload that arrived from a source.
  • A delivery is one attempt to hand that message to one sink.

One message going to three sinks is one message and three deliveries, each succeeding or failing independently. A sink being down does not affect the other two.

Messages are transient

This is the single most important thing to know about storage:

The Center is not your archive
A message is held only until its deliveries are done, then discarded. There is no message history to browse and no way to re-read yesterday's payloads. Whatever your sink stores is the record.

That is a deliberate design choice — the Center is a pipe, not a database — but it has a practical consequence: stand up a sink that stores things before you need the history. A sink you add tomorrow starts from tomorrow.

What does persist is counts. Analytics keeps received / delivered / failed totals per project and integration, so you can see volume and failure trends long after the payloads themselves are gone.

Delivery: at least once

The Center guarantees each message reaches a sink at least once. Not exactly once — that guarantee is not achievable across a network without cooperation from the receiver.

In practice, your sink will occasionally see the same message twice: it accepted the message, but its acknowledgement was lost, so the Center retried.

Handling repeats

Every delivered message carries an idempotencyKey — stable for a given inbound message, derived from the provider, the device and the provider's own message id:

SIGFOX:1A2B3C:DATA_BIDIR:18

Store it. Ignore keys you have already processed. That is the whole protocol.

The exception is the raw provider frame output shape, which carries only the provider's own fields and therefore no key. Sinks on that shape must de-duplicate on provider fields instead — for Sigfox, device plus sequence number. It is a real trade-off, and worth choosing deliberately rather than by accident.

Retries and dead letters

A failed delivery is retried with growing backoff. After eight failed attempts it is dead-lettered: parked, with its attempt count, in the Dead letters page.

Dead letters are not lost — they are waiting. Fix the cause, then Replay.

Replay re-applies the current configuration
A replayed delivery is rebuilt with today's output structure, not the one in force when it first failed. So fixing a broken transform and replaying works — the retry sends the corrected shape.

What counts as a failure

The sink's HTTP response decides. A 2xx is success; anything else — or a timeout, or a refused connection — is a failed attempt and will be retried.

This means a sink that returns 200 while quietly discarding the body looks perfectly healthy from here. If deliveries are green but data is missing downstream, suspect the receiver before the Center.

Next

When delivery fails
Diagnosing and replaying, and reading Analytics.
What the sink receives
The five shapes, and which one keeps your de-duplication key.
Copyright © 2026