The indexing API lets you upload a folder’s worth of files from the browser and track the resulting background job. Files are copied toDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/TrinaxCode/TrinaxAI/llms.txt
Use this file to discover all available pages before exploring further.
local_sources/collections/<collection_id>/<label>-<timestamp>/, then index.py is spawned as a subprocess to chunk and embed them. The in-memory retriever reloads automatically when the job completes. All endpoints on this page require authorization.
All indexing and watcher endpoints require authorization via localhost/LAN access or an
X-Admin-Token header.POST /system/index-upload
Upload a folder for indexing via a multipart form. The browser’s native folder picker provides the files — TrinaxAI copies them into a local staging directory and launches a background indexing job.Request
multipart/form-data with the following fields:
One or more files to index. File paths are sanitized to prevent path traversal. Unsupported or oversized files are skipped automatically.
Human-readable label for the import batch (e.g.
"InsiderApp" or "Q2Docs"). Used in the target directory name and job metadata. Sanitized to alphanumeric + dots, spaces, and hyphens.ID of the collection to index files into. If the collection does not yet exist it is created automatically.
Response
Always
true when the job is successfully started.Unique hex ID for the background indexing job. Use this with
GET /system/index-jobs/{job_id} to poll progress.Always
false at job start — indexing runs in the background.Absolute path of the staging directory where files were saved.
Number of files successfully saved to the staging directory.
Number of files skipped (oversized, unsafe paths, or write errors).
Total bytes saved to disk.
List of project names already known to the in-memory index at upload time. Usually
[] at job start since indexing runs in the background.Resolved collection ID for this job.
Display name of the resolved collection.
Example
Response
GET /system/index-jobs/{job_id}
Poll the status and progress of a running or completed indexing job.Path parameters
The job ID returned by
POST /system/index-upload.Response
The job ID.
Human-readable batch label.
Current job state. One of:
"saving", "indexing", "completed", "failed", "cancelled".Granular phase within the current status. Examples:
"starting", "chunking", "embedding", "saving_index", "finishing", "completed", "failed", "cancelled".Estimated completion percentage
[0, 100].Estimated seconds remaining, or
null if not calculable yet.Seconds elapsed since the job started.
Files saved to the staging directory.
Files that were skipped.
Total bytes processed.
true once the in-memory retriever has been successfully reloaded with the new content.List of project names detected in the indexed content (populated after completion).
Collection ID for this job.
Collection display name.
Last 8,000 characters of stdout from
index.py. Useful for diagnosing failures.Error message if the job failed, otherwise empty string.
Whether cancellation was requested.
Unix timestamp when the job was created.
Unix timestamp when the job finished, or
null if still running.Example
Response
POST /system/index-jobs/{job_id}/cancel
Request cancellation of a running index job. The subprocess is sentSIGTERM and the job transitions to "cancelled" status. Already-saved files in the staging directory are not removed.
Path parameters
The job ID to cancel.
Response
Always
true when the cancellation request is accepted.The final job state object (same shape as
GET /system/index-jobs/{job_id}).Example
Response
POST /system/reload
Hot-reload the RAG index from thestorage/ directory without restarting the API server. Call this after running python index.py manually on the host or after making changes to local_sources/.
Response
true if the index was loaded successfully. false if storage/ has no valid index yet.true if the in-memory retriever is now active.List of project names detected in the freshly loaded index.
Example
Response
POST /v1/watch/start
Start a filesystem watcher (backed bywatchdog) that automatically triggers a re-index whenever files in the watched directories are created, modified, moved, or deleted. Requires the watchdog Python package to be installed.
Returns HTTP
501 if watchdog is not installed. Install it with pip install watchdog.Request body
List of absolute directory paths to watch recursively. If omitted, TrinaxAI auto-discovers sensible defaults based on
local_sources/ and the active collection’s subdirectory.Collection ID used to narrow the default path discovery when
paths is not provided.Response
"started" if the watcher was launched. "already_running" if a watcher is already active.List of absolute directory paths now being watched.
Process ID of the RAG API server hosting the watcher thread.
Example
Response
POST /v1/watch/stop
Stop the running filesystem watcher. If no watcher is active, returns"not_running".
Response
"stopped" if a watcher was running and has been stopped. "not_running" if there was nothing to stop.Example
Response
GET /v1/watch/status
Report the current state of the filesystem watcher.Response
true if the watcher observer thread is alive.List of absolute directory paths currently being watched. Empty if not running.
Total number of filesystem events processed since the watcher was started.
Unix timestamp when the watcher was started, or
null if not running.Example
Response
POST /v1/usage
Record a usage event from frontend-only flows (e.g. direct Ollama chat that bypasses the RAG API). These events are appended tostorage/usage.jsonl and rolled into the usage summary.
Request body
Usage engine identifier (e.g.
"ollama", "rag", "direct"). Max 40 characters.Model name used for the request. Max 120 characters.
Optional project name associated with the request.
Optional list of collection IDs involved in the request.
Estimated token count for the request. Used for the aggregated token counter in
/v1/stats.Response
Always
true.Example
Response
GET /v1/stats
Retrieve aggregated local usage statistics built fromstorage/usage.jsonl. The summary is incrementally maintained on every usage record write and served from storage/usage_summary.json for fast reads.
Response
Total number of recorded usage events.
Map of engine name → count, sorted by descending count.
Sum of all
est_tokens values across all recorded events.Top 10 collections by usage count, each as
{"id": string, "count": integer}.Top 10 models by usage count, each as
{"model": string, "count": integer}.Number of indexing runs recorded.
Unix timestamp of the earliest recorded event.
0.0 if no events yet.Unix timestamp of the most recent recorded event.
Example
Response