Guides

Connect a source

Give a device network somewhere to post, and make sure only it can.

A source is where messages come from. Connecting one means creating the integration, then pointing the network at the endpoint it produces.

Create the integration

Integrations → New integration, direction Source (left), and pick the provider. Attach a credential if the provider needs one to be called back — see Provider credentials.

Choose an endpoint

The Center gives you more than one address, and they differ in what they pin down. All of them accept the same payloads.

EndpointPinsUse when
…/ingest/source/{sk_key}this exact sourceNormal. No guessing involved.
…/ingest/project/{pk_key}the projectOne address for several sources; the Center infers which.
…/ingest/device/{dk_key}one deviceThe sender speaks for a single device and omits its id.
…/webhooks/{integrationId}this exact sourceThe original form; the keyed URLs are usually nicer.

Copy the URL from the integration list, or from Flow → Endpoint & schema.

Prefer the source key
The project endpoint has to work out which source a payload came from — the single active source, or the one whose adapter accepts the payload. That is convenient with one source and ambiguous with several. Pinning the source removes the question.

An opaque sk_7f3a… key is fine for a machine and awkward in an email. Set an ingest slug and you get a short link instead:

https://your-center/i/baylan-hatay-proje1     ← a project slug
https://your-center/i/s/sigfox-hatay-bidir    ← a source slug

Slugs are lowercase letters, digits and hyphens, at least six characters. Project and source slugs are independent namespaces, so the same word can be both.

Slugs are guessable by design — that is the point of them. They are off by default, and they change nothing about security: the adapter still authenticates every payload. The key-based URL keeps working alongside the slug.

Where: Flow → Endpoint & schema, or the integration.

Lock it down

The shared secret

Most providers can send a secret with each callback, which the adapter checks. Configure it on the integration, and configure the matching value on the network's callback. This is the actual authentication.

Required headers

A source can require specific headers on every inbound request. Mark a header required and requests without it are rejected before anything else happens.

Useful for a second factor in front of the payload check, or to satisfy a gateway that needs a routing header anyway. Non-required headers are display only — they are shown alongside the endpoint so whoever wires up the sender knows what to send.

Required headers apply to HTTP only
Sources on MQTT, TCP or CoAP have no HTTP headers to check, so the requirement is skipped there. Do not rely on it as your only control for those transports.

Rotating a key

Rotate issues a new ingest key and invalidates the old one immediately. There is no grace period, so any backend still posting to the previous URL starts failing at once.

Rotate when a key has been shared too widely or has leaked. Plan it: update every sender in the same window.

A configured slug survives rotation — the slug URL keeps working, because it resolves to the integration rather than to the key.

Describe the payload

Endpoint & schema also lets you record the payload shape you expect. It is published alongside the endpoint so whoever configures the sender can see what to send.

It is documentation, not validation — the Center does not reject messages for disagreeing with it.

Point the network at it

Finally, configure the callback on the provider side. For Sigfox that is on the device type's callbacks; the Center can also register those for you.

Send a test uplink, then check Analytics. If Received moved, the connection is live.

Next

Add your devices
So arriving messages match something.
Decode the payload
Turn the bytes into named readings.
Copyright © 2026