Users & agents

Audit log

What happened in your project, and what your agents read: one event per call that ran, newest first.

"Who wrote this memory, and what did the agent know when it decided?" Filter by user_id to get the events attributed to one end user: writes, edits, fact writes, corrections and forgets, end-user erasures, reads of one memory, and every read made with that user_id, with the memories and facts it returned. A read made without a user_id, and the event that queues a batch, carry user_id null: find them by target_id or in read. Each memory a batch imports has its own write event (actor worker, meta.batch the job id) with its end user. A read lists ids. To see what the store knew at that moment, read with known_as_of set to the event's ts: Get facts returns the facts as the store knew them then, and Get context the block it could have built. as_of answers another question: what was true then, as the store knows it now.

The log records ids, counts and short labels, never the text of a memory, a fact or a query. Erasing an end user or an agent namespace therefore removes its content for good, and the log still shows that it happened. Forgetting a single memory is recorded as erase too, but keeps the memory and its facts as history. Events are kept for 400 days.

This endpoint returns the events filed under your key's project: every call made with a key, key_create, key_change, a project's create, rename, archive and unarchive (setting_change), a key disconnected by an app (key_revoke), and reads made from the dashboard on this project's data (actor dashboard). Administrative events with no project are not returned to a key: login, logout, a key revoked from the dashboard or with an admin key, webhook and alias settings, a project deleted, and facts corrected or forgotten, or an end user erased across the account, from the dashboard. They are in the dashboard's operator audit screen.

Authentication

HTTP header, required: Authorization: Bearer kor_live_.... The key needs the memories:read scope. Reading the log does not count against your query quota, and the read is not itself written to the log.

A key sees only the events of its own account and its own project. A key whose project was deleted falls back to the account's Default project and reads its events.

Query parameters

Example request

curl "https://api.korely.ai/v1/audit?user_id=customer-4812&limit=50" \
  -H "Authorization: Bearer kor_live_..."

import requests

r = requests.get(
    "https://api.korely.ai/v1/audit",
    params={"user_id": "customer-4812", "limit": 50},
    headers={"Authorization": "Bearer kor_live_..."},
)
for e in r.json()["events"]:
    print(e["ts"], e["action"], e["target_id"], (e.get("read") or {}).get("facts"))

const r = await fetch(
  "https://api.korely.ai/v1/audit?user_id=customer-4812&limit=50",
  { headers: { Authorization: "Bearer kor_live_..." } },
);
const { events, total } = await r.json();

Response

200 OK. The events, newest first, and how many match. The order is ts descending, then the event's internal id descending, so two events in the same instant keep one order and paging with offset is stable: a page neither repeats nor skips an event that was already there.

{
  "events": [
    {
      "ts": "2026-10-02T09:14:31.218000Z",
      "actor": "rest",
      "action": "read",
      "result": "ok",
      "user_id": "customer-4812",
      "target_id": null,
      "meta": {"endpoint": "context", "memories_read": 3, "facts_read": 2},
      "ip": null,
      "read": {"memories": ["mem_8f2c1a", "mem_41d0e7", "mem_c9a0b2"], "facts": ["fct_a1", "fct_b7"]}
    },
    {
      "ts": "2026-10-02T09:12:05.004000Z",
      "actor": "rest",
      "action": "write",
      "result": "ok",
      "user_id": "customer-4812",
      "target_id": "mem_c9a0b2",
      "meta": {"endpoint": "memories:add"},
      "ip": null,
      "read": null
    }
  ],
  "total": 2
}

Errors