Collections & Environments

Group ObserveOne API Checks under a shared base URL and default headers with collections, and swap variable and secret sets per stage with environments.

Collections and environments remove repetition. A collection groups checks that share a base URL and default headers. An environment is a named set of variables and secrets you can switch a check between, for example staging versus production. They layer cleanly: the check always wins over what it inherits.

Collections#

A collection holds a set of checks plus shared defaults:

  • A base URL, so member checks can use a relative path like /users that joins the base at run time.
  • Default headers applied to every member.

Create a collection from the API Checks area, then assign checks to it with the collection picker on the request line. To manage members and defaults, use the collection's own view.

The collection picker open on the check form, listing the available collections to assign the check to.
Assign a check to a collection from the picker on the request line.

Resolution order when a check runs in a collection:

  1. The collection base URL joins the check's relative path (an absolute URL on the check is used as-is).
  2. Collection default headers apply, then the check's own headers, which override a collision.

A relative URL requires a collection. Without one there is no base to join, so the check needs an absolute https:// URL.

Environments#

An environment is a named bundle of variables and masked secrets that you layer under a check. Switch the active environment with the environment picker on the request line, and the same {{KEY}} references resolve to that environment's values.

The environment picker open on the check form, listing the staging and production environments to switch between.
Switch the active environment from the request line. The same references resolve to that stage's values.

This points one check at different stages without editing it: {{BASE_URL}} resolves to the staging value under Staging and the production value under Production. Values set directly on the check still win.

Environments are owner-scoped (you or your team), the same as checks, and their secrets are masked on read just like the per-check vault.

The environment binding persists on the check, so it applies to manual runs and scheduled runs the same way it applies to send-now, not just the one-off preview. A request-level environment_id (for example, from an ad hoc run against a different stage) still overrides the check's saved binding for that run only.

How they combine#

A check resolves its request bottom-up: environment values and collection defaults form the base, then the check's own URL, headers, body, and secrets are applied on top, then the Auth tab fills any auth header you did not set by hand. The most specific layer always wins.

Next steps#

Was this page helpful?