Skip to main content

​
Integration

The durable boundary between your product and Conare. An Integration is owned by your organization; separate deployment stages (staging, prod) are separate Integrations disambiguated by slug. Each has its own cint_... key with explicit scopes (memory:read, memory:write, memory:delete).

​
End users

Every memory call names an endUserId (1–128 chars, A-Za-z0-9@._-) — your identifier for your user. It is not a namespace: the physical tenant is an opaque HMAC derived from your Integration and the end-user ID. Clients cannot select namespaces or address another tenant, by construction.
  • Set display identity with PUT /api/v1/users/{endUserId} (name/email for your dashboard views).
  • DELETE /api/v1/users/{endUserId} is a full GDPR wipe of that user.

​
Containers

Containers group one user’s memories by source — e.g. profile, claude-chats, saved, or one per connected data source (container tag = connector id). Use containerTag on save to organize, and DELETE /api/v1/containers/{containerTag} to drop one source’s memories without touching the rest.

​
Retrieval modes

​
Errors and observability

Errors use a stable envelope — { statusCode, code, message, requestId, details? } — and never leak internal tenant IDs or backend text. Every response includes X-Request-Id; send your own to correlate end-to-end. Rate limits are signaled with standard headers and 429; usage-ledger plans signal an exhausted allowance with 402 plus balance/reset metadata.