The JSON Envelope Behind app.onepassapps.com: What /api, /api/health and a 404 Actually Answer

I work on OnePassApps, the team behind app.onepassapps.com, so this is a look at the API our own apps run on: what it says about itself, and exactly what it answers when you ask for something it does not have.

Every number below was measured with plain HTTPS from outside the browser on 4 November 2026 - no cookies, no session, no API key, signed out.

Two hosts, and the one that answers with JSON

The apps live on app.onepassapps.com. The JSON lives on api.onepassapps.com. They are not interchangeable.

Ask the app host for the API and you get the site's own HTML error page, not JSON:

GET https://app.onepassapps.com/api 404 content-type: text/html; charset=utf-8 13,953-14,320 bytes 

/api/health and /api/plans on that host answer the same way. The API host resolves to Cloudflare addresses (104.21.69.121, 172.67.208.4 and two IPv6 addresses), and every answer it gives carries Server: cloudflare.

GET /api: 104 bytes that name the service

GET https://api.onepassapps.com/api 200 application/json 104 bytes {"ok":true,"data":{"name":"ToolPass API","version":"0.6.0"},"meta":{"requestId":"req_1Q7VjUOGMPiO80WV"}} 

That is the whole response. Three top-level keys - ok, data, meta - and inside data just a name and a version.

The name it reports is ToolPass API and the version is 0.6.0. OnePassApps is the product name; ToolPass API is the service name our own backend reports about itself, and the health endpoint below reports the same family name (toolpass-api).

GET /api/health: the build hash, the image digest and the server clock

GET https://api.onepassapps.com/api/health 200 application/json 410 bytes 

data carries eight keys. Here they are, in the order the API returns them, with the values as measured on 4 November 2026:

Three details worth reading carefully.

The commit hash is the full 40-character SHA-1, and the release string is the version plus the same hash - so a release string and a commit always agree.

The imageDigest is the container image digest, sha256: plus 64 hex characters, which is a different identity from the commit.

now is the server's own clock, and it moves between calls: two requests to the same path returned two different requestId values and two different now values. The build timestamp, by contrast, is fixed for a given build.

One envelope, two shapes

Every response I got from this host used the same envelope. Success carries ok, data and meta; failure carries ok, error and meta. meta always carries one key, requestId, and the value is req_ followed by 16 characters.

Two back-to-back requests to GET /api produced different request IDs - req_jjV7LlfMAvgA_m-F and req_-wY9jEZhZ4u2hwU0 - so the ID is per-request, not per-route.

A route that does not exist: 404, 124 bytes, one message

GET https://api.onepassapps.com/api/does-not-exist 404 application/json 124 bytes {"ok":false,"error":{"code":"NOT_FOUND","message":"That route does not exist."},"meta":{"requestId":"req_Yw6YJ-jt-j4ILkS7"}} 

A deeper invented path, /api/nope/deeper/still, answered with the same code, the same message and the same body length - only the requestId differed. So the error text is fixed for every unknown route: there is no per-route detail to leak and no 404 HTML page mixed into the API. The message reads "That route does not exist."

Wrong method, same answer

POST https://api.onepassapps.com/api with a JSON body answers 404 with the same 124-byte NOT_FOUND envelope. POST /api/health answers the same way. A 405 would be the usual answer from an HTTP server; this one says the route does not exist.

OPTIONS /api answers 204 with an empty body.

The method matters more than that sentence suggests. An earlier session of this blog measured a POST to /api/signaldesk/audio, the NewsFlow audio route, answering 200 - and a GET on that same route answers the same 404 envelope as anything else. So the router matches on method and path together rather than answering 405 for a known path reached the wrong way.

Caching and CORS

Every response from the API host carries Cache-Control: private, no-store, max-age=0 - never cached by a browser or a shared cache.

None of those responses carried an Access-Control-Allow-Origin header, with or without an Origin header sent, and none carried a Vary: Origin. The app host is the opposite: its own 404 page answers Access-Control-Allow-Origin: *.

What I could not find

I probed a spread of paths on the API host without a session. Seven answered 200 with JSON:

Everything else I tried answered the same 124-byte NOT_FOUND envelope: /api/docs, /api/openapi.json, /api/routes, /api/sdks, /api/changelog, /api/version, /api/status, and GET requests to the two write routes /api/public-conversion and /api/signaldesk/audio.

So there is no published schema to read, no route index, and no version document: the API's own answer to "what can I call" is the same 404 it gives to anything unknown. The three endpoints worth knowing about are the root, which names the service, the health check, which names the build, and the fixed error envelope every other path shares.

If you want to see the products themselves rather than the API that serves them, the OnePassApps home page is where the nine apps live, and the app guides walk through them one by one.

One note to close on the disclosure: I work on OnePassApps, the team that runs this API, and every request above was a read against our own public endpoints. No file, text or form data was sent anywhere in this measurement.