API checks started simple: give us a URL, a method, and an assertion or two, and we run it on a schedule from multiple regions and tell you when it breaks. That covers monitoring well, but not the part before it: building the request. So we grew API checks from a basic checker into a lightweight API client that also monitors. Here is what shipped and why.

Create API Check form with collection and environment selectors and tabs for headers, body, assertions, auth, secrets, and schedule — The API check builder: name the check, pick a collection and environment, then set the method, URL, and the request from one form.

The problem: a request is more than a URL#

A real API request carries tokens, runs against different environments, and rarely lives alone. Our old form ignored all three: tokens sat in headers as plain text, a check pointed at one hardcoded URL, and every check was an island even when ten of them hit the same service.

We fixed that with three features, in order: a secrets vault, environments, then collections. Each solved the problem the previous one exposed.

Secrets vault#

Store a token once and reference it anywhere in the request as {{KEY}}, in the URL, a header, or the body. The check stores the reference, not the raw value.

Secrets tab showing an API_TOKEN stored as a write-only value — The Secrets tab stores values write-only: reference them as {{KEY}}, replace or delete them, but never read them back.

The decision worth explaining: secrets are write-only. After you save one you see its name forever but never its value again. It is resolved only when the check runs, never sent back to your browser. The trade-off is real, you re-enter a secret to change it, but a secret you can read back is one that leaks the first time someone shares a screen.

Environments#

Next wall: targets. Environments are named sets of variables and secrets, the usual dev, staging, production split. A check references {{API_URL}} instead of a hardcoded host, so switching the active environment runs the same request against a different server. Validate in staging, switch, run again in production.

Collections#

Collections group related checks under a shared base URL and default headers. Put your /api/users checks in one collection, set the auth header once, and every check inside inherits it. Ungrouped checks still work, so it is opt-in, not a migration.

The one rule that ties it together: most specific wins#

A collection, an environment, and a check can all set the same value. When they disagree, the most specific one wins: the check beats the environment, and the environment beats the collection.

We kept it to that one rule, no deeper chains. You can always tell where a value came from, which matters more for a monitoring tool than extra flexibility.

What's next#

This arc built the client half: configure a request once, store its secrets, point it anywhere, organize it. The next phase leans into the half Postman and Insomnia do not, the monitoring layer, with deeper per-region latency and run history.

Inline 200 response showing 142 ms, passing assertions, and the JSON response body — Send runs the request once and shows status, latency, assertion results, and the response body before you save it as a scheduled check.

Building and sending a request is table stakes. Keeping it running on a schedule and telling you the moment it breaks is the point.

ObserveOne's API checks take the request you just built, add assertions on status, response time, and body, and run it from multiple regions on a schedule.

Building API Checks Into an API Client