Provider credentials
To call a provider's API — read Sigfox device types, register callbacks, provision a device — the Center needs credentials for that provider. They are stored once per tenant and referenced by the integrations that need them.
Where: IAM → Credentials.
Why they are separate from integrations
Because the alternative is worse. Credentials stored on each integration means the same password in five places, and a rotation you will get wrong at least once.
Here, integrations reference a credential. Change the password in one place and everything using it follows.
Secrets are one-way
A secret is encrypted at rest and never shown again after you save it. The list tells you whether one is Configured or Not set, and nothing more.
When you edit a credential, leave the secret fields blank to keep the stored value. You only type a secret to replace it. That is what lets you fix a label or change status without knowing the password.
Scopes
A credential is visible to one of three levels:
The most specific one wins: an integration's explicitly chosen credential first, then a project credential, then the tenant default.
A project credential is the right tool when one deployment runs against a separate provider account — a pilot on a test account, or a customer who insists on their own contract. Everything else stays on the tenant default.
Managed credentials
Some credentials are created by the Center rather than by you — Sigfox
provisioning generates an API user for a tenant and stores it as sigfox-auto;
The Things Stack provisioning mints the organization's una-center key and
stores it as tts-auto. Those show as Managed.
For The Things Stack this is why only the platform (or reseller) tenant needs a credential of its own — a personal or organization API key with organization and application rights. Every tenant beneath it is provisioned with that key and gets its own managed one; nobody pastes a key per tenant.
Treat them as the Center's own. Editing or deleting one breaks the provisioning that created it.
Rotating
- Get a new secret from the provider.
- Edit the credential and enter it, replacing the old value.
- Test an integration that uses it.
Nothing else needs touching — every integration referencing the credential picks up the new value.
If you rotate on the provider side first, expect failures until step 2. Do it in one sitting rather than leaving it half done.
When a credential is wrong
Symptoms tend to be specific:
| Symptom | Likely |
|---|---|
| Sink deliveries fail with 401/403 | Sink's own auth, not a provider credential |
| Device type list is empty in the picker | No Sigfox credential, or provider reads are gated off |
| Application or organization list is empty in the picker | No The Things Stack credential on the tenant or above it, reads gated off, or a key minted on a single application — use a personal or organization key |
| Provisioning plan fails to run | Missing or wrong credential for that tenant |
| Coverage map is blank | Same — no credential, or reads gated |
The sink case is the one to keep straight: sink authentication is configured on the integration itself. Provider credentials are for calling a provider's management API, not for delivering data.