> ## Documentation Index
> Fetch the complete documentation index at: https://docs.impellabs.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity

> Who the buyer is, and the reference your tools receive.

## One person, many handles

The platform separates the **customer** (a person) from their **identities**
(one per channel handle) and from **leads** (a conversation record).

```
Customer  "Anjali"
 ├── identity  whatsapp  · 919...
 ├── identity  website   · visitor-id
 └── identity  instagram · @handle
```

A customer who messages on WhatsApp after using the website widget is
recognised as the same person — so a cart started in one place is still theirs
in the other.

## Merges are conservative

Identities merge only on a **verified** contact detail: a phone number the
platform actually received a message from, or a confirmed email. Never on a
name, never on similarity, never probabilistically.

<Note>
  This is deliberate. A wrong merge hands one customer another customer's
  conversation and order history — the kind of mistake that cannot be
  apologised away.
</Note>

Every merge is recorded and reversible.

## `buyer_ref`

Your tools receive a stable reference for the person in the conversation. Use
it as the key for their cart, their tier and their history.

<Warning>
  Treat `buyer_ref` as a pseudonymous key, not proof of anything. Whether that
  buyer is verified for wholesale, allowed a discount, or permitted to see an
  order is **your** decision, resolved from your own records against the
  workspace the auth token identifies.
</Warning>

## What you should not ask for

Do not require a phone number or email as a tool argument to identify someone.
The platform already knows who is talking; asking again makes the assistant
interrogate a customer it has already recognised, which reads as forgetting
them.