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

# End-user lifecycle

> Attach display identity to opaque end-user tenants, delete users with a full GDPR teardown, and understand how retention treats connector activity.

Every memory call names an `endUserId` — your stable identifier for your user (1–128 chars, `A-Za-z0-9@._-`). Conare never stores it in the clear: the physical tenant is an opaque HMAC derived from your Integration and the ID, and isolation always keys off the hash. This page covers the two lifecycle operations you own — labeling and deletion — plus how automatic retention interacts with connectors.

## Attach display identity

By default, your dashboard's End Users roster shows opaque hashes. Push a display name and/or email so the roster shows people instead:

```bash theme={null}
curl -X PUT https://api.conare.ai/api/v1/users/u_123 \
  -H "Authorization: Bearer $CONARE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Ada Lovelace", "email": "ada@example.com" }'
```

Or with the SDK:

```ts theme={null}
await conare.setUserIdentity({
  endUserId: "u_123",
  name: "Ada Lovelace",
  email: "ada@example.com",
});
```

Semantics:

* **Cosmetic only.** The `endUserId` stays HMAC-hashed on Conare's side; retrieval, isolation, and billing still key off the hash. This label just changes what *you* see in the roster.
* **Partial updates.** Send a string to set a field, `null` to clear it, omit the key to leave it untouched. Provide at least one of `name` or `email`.
* **Limits.** `name` up to 120 chars, `email` up to 254 chars (shape-checked for `@`; no deliverability check — you own your users' address hygiene).
* **Unmetered.** The call is free and does not count as end-user activity, so labeling a dormant user will not extend their retention window.

When to use it: call this whenever you already know a display identity for a user — for example, right after they sign up, or when you first ship the integration and want to backfill labels for existing users. It is optional; skipping it just leaves the roster showing hashes.

## Delete an end user (GDPR wipe)

`DELETE /api/v1/users/{endUserId}` is a full, irreversible teardown. Wire it into your account-deletion flow.

```bash theme={null}
curl -X DELETE https://api.conare.ai/api/v1/users/u_123 \
  -H "Authorization: Bearer $CONARE_KEY"
```

```ts theme={null}
await conare.deleteUser("u_123");
```

In one call, Conare:

1. **Revokes connector-plane resources first** — any OAuth holds and per-user connector resources are torn down before the memory wipe. If the connector plane is unreachable the call returns `503` so you can retry; a wipe that left a live OAuth token behind would be a false success.
2. **Wipes the memory plane** — every memory, every vector, every container for that user.
3. **Drops connector state** — the per-user connector state used to resume incremental syncs.
4. **Removes the roster row** — the user disappears from your End Users dashboard.

In-flight background syncs cannot resurrect a deleted user. If a connector sync is running when you delete, the sync aborts mid-run rather than writing into the wiped tenant.

<Note>
  `DELETE` is always immediate and always the whole user, regardless of your retention policy. There is no soft-delete or grace period.
</Note>

## Automatic retention

Under **Platform → Retention** you can set a maximum inactivity window. Once a window is configured, Conare automatically purges any end user idle for longer than that — a purge runs the same full teardown as an explicit `DELETE /api/v1/users/{endUserId}` (memory plane, connector state, roster row, OAuth revocations).

What counts as activity:

* Any partner API call that names the user — including reads (`search`, `recall`, `suggestions`) and writes (`memories`, `containers`).
* **Connector syncs count as activity.** A user with a live connector is retained until you disconnect it. If you want automatic retention to apply to connected users, disconnect the connector first (or delete the user explicitly).

What does not count as activity:

* `PUT /api/v1/users/{endUserId}` (setting display identity) — labeling a dormant user does not extend retention.
* Dashboard views of the roster.

Leave the field empty to keep users forever. Explicit `DELETE` requests always run immediately regardless of retention settings.