Credential types
All four credential types use the HTTP header Authorization: Bearer <credential>, but they identify different callers and are not interchangeable.
| Credential | How to obtain it | Used for | Where to keep it |
|---|---|---|---|
| Console session | Sign in to Notify Console | /console/api/* | Console session |
| Application API key | Create a credential in Tenant Console or the authorized Admin API | Application routes under /v1/* | Your backend secret store |
| User token | Your backend calls POST /v1/user-tokens | /v1/user/* | Your authenticated frontend session |
| Platform administrator key | Server bootstrap configuration | /admin/v1/* | Platform operations secret store |
Does Bearer mean I have to log in?
No. Bearer describes how a credential is sent over HTTP. For application endpoints, the value is an application API key. For user endpoints, it is the signed user token. Logging in to Console produces a Console session, not an application API key.
Can Swagger create these credentials?
Swagger can call the documented API endpoints when you already have permission:
- An authorized platform operator can create application credentials through the Admin API.
- An application key with
users:token_issuecan request a user token. - Console login and Console administration are separate from the public integration API.
- There is no public endpoint that hands out a platform administrator key.
The Swagger Authorize dialog only stores a credential for requests. It does not create a credential.
Scope versus identity
The key identifies the application. Its scopes describe allowed operations. An account identifier selects a customer account inside that application. These are separate checks; see Scopes and permissions.