Remember
POST /api/v1/remember — Ingest data and build the knowledge graph in a single call.
Combines the add and cognify steps. Equivalent to calling cognee.remember() in the Python SDK. Accepts multipart form data. For most workflows, remember is the simplest entry point; use the lower-level add + cognify operations separately when you need to upload multiple files before triggering processing.
On a completed run, the response includes
items_processed — the count of successfully ingested items (entries whose pipeline run did not error).
Error responses
A
graph_model that is invalid JSON or cannot be converted to a schema is now rejected with 400 rather than being silently ignored. Empty optional fields (content_type, graph_model, session_id, node_set entries) are treated as omitted.How per-file labels and metadata work
POST /api/v1/remember and POST /api/v1/add both accept two optional form fields that attach a label and arbitrary metadata to each uploaded file. They are the HTTP equivalent of the Python SDK’s DataItem(label=..., external_metadata=...).
Each field is sent as a single JSON part, not one part per file, because multipart clients cannot reliably repeat an array form field. Entries pair positionally with the uploaded files: the Nth entry applies to the Nth file.
400. external_metadata is merged into the file’s stored metadata, with your keys taking precedence over loader-derived ones; node_set is reserved and rejected, so use the node_set form field instead.
Saved values are returned by GET /api/v1/datasets/{dataset_id}/data as label and externalMetadata.
Swagger UI caveat. Typing a JSON array of strings into the
labels field in Swagger UI sends it as a comma-joined string (finance,people,). The endpoint accepts that form equivalently, so try-it-out works — but it means a label cannot contain a comma unless your client sends real JSON. external_metadata has no comma-separated fallback: it must always be valid JSON.Lower-level operations
The following endpoints provide more granular control over data ingestion. Most users should preferremember above.
Add
POST /api/v1/add — Upload files to a dataset without processing.
Accepts multipart form data. Files are stored in the dataset but not yet processed into the knowledge graph — call cognify separately.
Unlike
remember, add has no session_id or content_type, so labels and external_metadata are always available here.
Supported file types:
- Documents — PDF, TXT, Markdown, CSV, JSON, DOCX, PPTX
- Images — PNG, JPG, JPEG, GIF, WEBP, TIFF, BMP, and more, extracted via the tenant’s configured vision model
- Audio — MP3, WAV, M4A, OGG, FLAC, and more, transcribed to text
POST /api/v1/remember.
Update
PATCH /api/v1/update — Replace an existing document in a dataset.
Accepts multipart form data. Requires both the data item ID and dataset ID as query parameters.
Storage and document limits
Keeping data in a workspace is not itself billed — there is no per-document or per-byte charge, only the token cost of processing it. Stored volume is capped instead:
Both are checked by
POST /api/v1/add — and by POST /api/v1/add_text — before anything is stored, against what you already hold plus the incoming payload. A call that would cross either limit is rejected with 413 Request Entity Too Large, and none of its files are stored:
GET /api/v1/quotas/usage reports where you stand, as storageUsedInBytes against storageLimitInBytes.
POST /api/v1/remember carries the token-credit guard but not this check, so data ingested through it is not counted against either limit at request time. The check is also per request rather than atomic, so uploads running concurrently can overshoot slightly before the next one is rejected.
Uploads from the Cloud UI go through
add in batches of up to 10 files (200 files per selection), so a selection that crosses a limit part-way keeps the batches that already landed and fails the one that crossed it. Free the space up by deleting data you no longer need — see Delete — and retry the remainder.