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 can generate an API user for a tenant and store the result. Those show as Managed.
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 |
| 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.