Korely
Join early access

Platform

Data & governance

Where your agents' memory lives, who can touch it, and how to erase it.

EU data residency

Your stored memory lives on our own infrastructure in the EU (Helsinki, Finland — Hetzner). It is stored and processed in the EU, never replicated to the US — which side-steps the US CLOUD Act exposure that comes with US-hosted memory vendors. EU residency applies on every tier, including the free Hobby plan, and requires no configuration on your part.

Sub-processors used during the write path (entity extraction, embedding) are DPA-covered EU or EU-adequate providers. The derived outputs — facts, embeddings, graph edges — are stored only in your account's namespace. Raw message content is discarded from inference pipelines after extraction completes.

EU residency applies to every namespace by construction — your facts, embeddings, and graph edges are written only to EU-hosted storage. A GET /v1/ping probe confirms the API is reachable and echoes your key's tier and scopes:

Terminal window
curl https://api.korely.ai/v1/ping \
  -H "Authorization: Bearer kor_live_..."
# {"ok":true,"tier":"hobby","scopes":["memories:read","memories:write"]}

Namespaces & scoping

Every call is scoped by your account first, then by the namespace parameters you pass:

  • user_id — your end user. The unit of isolation; unlimited on every tier. Choose any opaque string (a database ID, a hashed email, a UUID) — Korely never validates the format.
  • agent_id — one of your apps or agents. Plans cap the number of distinct agent IDs (Hobby: 2, Developer: 10, Team: 100, Scale: 500). Passing an unknown agent_id past your plan's limit returns 403 agent_cap_exceeded.
  • run_id — a single session or conversation turn. Useful for isolating memories that should not persist across runs.

The scope is enforced server-side on every query. One customer's memories can never surface in another's results — by construction, not by prompt discipline. The GET /v1/users endpoint lists every user_id that appears in your account, so you always know exactly which end-user data you hold.

Terminal window
# List every end user in your account, with memory and fact counts
curl https://api.korely.ai/v1/users \
  -H "Authorization: Bearer kor_live_..."
# {"users": [
#   {"user_id": "customer-4812", "memories": 18, "facts": 9, "last_active": "2026-06-15T..."},
#   {"user_id": "customer-7091", "memories": 4,  "facts": 2, "last_active": "2026-06-14T..."}
# ]}

Erasure (GDPR Article 17)

Forget everything Korely holds about one end user — every memory and every fact — in a single call:

Terminal window
curl -X DELETE "https://api.korely.ai/v1/users/customer-4812/memories" \
  -H "Authorization: Bearer kor_live_..."
# 200 OK
# {"user_id":"customer-4812","memories_forgotten":18,"facts_invalidated":9,"audit_id":"aud_..."}

The call returns a receipt — memories_forgotten, facts_invalidated, and an audit_id — so the erasure is itself provable. This is where Korely's bi-temporal model earns its keep: a "forget" invalidates each typed fact (stamps invalid_at) rather than mutating or hard-deleting the underlying record. The data instantly stops being served to every query surface — REST, SDK, CLI, or MCP — while a tamper-evident audit trail of what was held and when it was erased stays intact for your own Article 17 accountability. The endpoint is idempotent: erasing an unknown or already-erased user returns 200 with zero counts, never an error.

To forget a single memory (rather than an entire user), use DELETE /v1/memories/{id} — or korely.delete(id) in the SDK. It returns {"id":"mem_...","status":"forgotten","facts_invalidated":N,"audit_id":"aud_..."}. A repeat delete of the same memory, or a delete of an id that was never created, returns 404 not_found.

If you track which user_id values map to real people in your own system, a one-call erasure is the complete Korely side of an Article 17 workflow — no support ticket, no waiting period.

API keys

Requests authenticate with a kor_live_ key in the Authorization: Bearer header. Korely stores only a salted SHA-256 hash of the key — the plaintext is shown exactly once, at creation, and cannot be retrieved afterward. If a key is lost or suspected compromised, rotate it from the dashboard; the old key stops working instantly across every surface (REST, SDK, CLI, MCP).

An invalid or missing key returns 401 invalid_key. Every Korely error uses the same flat envelope — {"code": "<slug>", "message": "<text>"} — so one catch block handles all of them: 

{
  "code": "invalid_key",
  "message": "Invalid or missing API key"
}

Best practice: store your key in an environment variable (KORELY_API_KEY) rather than hard-coding it. The SDK reads this variable automatically. Never commit a kor_live_ key to source control.

No training on your data

Your stored memories and facts are never used to train or fine-tune any model — Korely's own or any third party's. AI inference on the write path (entity extraction, relation typing, embeddings) runs through DPA-covered sub-processors in data-processor mode, where they are contractually prohibited from using your data for their own model training. The processed outputs belong exclusively to your account namespace.

There is no opt-out toggle because there is no opt-in: training on customer data is not part of the data pipeline, by design.

Quota & rate limits

Plans carry monthly write and query quotas (see pricing). When you reach your monthly memory write limit, further writes return 429 quota_exceeded. There is no surprise overage charge — you can upgrade at any time to raise your limit. The write-quota 429 carries no Retry-After header (the cap resets on your billing cycle, not after a delay): 

{
  "code": "quota_exceeded",
  "message": "Monthly memory write limit reached (1000). Upgrade to add more."
}

Short-term request bursts are handled separately. If you exceed the per-second rate limit, you get a 429 that does carry a Retry-After header — an integer number of seconds to wait before retrying.

For the full security posture — encryption in transit and at rest, sub-processor list, and compliance documentation — see the security page.

Related