Authentication & Secrets

Attach Bearer, Basic, API key, or OAuth2 client-credentials auth to an ObserveOne API Check, and store credentials in the per-check secrets vault so values never live in the request or an export.

Most real APIs need a credential. ObserveOne keeps credentials out of the request itself: you store them once in a per-check secrets vault, reference them with {{KEY}}, and pick an auth type that assembles the right header server-side. The values never appear in the saved check, in send-now output, or in an export.

The secrets vault#

Each saved check has its own vault on the Secrets tab. It is write-only: you add keys and values, but the dashboard only ever reads back the key names, never the stored values.

  1. Save the check first. The vault is keyed to the saved check, so the Secrets tab prompts you to save before you can add anything.
  2. Add a secret as a key/value row, for example TOKEN with the token string as its value.
  3. Reference it anywhere in the request as {{TOKEN}}, in the URL, a header, or the body.
The Secrets tab showing a stored API_TOKEN key with its value masked as type-to-replace, and an empty key/value row to add another.
The Secrets tab: stored keys are listed, values are masked, and you reference them as {{KEY}}.

At send time and on every scheduled run, ObserveOne resolves {{KEY}} references server-side and strips the raw values before the request leaves the platform. Workers never receive the secret values.

To update a secret, write a new value for the key. To delete one, save it with an empty value.

The Auth tab#

Rather than hand-building an Authorization header, open the Auth tab and pick a type. Each type takes vault references (not raw values) and serializes the correct header for you:

  • None: no auth header is added.
  • Bearer token: takes a token reference, sends Authorization: Bearer <token>.
  • Basic auth: takes a username and password reference, sends the encoded Authorization: Basic header.
  • API key: takes a header name and a key reference, sends the key under the header you name.
  • OAuth2 (client credentials): see below.
The Auth tab with Bearer token selected and the token field set to a vault reference.
The Auth tab assembles the header for you. Each type takes vault references, not raw values.

The auth config stores only references and header names, never values. An explicit Authorization header on the Headers tab takes precedence; the Auth tab only fills the gap.

OAuth2 client credentials#

The OAuth2 (client credentials) type is for machine-to-machine APIs that hand out short-lived access tokens. A static Bearer token expires (often within the hour), which makes it useless for an unattended, scheduled check. With client credentials, ObserveOne mints and refreshes the token for you.

Provide:

  • Token URL: the https:// token endpoint.
  • Client ID and Client secret: as vault references.
  • Scopes (optional) and Audience (optional).
The Auth tab with OAuth2 client credentials selected, showing token URL, client ID and secret references, scopes, and an optional audience.
OAuth2 client credentials: the server mints and refreshes the token from your vaulted client ID and secret.

On each run the server fetches a token, caches it for its lifetime, and refreshes it when it expires. You never touch a token by hand, which is what makes a scheduled check against an OAuth2-protected API viable.

The token endpoint is fetched from ObserveOne's servers, so it must be a public https:// URL and is validated against the same protections as every other outbound request.

Next steps#

Was this page helpful?