The Maintenance Message Ships With the Switch Off: What /api/runtime Actually Sends

I work on OnePassApps, the team behind app.onepassapps.com, so this is our own API, and every value below was measured this morning from outside the browser, signed out, with no key, no cookie and no session.

Our API host answers a few public routes with no session. One of them, GET /api/runtime, is the route a client reads to decide whether to show a maintenance banner or an announcement to users. It is 471 bytes of JSON, and this is what it says.

The route

GET https://api.onepassapps.com/api/runtime

• HTTP 200
• content-type: application/json
• 471 bytes
• Cache-Control: private, no-store, max-age=0

The body, verbatim, on one line:

{"ok":true,"data":{"maintenance":{"enabled":false,"message":"SaaS Factory is temporarily in maintenance mode. Please try again shortly."},"announcement":{"enabled":false,"tone":"info","title":"Service update","message":"","linkLabel":"","linkHref":""},"publicSignupEnabled":true,"products":{"signaldesk":{"mode":"inherit","message":""},"movie-tracker":{"mode":"inherit","message":""}},"generatedAt":"2026-11-08T09:15:47.739Z"},"meta":{"requestId":"req_vcWenSdW3XTuYqYH"}}

The switch is off, and the message is still there

That is the part worth reading twice. maintenance.enabled is false. The service is up - the very request above answered 200. But the maintenance object still carries a full, readable sentence:

"SaaS Factory is temporarily in maintenance mode. Please try again shortly."

Nothing in the payload marks that string as a placeholder. It is not null, not empty, not a template. A client that renders maintenance.message without first checking maintenance.enabled would put a live-looking outage notice in front of users of a healthy service.

Two names in that one sentence are not the public brand. The message says "SaaS Factory", and the health route calls the service "toolpass-api", with a release string of toolpass@0.6.0 and an image version of 0.6.0. The site people actually visit is app.onepassapps.com. The public API still answers to its internal codename, and the string that is one flag away from being shown to users carries that name too.

The announcement block keeps a title and drops the message

The announcement block is the mirror image of the maintenance one. announcement.enabled is false, announcement.message is empty, and linkLabel and linkHref are empty. But tone is info and title is "Service update" - both populated.

So one block ships its text with the switch off, and the other ships its title with the switch off. From the payload alone a client cannot tell which of those defaults are meant to be seen by a user. It has to read enabled first, every time.

The request id is in the header and in the body

Three reads, about a second apart, gave three different generatedAt stamps and three different request ids:

The header and the body agreed on every read. generatedAt moved forward with the clock, and it is stamped in the same ISO format as the timestamps elsewhere in the API.

A POST to it is a 404, not a 405

POST https://api.onepassapps.com/api/runtime with an empty JSON body answers HTTP 404, with the same envelope every unknown path gets:

{"ok":false,"error":{"code":"NOT_FOUND","message":"That route does not exist."},"meta":{"requestId":"req_..."}}

There is no method-not-allowed answer in the API's vocabulary: the route exists for GET, and the API still says the route does not exist. On the app host the same path answers HTTP 404 with the site's own HTML error page - 13,953 bytes of text/html - not JSON.

The headers name more things than the body does

access-control-expose-headers on the same response lists X-Request-Id, X-RateLimit-Limit, X-RateLimit-Remaining, X-Concurrency-Limit, X-Concurrency-Remaining, Retry-After, X-ToolPass-Credits-Changed and X-ToolPass-Impersonating.

The last two are the interesting ones: credit accounting and impersonation controls, named after the internal codename, and declared as headers a browser is allowed to read. The response also carries x-concurrency-limit: 64 and x-concurrency-remaining: 63.

What I did not do

I sent no Origin header, asked for nothing with a key, and did not try to make the maintenance block flip - there is no public write route for it. I read one public route three times and the health route once, from outside the browser, on 8 November 2026. Maintenance and announcement blocks change with operations, so read the live route before you rely on either of them.

The earlier post on the same API host, for the envelope and the health route: https://dev.to/onepassapps/the-json-envelope-behind-apponepassappscom-what-api-apihealth-and-a-404-actually-answer-ni0

The site is at https://app.onepassapps.com/?utm_source=devto&utm_medium=post&utm_campaign=runtime-maintenance-legacy&utm_content=runtime-link and the app guides are at https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=runtime-maintenance-legacy&utm_content=guides-link

I work on OnePassApps, so this is our own service and our own copy, measured today rather than described from memory.