LLM.txt

The llm.txt standard is a simple way to give AI tools and agents context about an IntelligenceBox server. Below is a recommended, plain-text summary of the public API, maintained by the IntelligenceBox team. Host it at a well-known URL on your own server or feed it directly into an agent so any LLM-powered tool can understand which endpoints are available and how to authenticate.

What is LLM.txt?

llm.txt is a plain text file at the root of your server that describes:

What the server does
Available API endpoints
How to authenticate
Example requests

AI assistants and tools can read this file to understand how to interact with your IntelligenceBox.

Where to host it

By convention, an llm.txt file lives at the root of the server:

Shell

GET /llm.txt

IntelligenceBox does not generate or serve this file for you -- copy the summary below into a file your server hosts at that path (no authentication required), or paste it straight into your agent’s context.

Example

If you host the file at the path above, agents can fetch it directly:

Shell

curl https://your-box-server/llm.txt

Recommended summary

Keep this in sync with the public API whenever endpoints change:

Shell

# IntelligenceBox API

Private AI server for chat, document search, assistants and desktop notifications.

## Authentication
Box requests except /health require an API key header:
x-api-key: YOUR_API_KEY
(or: Authorization: Bearer YOUR_API_KEY)

Optional workspace headers: x-organization-id, x-organization-scope.
Errors share one envelope: { "error": string, "code": string, "details"?: unknown }.

## Discovery
GET /health                      Server health. No authentication.
GET /api/public/me               Identity and workspace behind the API key.
GET /api/public/models           Available AI models; check hasCredential before use.
GET /api/public/tools            Built-in tool keys for assistants.
GET /api/public/capabilities     Machine-readable map of every endpoint on this box.

## Chat
POST /api/ai/chat
Send messages and receive a streaming (SSE) AI response with citations.

Request:
{
  "id": "unique-chat-id",
  "messages": [{"role": "user", "content": "Hello"}],
  "boxAddress": "https://your-server",
  "assistantId": "optional-assistant-id",
  "vector": ["optional-folder-ids"]
}

POST /api/ai/chat/:id/stop       Stop an in-flight response.
POST /api/v1/chat/completions    OpenAI-compatible passthrough to the local model.
                                 No retrieval, no tools, no history; model field ignored.
GET  /api/v1/models              OpenAI-compatible model list.

## Conversations
GET    /api/public/chats         List conversations. ?origin=API for API-created ones.
GET    /api/public/chats/:id     Conversation with its full transcript.
PATCH  /api/public/chats/:id     Rename. Body: { "title": string }
DELETE /api/public/chats/:id     Delete the conversation and its messages.

## Folders (knowledge collections)
GET    /api/public/vectors       List folders.
POST   /api/public/vectors       Create. Body: { "name", "description?", "strategy?": CHUNK|DOCUMENT|TABULAR, "topK?" }
GET    /api/public/vectors/:id   Folder with its pipeline settings and file count.
PATCH  /api/public/vectors/:id   Update metadata and retrieval settings. strategy is immutable.
DELETE /api/public/vectors/:id   Delete the folder and everything indexed in it.

POST /api/public/vectors/:id/search
Semantic search with no LLM. Body: { "query": string, "limit?": number, "documentIds?": string[] }
Returns passages with score, text, documentId, fileName, pageNumber.

## Files
GET    /api/public/vectors/:id/files                  List files in a folder.
POST   /api/public/vectors/:id/files                  Upload (multipart/form-data, field "file").
GET    /api/public/vectors/:id/files/:fileId          File metadata.
PUT    /api/public/vectors/:id/files/:fileId          Replace a file.
DELETE /api/public/vectors/:id/files/:fileId          Delete a file.
GET    /api/public/vectors/:id/files/:fileId/content   Download the bytes.

## Assistants
GET    /api/public/assistants        List assistants.
POST   /api/public/assistants        Create. Body: { "name", "instructions?", "visibility?", "vectorIds?", "builtInTools?" }
GET    /api/public/assistants/:id    Assistant with full instructions.
PATCH  /api/public/assistants/:id    Update (owner only). Collections replace, they do not merge.
DELETE /api/public/assistants/:id    Delete (owner only).

## Notifications (push into the desktop app)
POST /api/public/notifications
Body: {
  "title": string,             // required
  "description": string,
  "type": "info"|"success"|"error",
  "category": "system"|"backgroundTasks"|"chat"|"calendar"|"email"|"messaging"|...,
  "deepLink": "/inter/chat/:id",   // in-app route, must start with "/"
  "icon": "Rocket",                // Lucide icon name
  "name": "CI pipeline",
  "read": false,
  "dedupeKey": "job:nightly",      // collapse repeats into one row
  "silent": false
}
Persisted first, then delivered live — a notification sent while the app is closed
is replayed in the bell on the next launch.

GET    /api/public/notifications                Feed. ?unreadOnly=true&category=&limit=&offset=
GET    /api/public/notifications/unread-count   Unread count.
GET    /api/public/notifications/:id            One notification.
PATCH  /api/public/notifications/:id            Body: { "read": boolean } | { "seen": boolean }
POST   /api/public/notifications/read-all       Mark everything read.
DELETE /api/public/notifications/:id            Delete.

### External apps (EMBED)
An app installed into the box is opened by a form POST to its SSO path
carrying ticket, apiKey and apiBaseUrl. The key acts as the launching user;
redeem the ticket server-side to confirm who they are.

POST /api/integrations/embed/exchange   (on the AUTH service, not the box)
Headers: Authorization: Bearer <the apiKey from the launch POST>
Body:    { "ticket": string }
Returns: { user: { id, email, name }, embed: { key } }
There is NO per-installation client secret: one external app serves many
installations and the ticket is opaque, so it would have nothing to look one
up by. The ticket is bound to the key digest instead — a ticket captured
alone is not redeemable. Call the box API with the x-api-key header against
apiBaseUrl, but validate that URL against what you know for the customer:
it arrives in a forgeable POST. The key is stable per user+app and keeps
working between launches. It dies when access is revoked or the app is
paused/uninstalled.

## Support reports (AUTH service)
POST AUTH_URL/api/v1/tickets
Authorization: Bearer <cloud JWT or cloud API key>
Content-Type: application/json
Body: { "sourceApp": string, "title": string, "description": string,
        "type"?: "BUG"|"SUGGESTION"|"QUESTION", "context"?: object }
Optional screenshot/attachment data URLs and uiLogs/serverLogs arrays.
Returns 201: { "ticket": { "id", "createdAt", "status": "OPEN", "sourceApp" } }.
Reporter and company come from credentials. Box-local and boxe_ keys do not
work here. Restricted cloud keys need permissions: { "tickets": ["create"] }.
Complete body limit: 20,000,000 bytes. Key quotas/rate limits apply.
Each successful POST creates a ticket; context.externalId does not deduplicate.
Errors: { "error": { "code", "message", "issues"? } }.
See /docs/api/tickets for all fields, limits and error codes.

## More Info
https://intelligencebox.it/docs

Why Use LLM.txt?

The llm.txt file bridges the gap between traditional API documentation and the way modern AI agents consume information. Unlike OpenAPI specs or HTML docs, it is designed to be lightweight and immediately parsable by language models without requiring a specialized client library.

AI Tools: Tools like Claude, ChatGPT plugins, and autonomous agents can discover your API endpoints, authentication requirements, and request formats automatically.
Documentation: The file doubles as a human-readable summary of your API, making it useful for developers who want a quick overview without navigating full documentation.
Standardized: As adoption grows, llm.txt is becoming the de facto standard for AI-to-API discovery, similar to how robots.txt became the standard for search engine crawlers.
Team-maintained: The IntelligenceBox team keeps this recommended summary in sync with the public API. Copy it into your own llm.txt or your agent’s context, and re-check it when the API changes.

Integration Tips

If you are building an AI agent or tool that needs to interact with an IntelligenceBox instance, feed the summary above (or the llm.txt file, if the server hosts one) into your agent’s system prompt or context window so the model understands which endpoints are available and how to authenticate. This approach lets your agent adapt to an IntelligenceBox server without hardcoded endpoint URLs.

LLM.txt

What is LLM.txt?

Where to host it

Example

Recommended summary

Why Use LLM.txt?

Integration Tips

Learn More