The 90-Day Cookie: What the One Cookie Our API Sets Actually Says, and the Sibling Route That Sets Nothing

I work on OnePassApps, so this is our own site, measured today, signed out, with no cookies sent.

Three earlier posts of ours already cover the shape of this. One measured the app host and found zero Set-Cookie headers on all 56 pages of our sitemap. Another swept both hosts and found that exactly one response of 88 sets a cookie at all - /api/guest-data/signaldesk - and named it toolpass_signaldesk_guest. A third explained that the two cookies you see in a signed-out browser are written by the sign-in script, not by the document response. Those are the canonical write-ups and this post does not repeat them.

What had not been measured is the cookie itself: what its attributes say, how long it lives, whether the value is stable, and whether the route next to it behaves the same way.

The one cookie, in full

Raw header line, from a signed-out GET https://api.onepassapps.com/api/guest-data/signaldesk over plain HTTPS:

Set-Cookie: toolpass_signaldesk_guest=<value>; Max-Age=7776000; Path=/api; HttpOnly; Secure; SameSite=Lax 

• Max-Age=7776000 - 7776000 seconds is exactly 90 days.
• Path=/api - the browser sends it back to our API host under /api, and never to the app host.
• HttpOnly - page JavaScript cannot read it.
• Secure - only over HTTPS.
• SameSite=Lax - not attached to cross-site subresource requests.

None of these five attributes has appeared in a post of ours before. That is the gap this fills.

The value is not stable

I fetched that same route four times inside one minute and recorded four different values. The value is a UUID and it changes on every response, so the cookie is not a remembered identifier - the server issues a fresh one each time.

The browser agrees about the lifetime, and to within a few seconds. I deleted the cookie, loaded the NewsFlow page, and read the expiry the browser stored: 7,775,992 seconds out. The header asks for 7,776,000. The eight-second gap is the distance between the server stamping the expiry and the response landing in the browser.

The sibling route sets nothing

The guest-data endpoint answers for two valid app ids, and both of them answer 200:

So the cookie is not a property of the endpoint. It is a property of that one route. Two URLs one directory apart, same method, same host, same status - and only one of them hands the browser something to carry. The extra header line on the first row is the Set-Cookie itself.

How I pinned it to one page

Reading headers tells you a route sets a cookie. It does not tell you which page in the app causes that request, so I checked in a real browser instead:

1. Deleted toolpass_signaldesk_guest, then loaded the home page. It did not come back.
2. Loaded the NewsFlow page. It came back, with a fresh expiry.
3. Loaded the Movie Tracker page instead. It did not come back.

Step 2 is the one that matters, because NewsFlow's public slug is newsflow while the API knows that app as signaldesk. Loading /apps/newsflow is what triggers the call to /api/guest-data/signaldesk. The home page also calls the API - runtime, feature flags, public conversion, auth config, voting, plans, favourite counts - and not one of those responses carries a Set-Cookie line.

The auth host's cookies, for contrast

clerk.onepassapps.com is the one host of ours that answers with cookies on every request. Across the nine requests I made to it back to back, every answer carried exactly two Set-Cookie lines, all of them HttpOnly, SameSite=None, Secure, and scoped Path=/ to that host: Cloudflare's bot-management pair, __cf_bm (also Partitioned, with an Expires about 30 minutes out) and _cfuvid (a session cookie).

Two requests to the same host earlier in this run answered with a different pair: the auth service's own session cookies, two long random names, one of them Partitioned and carrying an Expires about 30 minutes out. The auth host's cookie set changes with what the edge and the auth service decide to send. Ours does not change at all.

What I did not do

• Signed out throughout. I did not exercise an authenticated session, so I make no claim about what a signed-in request sets.
• GET only. I did not test whether POST, PUT or DELETE responses carry Set-Cookie lines.
• I did not decode, replay or forge the guest cookie, and I did not try to satisfy Cloudflare's bot-management cookie.
• The two 400 answers are the API refusing an app id it does not know. I did not chase which ids it accepts.
• The browser work was one browser, one signed-out session, one build on one day (11 November 2026).

If you want to look

The sitemap behind the 56 pages is at https://app.onepassapps.com/sitemap.xml. The apps themselves are at https://app.onepassapps.com/?utm_source=devto&utm_medium=post&utm_campaign=cookie-attributes&utm_content=app-link and the written guides are at https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=cookie-attributes&utm_content=guides-link

I write here as the OnePassApps team. Corrections are better than praise.