Client accounts
A client account belongs to one Supabase Auth subject. A Telegram client's account starts incomplete, without a phone, and becomes ready when a bot-verified contact arrives. It keeps the verified phone separate from the name and preferred phone suggested for future bookings. Changing those suggestions does not verify a new phone or rewrite the contact snapshot on an existing appointment. A later Telegram launch also leaves a manually edited account name intact. See Telegram client authentication.
Website client accounts
A website visitor who signed in with a phone one-time code can create a client
account with POST /client/account. The request carries no body. The API reads
the caller's own Supabase Auth user and uses its confirmed phone and
confirmation time as the account's verified contact, so the account is ready
immediately.
| Response | When |
|---|---|
200 {"status":"ready","botWriteAllowed":false} | The account was created, or the subject's existing account was reused |
401 unauthorized | No valid Supabase access token |
403 phone_required | Supabase Auth has no confirmed phone for this subject, such as a Telegram-created or email user |
503 unavailable | Supabase Auth could not be reached. Nothing was written, and the request can be retried |
Repeating the request with the same confirmed phone keeps the original verification time. If the subject's confirmed phone changed in Supabase Auth, the account's verified contact becomes the new phone.
A phone never selects or merges an account. A website account and a Telegram account are separate even when they hold the same verified phone, and neither can see the other's appointments or claims. A website account has no Telegram identity, so it has no bot write permission and receives no Telegram notifications.
GET /client/profile returns telegramUserId: null for a website account,
and displayName: null until the client sets a name.
Appointment ownership
The account lists only appointments claimed by that client, including confirmed and cancelled history. A successful Telegram booking creates its claim as part of the booking transaction. An anonymous browser booking can be added later with an active personal management link. Repeating the claim for the same account succeeds without a duplicate; a different account cannot take over an existing claim. The booking's original contact snapshot remains unchanged.
Prior professionals are derived from claimed appointments. The account can still show a visit when its schedule is archived, but cannot offer a new booking on that schedule.
A client can cancel an owned future confirmed appointment. The operation keeps its history, releases capacity, and records cancellation effects once. A client without the claim cannot use the account cancellation action for that appointment. The holder of an active management link has a separate bearer capability described in Public booking.