---
title: "Let your users sign in from the chat | Busymate AI"
description: "Give customers a sign-in card inside the chat, using the accounts you already run: what they get, how to switch it on, and what stays with you."
last_updated: "2026-09-15T11:05:28+03:00"
---
# Let your users sign in from the chat | Busymate AI

Source: https://busymate.ai/ro/docs/guides/in-chat-sign-in
Last modified: 2026-09-15T11:05:28+03:00
Busymate AI lets a customer sign in without leaving the conversation, with the account they already have with you. A sign-in card opens in the thread the moment a question needs their account, the credentials go to your own site, and the same conversation carries on signed in. No platform account is created for them, and nothing about their login reaches the assistant.

Diagram: A question needs an account; a sign-in card opens in the thread; the same conversation continues signed in, vouched for by a short-lived proof your site signs

## Yours end to end

- **Sign-in and sign-up are your product's.** The card, the login page and the account creation flow are the ones you already run. Busymate AI never stores a password or creates a customer account; it only verifies the short-lived proof your site signs afterwards.
- **What the assistant learns** is an unchanging customer id and, if you allow it, a few display claims such as a name or plan. Everything else stays behind your API and is fetched per request.

## 1. Register your accounts as the identity provider

Open [Console → End-user identity](https://busymate.ai/console/identity), or call `upsert_tenant_identity_provider`. Enter your issuer, JWKS URL, audience, workspace and subject claims, the maximum proof age and the mint endpoint described in [Recognize signed-in customers](https://busymate.ai/ro/docs/guides/identified-visitors). Add your **customer login URL** as well — the hosted chat and the silent connect in step 4 use it. Save, press **Test identified launch**, then publish.

The check is standards-only: an ES256 (or RS256) JWT verified against your published JWKS for issuer, audience, subject, workspace claim, the nonce the launch asked for, a one-time `jti`, age and expiry. A failed check names the claim, never the value.

{{snippet:identity-endpoint}}

## 2. Put a sign-in card in the chat

On any page where the chat is embedded, register a page tool called `sign_in` that returns a form card:

{{snippet:page-tools-sign-in}}

The fields are yours: email and password, an emailed code, or a single button that starts the sign-in you already offer. A `password` field is accepted only on a card that submits back into your own page, so the value goes from the input to your `execute` and nowhere else, and the settled card shows `•••••`. When your tool answers `{ signedIn: true }`, the widget asks your page for a fresh proof through `getIdentity` and re-mints the session in place — same thread, now identified, the earlier question answered.

## 3. Know what happens where

| Where the chat runs | What the Sign in control does |
|---|---|
| Embedded on your page, `sign_in` registered | The card opens in the thread. Nothing leaves the page. |
| Embedded on your page, no `sign_in` tool | Your page navigates to your login URL with `return_to` and a one-time `bmai_nonce`, then returns and hands the proof to the widget. |
| Your hosted chat address | The same redirect: to your login URL and back to the exact `return_to`, proof in the URL fragment. |
| Your iOS or Android app | The app receives the request over the native bridge and runs its own login. |

A credential is never typed into a frame that is not yours. The card submits into your page, and a redirect always happens at the top level, on your origin.

## 4. Connect a customer who is already signed in

If the customer already has a session with your product, the chat can inherit it without showing a form. On the hosted address and in the embed, the widget opens your login URL once per tab in a hidden frame with `bmai_prompt=none` — the `prompt=none` meaning every identity stack knows: answer only from an existing session, never render a form. Your login redirects straight back with the proof in the fragment, and the session is re-minted signed in. It works when:

- your customer login URL is published on the current revision;
- your login honours `bmai_prompt=none` — an existing session answers, a signed-out visitor is sent back with nothing;
- the probe finishes within three seconds; it runs once per tab and fails silently, so the visitor simply stays a guest with the Sign in control still there.

This can only add an identity. It never blocks the chat, never redirects the visible page, never traps anyone in a login form, and is not attempted inside a native app, which passes identity over its own bridge.

## 5. Choose what a signed-in customer can do

Each connected tool carries an access level. **Public** tools answer anyone. **Identified** tools run only after the proof was verified and receive your customer id. **Delegated** tools also need *Allow delegated customer account access* on the provider and act through a signed actor token or a per-customer consent. Set the levels in [Connect your MCP server as assistant tools](https://busymate.ai/ro/docs/guides/connect-mcp-server). The sites at [demo.busymate.ai](https://demo.busymate.ai) each include a demo customer to sign in as: the same card, then orders, bookings or balances for that one person.

## Verify

1. Signed out, ask something that needs an account: the card appears in the thread, not a link away.
2. Sign in from the card: the same conversation continues and your earlier question is answered.
3. Open the tool call's details: the password shows as `•••••`.
4. Sign in to your product in another tab, then open the hosted chat: it is signed in with no form shown.
5. A second customer cannot see the first one's history or account.

<!-- qa:start -->
### Do my customers need an account with Busymate AI?
No. They sign in to your product. Your site signs a short-lived proof, the assistant verifies it against your public key, and the subject is your own customer id.

### Where do sign-ups happen?
In your product, the way they do today. The card or the login page you return is yours, so a new customer creates an account with you and comes back to the chat signed in.

### Can the assistant read the password?
No. A password field is accepted only on a card that submits into your own page. The value never enters a tool argument, the transcript or a log.

### What if the silent connect is not answered?
Nothing visible happens. The probe expires after three seconds, the visitor stays a guest and the Sign in control is still there.
<!-- qa:end -->

## Next

- **[Recognize signed-in customers](https://busymate.ai/ro/docs/guides/identified-visitors)** — the keys, the claims and the mint endpoint.
- **[Forms and sign-in inside the chat](https://busymate.ai/ro/docs/guides/form-cards)** — the card contract in detail.
- **[Connect your MCP server as assistant tools](https://busymate.ai/ro/docs/guides/connect-mcp-server)** — the identified tools it unlocks.