Authentication Model
APIContext separates credential configuration from runtime tokens so that monitors can authenticate against protected APIs without embedding secrets in individual call definitions.
Authentication setups
An authentication setup is a reusable credential configuration attached to a project. It defines how APIContext obtains an access token: the grant type, endpoints, client credentials, scopes, and any extra parameters. You create one setup and reference it from any number of monitors in the same project.
Tokens
A token is the runtime credential that APIContext uses when executing a monitor. For OAuth flows, the platform handles the full token lifecycle: it exchanges the setup's credentials for an access token and caches it. It refreshes the token automatically when the token has a refresh token or uses the Client Credentials grant; otherwise a person signs in again. For simpler schemes (API key, Basic Auth), the token is the static credential itself.
Supported flows
| Flow | When to use |
|---|---|
| API Key | Static key passed as a header or query parameter |
| Basic Auth | Username/password encoded in the Authorization header |
| OAuth 2.0: Client Credentials | Server-to-server; no user context |
| OAuth 2.0: Authorization Code | User-delegated access; requires one-time browser consent |
| OAuth 2.0 + JWS/JWT | Signed assertions (e.g., Google service accounts) |
| OAuth 1.0a | Legacy APIs that require signed requests |
| Mutual TLS (mTLS) | Client certificate authentication |
| Custom | Arbitrary token-fetch logic via chained API calls |
Sharing restrictions
Authentication setups are scoped to a single project. Tokens cannot be shared across projects: this prevents accidental credential leakage when monitors are copied or moved.
See also
- Authentication settings guide: creating and configuring authentication setups
- OAuth fundamentals: detailed OAuth 2.0 walkthrough
- Device code auth: authenticating from headless environments