Skip to main content
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:
Or with the SDK:
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.
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.
DELETE is always immediate and always the whole user, regardless of your retention policy. There is no soft-delete or grace period.

​
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.