Knowledge

Limits and errors

Capacity, supported file formats and failure handling.

Capacity

These limits apply to the current API. Processing timings below are measurements, not a service guarantee.

LimitValue
Non-deleted stores per organization100
Files per store10,000
Source file size100,000,000 bytes (100 MB)
Estimated tokens per file5,000,000
Files per batch1–500
Store name256 characters
metadata / attributes keys16
Key / string value length64 / 512 characters
Static chunk size100–4096 tokens
Default chunk / overlap800 / 400 tokens
Maximum overlap≤ ½ chunk size
Search results (files on the compatible API, chunks on the native API)1–50; default 10
List page size1–100; default 20
Expiry days1–365
JSON request body1,000,000 bytes
Ingestion deadline30 minutes
Processing retries3
Retention after deletion7 days

Metadata values are strings. Attribute values may be strings, numbers or booleans. Filter nesting is limited to 20 levels below the root. Search candidates are capped at 50 per retrieval method. Search has no next page.

File formats and processing time

A knowledge base can ingest these types (as detected by the file service):

TypeIngested content
PDFDocument text
DOCX, PPTX, XLSXDocument text
PNG, JPEG, GIF, WebPA model-generated description of the picture, not verbatim OCR
HTMLVisible text, without scripts and styles
Plain text, Markdown, CSV, JSONThe original text

An accepted upload is not necessarily ingestible. The file service accepts these types, but a knowledge base cannot ingest them: audio (MP3, WAV, FLAC, OGG, M4A), video (MP4, WebM), NDJSON, XML, YAML, SVG, and files detected as Python or JavaScript source. Attaching them is not refused; ingestion fails asynchronously, the file status becomes failed and last_error.code is unsupported_file. Encrypted PDF or Office files also fail during ingestion (invalid_file). Empty files, ZIP archives and other binary files are rejected by the file service at upload.

Develop measurements on 2026-10-11: text and documents finished ingestion in about 4–21 seconds; a single image took about 4–11 seconds, and one PNG took about 87 seconds while 7 files were ingested at once.

HTTP errors

HTTPcodeAction
400INVALID_PARAMS / LIMIT_EXCEEDEDCorrect parameters or reduce the request size.
401UNAUTHENTICATEDCheck the API Key; compatible code is null.
404VECTOR_STORE_NOT_FOUND / FILE_NOT_FOUND / FILE_NOT_IN_STORE / BATCH_NOT_FOUND / CHUNK_NOT_FOUNDCheck the resource ID and its store.
409VECTOR_STORE_INVALID_STATE / FILE_INVALID_STATECheck deletion, expiry or file processing state.
413PAYLOAD_TOO_LARGEJSON request exceeds 1 MB; compatible code can be null.
429RATE_LIMITEDRetry later.
500— / nullInternal error; retain the request ID and retry later.
501NOT_IMPLEMENTEDOperation is not implemented.
503PROVIDER_UNAVAILABLEProcessing is temporarily unavailable; retry later.

Native errors normally use error.code, error.message and error.details. Compatible errors use error.message, error.type, error.param and error.code; the official SDK raises the corresponding HTTP error class. Unknown routes can omit code, 401 can omit details and malformed URL encoding can produce HTML.

Asynchronous failures

A file with status failed reports last_error.code: unsupported_file for unsupported parsing, invalid_file for invalid/empty/encrypted content, or server_error for processing failure or timeout. The estimated-token limit currently maps to invalid_file; its over-limit behavior has not been measured. Check file status after a successful attachment. Retry is available through the native API for failed files; successful retry after failure was not covered in the measurements.

Actual expiry and purge after 7 days have not been observed end to end. No reliable per-service requests-per-second limit was established by the tests.

Complete error objects → · Search limitations →

Export

On this page