Connect a source
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.
| Endpoint | Pins | Use when |
|---|---|---|
…/ingest/source/{sk_key} | this exact source | Normal. No guessing involved. |
…/ingest/project/{pk_key} | the project | One address for several sources; the Center infers which. |
…/ingest/device/{dk_key} | one device | The sender speaks for a single device and omits its id. |
…/webhooks/{integrationId} | this exact source | The original form; the keyed URLs are usually nicer. |
Copy the URL from the integration list, or from Flow → Endpoint & schema.
Pretty links
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. For a The Things Stack source the Center writes it onto the LNS webhook itself when it links the source — nothing to copy across.
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.
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.
The source wizard's Device type step works either way round: create a device type under the project's group (or reuse one by name), or use an existing one picked from the Backend — shown with its group breadcrumb, since device-type names repeat across groups. Using an existing type creates nothing on Sigfox; the source is pointed at it and the callbacks register there, with the type's own downlink mode.
The Things Stack step
A The Things Stack source has the counterpart: a The Things Stack step in the source wizard (Flow → Add source, or Integrations → New integration). Leave Link to The Things Stack on and the review step links the source as it is created — the project's application on Una's LNS (Create a new application, or Use an existing application picked by owner and name), a webhook from that application into this source's endpoint, and the application key the Center uses to register devices and push downlinks. The link runs as a task like every other step, and can be retried.
Turn it off to create the source without touching the LNS. You can link later from the same step, or from the project page's The Things Stack panel. On Flow the source card carries an LNS badge — Linked to LNS application … or Not linked to the LNS yet — open to link — that opens the step. A project has one LNS application and one webhook; linking through a second source moves the webhook there (Re-link).
Nothing is pasted into the LNS console: the application, the webhook, its secret and the key are all written by the Center, and once the link exists LoRaWAN devices register themselves as you create them.
Send a test uplink, then check Analytics. If Received moved, the connection
is live.