User lifecycle

Design memory around your existing user lifecycle. The winning pattern is simple: one internal user, one stable Memory Key, one private vault.

Signup

Create or assign a Memory Key when the user first needs memory. Mint keys with POST /v1/keys, authenticated with your account's Memory Key, or create them in the dashboard.

new user signup
  → POST /v1/keys  (mint a Memory Key)
  → store user_id ↔ memory_key mapping
  → use that key on every AI request for that user

curl -X POST https://api.memoryrouter.ai/v1/keys \
  -H "Authorization: Bearer $MEMORYROUTER_ACCOUNT_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "user:42" }'

The new key belongs to your account and inherits the provider keys you have stored. If you do not need memory until the user's first AI interaction, lazy provisioning is fine. See the Quickstart for the full getOrCreateMemoryKey pattern.

Usage

Every AI call from that user should include the same Memory Key.

const memoryKey = await getOrCreateMemoryKey(user.id)

await client.chat.completions.create(
  { model: 'openai/gpt-5.5', messages },
  { headers: { Authorization: `Bearer ${memoryKey}` } }
)

Plan changes

Keep the Memory Key stable when the user upgrades, downgrades, pauses, or changes billing plans. Billing state should change around the vault, not replace it.

Revocation and rotation

If a key is exposed, rotate it: mint a fresh key with POST /v1/keys, repoint your user_id mapping to the new key, and stop using the old one. The vault stays tied to the user identity through your mapping, while the exposed credential is no longer referenced.

Key deactivation and rotation tooling is available through the dashboard. For high-volume automated rotation, the cleanest pattern today is to issue a new key per user and update your stored mapping.

Account deletion

On account deletion:

1. Stop sending new requests with the user's Memory Key.
2. Delete the user's vault with DELETE /v1/memory, authenticated with that user's Memory Key.
3. Drop the user_id ↔ memory_key mapping from your store.
4. Record completion in your own audit trail.

curl -X DELETE https://api.memoryrouter.ai/v1/memory \
  -H "Authorization: Bearer mk_user-key"

This clears the memory stored in that user's vault. Run it as part of your own deletion flow so memory deletion stays in sync with the rest of the user's data.

Export

If your product offers data export, include memory in the same user-data export flow. Use POST /v1/memory/search to pull a user's memories with their Memory Key, then include the results in your export package alongside the rest of their data.

Migration and import

Backfill existing context when adopting MemoryRouter:

• profile fields
• conversation summaries
• support tickets
• coaching plans
• tutor progress
• sales notes
• product preferences

Use POST /v1/memory/upload for JSONL imports into the user's vault. Keep imports scoped by user so one customer's history never lands in another customer's vault.