Do I need to know which layer is broken before I run the checker?

No. Point it at your host and it names the layer itself — a page, a bridge, or your signing endpoint — instead of asking you to guess between them.

What if the CLI cannot reach my identity endpoint at all?

It reports that cell as could-not-observe, not as a pass. An unreachable endpoint is never counted as working; fix reachability, then re-run.

The browser check and the CLI disagree — which one is right?

Neither overrides the other. The browser proves the lifecycle a real page produces; the CLI proves what a browser cannot see, your endpoint's own response. A real integration passes both.

Does either check keep or send on a real token?

No. Both record shapes — whether two mints differ, whether a claim is present — never the token, the nonce, or a claim's value.

My symptom is not on this page — where do I look next?

Start at Recognize signed-in customers's four obligations; nearly every guest-when-signed-in report traces back to one of them.

Guides

Fix a signed-in customer who shows as a guest

Match your exact symptom to its cause and the conformance-checker cell that proves it, including the WebView-loads-your-own-page case.

Français

Sur cette page

Busymate AI shows almost the same symptom for every identity mistake: a customer you know is signed in shows up in the chat as a guest. This page starts from what you see, names the layer that actually broke, and identifies the exact cell in the conformance checker that will confirm the fix — instead of guessing across your website, your app and your backend at once.

1. Match your symptom to a cause

You see	The likely cause	What proves it
Signed in on the site, the chat still offers Sign in	Your bridge answered nothing on the first ask — often because it registered after the page had already loaded and asked once	The Identity check's first-launch cell
The first message is identified, every one after is a guest	Your app's WebView loads your OWN page rather than the assistant directly, and that page only answers the very first ask	See "Your app's WebView loads your own page" below
The customer signs out; the chat still shows their name	The sign-out call was never wired, so the previous session survives until the view is destroyed	The checker's logout cell
It works on one native platform, fails on the other	The two bridges answer at the wire level differently — one can deliver a JSON string where the other delivers a real object, and a string with no `type` field is silently dropped	Run the checker against each platform on its own
A launch that worked a moment ago is refused as expired, or as not-yet-valid	Your server's clock has drifted past the verifier's tolerance	The CLI's clock-skew cell reads your `iat` against server time
A sign-in works once, then every later ask is refused	A launch proof is single-use; something cached the pair and answered a second ask with it	The checker's token-expiry cell mints twice and expects two different answers

2. When your app's WebView loads a page you built

The shape that hides an otherwise-correct integration: your app's WebView does not load the assistant directly — it loads a page you built, and that page embeds the assistant. The assistant then asks its parent, which is your own page, and your page has no session of its own; the customer is signed in natively, one layer further out. A token on the launch URL answers the first ask and nothing after it, so a resume, a reconnect, an expiry and a restart each quietly fall back to no session there.

The fix has two halves, and both are required: keep the native bridge from Recognize signed-in customers installed in the app, and give your own page the small asker that forwards later questions to it — https://busymate.ai/sdk/v1/kit/web/native-identity.js. Installing only the bridge leaves it correct and unreachable.

3. Read the exact missing step, do not guess it

Two checks, one set of rules. The Identity check runs the lifecycle half against a page of yours and grades what comes back: a token that was not fresh, a sign-out that changed nothing, a bridge that answered late. The CLI — node v2/scripts/identity-conformance.mjs --host <your-host> --json — runs the half a browser cannot reach: JWKS reachability, key and algorithm agreement, claim shape, clock skew, and the CORS rules of your own endpoint. Each prints pass, fail, or could-not-observe per cell, together with the step it is missing, rather than a bare "identity broken".

Verify

Run the browser check and the CLI against the same host; note any cell that fails or comes back unobserved.
Fix the named step, not the whole integration — one obligation from Recognize signed-in customers is usually the entire gap.
Re-run both. A clean pass on every cell, not a green first screen, is what "fixed" means here.
In Console → Identity health, the same picture appears per platform — the fastest way to tell whether the fix reached every customer, not only the one browser you tested from.

Recognize signed-in customers — the contract every platform below implements.
Sign identity tokens from your backend — the endpoint every check above talks to.
In-app AI support for iOS and Android — the native bridge this page's WebView case depends on.

Questions

Do I need to know which layer is broken before I run the checker?: No. Point it at your host and it names the layer itself — a page, a bridge, or your signing endpoint — instead of asking you to guess between them.
What if the CLI cannot reach my identity endpoint at all?: It reports that cell as could-not-observe, not as a pass. An unreachable endpoint is never counted as working; fix reachability, then re-run.
The browser check and the CLI disagree — which one is right?: Neither overrides the other. The browser proves the lifecycle a real page produces; the CLI proves what a browser cannot see, your endpoint's own response. A real integration passes both.
Does either check keep or send on a real token?: No. Both record shapes — whether two mints differ, whether a claim is present — never the token, the nonce, or a claim's value.
My symptom is not on this page — where do I look next?: Start at Recognize signed-in customers's four obligations; nearly every guest-when-signed-in report traces back to one of them.