# Authentication
Source: https://docs.qontext.ai/api-docs/authentication
Create and rotate workspace API keys, authenticate requests, and configure access controls.
Authenticate with an API key from the workspace you want to access. Use the same key for every request in a workflow.
```bash theme={null}
curl --fail-with-body https://api.qontext.ai/v1/files \
-H "Authorization: Bearer $QONTEXT_API_KEY"
```
`X-API-Key` is also supported. Send one authentication header: if both are present, `X-API-Key` takes precedence, even when its value is invalid.
## Workspace access
The key determines the workspace and the files and folders the client can access. Configure its **Access Controls** in the app; see [Access management](/features/access-management#access-controls-for-api-keys).
Keys inherit their creator’s permissions by default. A key inheriting an owner’s or admin’s permissions can change file protection. Permissions assigned directly to a key are limited to **Can read** or **Can edit**; those grants do not allow changing protection.
Use separate keys for each application or environment. Keep secrets in environment variables or a secret manager, outside source code and browser applications.
## Creating an API key
In the [Qontext app](https://app.qontext.ai), go to **Clients → API Keys**. To add an API key, click **+ Create API key** in the top right corner.
In the **Create an API key** window, give your key a name and add an expiration date if required.
Copy the API key and store it safely. You will not be able to view it again later.
You can now access the context repository from any application, workflow, or script by sending `Authorization: Bearer ` with API requests.
## Rotating an API key
Rotate a key to replace its secret while keeping the key itself in place. Rotate when a secret may have been exposed, when it was shared more widely than intended, or on a regular schedule as part of your security practices. Owners, admins, and the member who created the key can rotate it.
The current secret stops working immediately. There is no overlap period, so any client still using the old secret fails until you update it with the new one.
In the [Qontext app](https://app.qontext.ai), go to **Clients → API Keys**. Click the three dots next to the key and choose **Rotate**, or open the key and select **Rotate** in the **Danger zone**.
Check that you are rotating the right key, then select **Rotate key**.
Copy the new API key and store it safely. You will not be able to view it again later.
Replace the old secret wherever the key is used and send it using `Authorization: Bearer `. Send a request to confirm the client works again.
### What stays the same
Rotation keeps the key's name, access controls, expiration date, and retrieval logs. It does not extend the expiration date; replace an expired key with a new one.
# Errors and limits
Source: https://docs.qontext.ai/api-docs/errors
Handle API errors, review outcomes, retries, and content limits.
## Error response format
Public API errors use the content type `application/problem+json` and this body:
```json theme={null}
{
"type": "https://docs.qontext.ai/errors/path-already-exists",
"title": "Path already exists",
"status": 409,
"code": "path_already_exists",
"detail": "Something already exists at that path.",
"requestId": "01JQ8H2XN4KP7VBR3TFY6ZC9SD"
}
```
| Field | Use |
| - | - |
| `code` | Stable machine code. **Branch on this.** |
| `type` | Stable URI for this kind of failure. It links to the section for the code on this page. You can also branch on this. |
| `status` | The same as the HTTP status. |
| `title` | Human label. Do not branch on it. |
| `detail` | Human explanation. Safe to show. Do not branch on it. |
| `requestId` | Locates the call in our logs. Send it to us when you ask for help. |
| `errors` | Present when specific inputs are at fault. One entry per field. |
`requestId` is also in the `X-Request-Id` response header on every call, success or failure.
## Field errors
When specific inputs are at fault, the `errors` array names each one. This excerpt shows the relevant fields:
```json theme={null}
{
"code": "invalid_request",
"status": 400,
"errors": [
{
"code": "out_of_range",
"pointer": "/limit",
"detail": "limit must not be greater than 1000"
}
]
}
```
`pointer` is a JSON Pointer to the member. `/limit` is the `limit` query parameter. `/content` is the `content` member of the body.
## Reads and writes fail differently
Reading an individual file or folder without access returns `404`. Lists and searches omit items the key cannot read. A write that the key may not perform answers `403 forbidden`.
## Retry rules
* Retry a `503`. Wait for `Retry-After` if the response includes it. Before retrying a write with an uncertain outcome, read the live state.
* Do not retry a `4xx`. Fix the request.
* Do not retry a `202` from `PUT /v1/files/{id}/content`. It is not an error. See [Updating content](/api-docs/updating-content#handle-the-outcome).
## Error codes
Each `type` URI in an error body points to one section below.
### `unauthenticated`
**401.** The API key is missing or not valid.
Do: check the `Authorization: Bearer` header. Create a new key in the app if the key was revoked.
### `forbidden`
**403.** This key may not perform this write.
Do: check the permissions of the key in the app. See [Access management](/features/access-management).
### `not_found`
**404.** The requested resource was not found.
Do: check the URL and resource identifier, and confirm that the key has access.
### `workspace_not_found`
**404.** No workspace matches this key.
Do: create a new key in the workspace you want to write to.
### `file_not_found`
**404.** No such file, or none this key can read.
Do: check the id. Look the file up by path with `GET /v1/files?path=...`.
### `folder_not_found`
**404.** No such folder, or none this key can read. Also answered for a destination folder that does not exist on a move or a create, and for a `parent_id` that names no folder on `GET /v1/folders`.
Do: check the id. Look the folder up by path with `GET /v1/folders?path=...`.
### `invalid_request`
**400.** A parameter or member is unknown or malformed. Also answered when a `PATCH` sends two fields, or none.
Do: read `errors`. Each entry names the field with a JSON Pointer.
### `invalid_id`
**400.** The id is not of the form `doc_…`, `dir_…`, or `chg_…`.
Do: use an id from an earlier response.
### `invalid_base_change`
**400.** `baseChangeId` is not a change of this file.
Do: read the file again. Send the `lastChangeId` it reports.
### `invalid_cursor`
**400.** The cursor is malformed, or was issued for a query with other filters.
Do: start again from the first page. Keep the same filters for every page.
### `path_already_exists`
**409.** A file or folder is already at that path. Nothing was overwritten.
Do: choose another path, or use the existing resource if that is your intent. To replace an existing file's content, read it first and follow [Updating content](/api-docs/updating-content).
### `type_mismatch`
**409.** The path names the wrong kind of resource for this parameter. For example, a folder path where a file path is required.
Do: a file path ends in `.md`. A folder path does not. Send the correct kind.
### `folder_not_empty`
**409.** The folder still has contents. Nothing was removed.
Do: send `recursive=true` to delete the folder with everything below it. Or delete the contents first.
### `changes_in_review`
**409.** The file, or a file in the folder, has changes that wait for review. Nothing was removed.
Do: resolve the changes in the app. See [Change reviews](/features/change-reviews). Then try again.
### `file_protected`
**409.** The file is protected. Nothing was removed.
Do: remove protection before deleting the file. A key inheriting an owner’s or admin’s permissions can change `protected` with [Update a file](/api-docs/files/update-file). Otherwise, ask a member with Full access to remove protection in the app.
### `content_too_large`
**422.** The content is longer than 51,200 characters.
Do: read `errors` for the length you sent and the limit. Split the content into smaller files.
### `service_unavailable`
**503.** The workspace is temporarily unreachable.
Do: wait for `Retry-After` if present, then try again.
### `internal_error`
**500.** An unexpected failure. We already have a report.
Do: inspect the live state before retrying a write. Send [support](mailto:support@qontext.ai) the `requestId` if the failure repeats.
## Limits
| Limit | Value |
| - | - |
| File content | 51,200 characters of Markdown or plain text |
| File or folder name | 255 characters |
| List page size | 1–1,000 items; default 100 |
| Hybrid search results | 1–500 files; default 10 |
| Regex search results | 1–500 files; default 50 |
| Regex search query | 1,024 characters, on a single line |
| Regex matches returned | 50 lines per file |
| Regex line length | Lines longer than 4,096 characters are skipped |
Use names without spaces or other whitespace; hyphens are a safe separator. Shell metacharacters are also rejected. Folder names cannot start with a dot. Names cannot contain `/`, `\`, or control characters, and cannot be `.` or `..`. File names end in lowercase `.md`; folder names do not.
# Files and folders
Source: https://docs.qontext.ai/api-docs/files-and-folders
Understand stable IDs, paths, parent folders, supported content, and file protection.
Files hold Markdown or plain-text content. Folders organize those files within a workspace's context repository.
## IDs and paths
| Field | Meaning |
| - | - |
| `id` | Stable identifier: `doc_…` for a file or `dir_…` for a folder. Use it for later reads and updates. |
| `path` | Absolute location, such as `/support/refunds.md`. Changes when an item or a containing folder moves or is renamed. |
| `parentId` | ID of the containing folder, or `null` at the root. |
| `parentPath` | Path of the containing folder, or `/` at the root. |
| `lastChangeId` | A file's last content change. Use it as `baseChangeId` when replacing content. |
Renaming or moving a file does not change its ID or advance its `lastChangeId`. Moving a folder preserves the IDs of the items below it.
## Create by path or parent
Create a file with either `path` and `content`, or `parentId`, `name`, and `content`. Create a folder with either `path`, or `parentId` and `name`. Use one alternative per request.
A path creates missing parent folders automatically. Set `parentId` to `null` to create at the root. An existing path returns `409 path_already_exists`; creation does not update an existing item.
File paths are absolute and end in lowercase `.md`. Folder paths do not end in `.md`. See [Errors and limits](/api-docs/errors#limits) for content and naming limits.
## Read and find content
[Get a file](/api-docs/files/get-file) returns metadata and its full content. [List files](/api-docs/files/list-files) returns metadata; use `path` when you know the exact location but not the ID.
Use [hybrid search](/api-docs/search/hybrid-search) to find relevant files by meaning, or [regex search](/api-docs/search/regex-search) to find matching lines. Search only returns content the key can read. Newly written content may take a moment to appear in search; direct reads and lists do not have that indexing delay.
Keys restricted to part of the repository may receive incomplete search results, including an empty response when readable matches exist. See [Search results with restricted access](/api-docs/search/hybrid-search#results-with-restricted-access).
## Protection and deletion
Protection routes content changes through review. Read [Updating content](/api-docs/updating-content) before implementing writes.
Deleting a file removes its change history and cannot be reversed through the API. Folder deletion requires `recursive=true` when the folder has contents. Confirm the intended scope before using recursive deletion; see the endpoint's error responses for conditions that prevent deletion.
# Create a file
Source: https://docs.qontext.ai/api-docs/files/create-file
api-reference/public-api.json POST /v1/files
Creates a file at the path given. Not an upsert: a path already holding a file is a conflict, so this never overwrites and never creates a duplicate. The response carries the `id` and the `lastChangeId`; later writes address those, because a rename moves the path.
# Delete a file
Source: https://docs.qontext.ai/api-docs/files/delete-file
api-reference/public-api.json DELETE /v1/files/{id}
Removes the file. Its change history goes with it, so this is not reversible through this API. A protected file, or one with changes still in review, is refused and nothing is removed, so a caller that did not mean to discard that work can deal with it first.
# Get a file
Source: https://docs.qontext.ai/api-docs/files/get-file
api-reference/public-api.json GET /v1/files/{id}
Answers the file and its full text. Together with `lastChangeId`, that is everything the content endpoint needs for the next write. The workspace is implicit in the API key and never appears in the URL. A file in another workspace answers as `file_not_found`, so existence does not leak.
# List files
Source: https://docs.qontext.ai/api-docs/files/list-files
api-reference/public-api.json GET /v1/files
Cursor paginated, never offset. A short page does not mean the end: items the key may not read are dropped after the page is read, so page until `hasMore` is false.
# Replace the content of a file
Source: https://docs.qontext.ai/api-docs/files/replace-file-content
api-reference/public-api.json PUT /v1/files/{id}/content
Replace the entire file content. Send the file's `lastChangeId` as `baseChangeId`. If the file changed first, the two versions are combined when possible. The response contains the content now saved; use it for the next edit.
# Rename, move, or protect a file
Source: https://docs.qontext.ai/api-docs/files/update-file
api-reference/public-api.json PATCH /v1/files/{id}
Send exactly one of `name` to rename in place, `parentId` to move, or `protected` to change whether changes to this file go to review. The id never changes, so ids held by a client stay valid; the path does. Sending two, or none, is rejected rather than resolved by a precedence rule: these are separate writes with no transaction across them, so a request doing two could apply the first and fail the second with no way to report which.
# Create a folder
Source: https://docs.qontext.ai/api-docs/folders/create-folder
api-reference/public-api.json POST /v1/folders
Creates one folder at `path`, creating missing parents, or directly inside `parentId` when sent with `name`. Not an upsert: a path already holding a folder is a conflict, so this never merges into an existing folder.
# Delete a folder
Source: https://docs.qontext.ai/api-docs/folders/delete-folder
api-reference/public-api.json DELETE /v1/folders/{id}
Refuses a folder that still has contents unless `recursive=true` is sent, in which case the whole subtree goes. The refusal changes nothing, so a caller that did not mean to delete the contents can read them first and decide.
# Get a folder
Source: https://docs.qontext.ai/api-docs/folders/get-folder
api-reference/public-api.json GET /v1/folders/{id}
The workspace is implicit in the API key and never appears in the URL. A folder in another workspace answers as `folder_not_found`, so existence does not leak.
# List folders
Source: https://docs.qontext.ai/api-docs/folders/list-folders
api-reference/public-api.json GET /v1/folders
Lists one folder by `path`, every folder below `path_prefix`, or direct children by `parent_id`. Without a selector it lists root folders. Cursor paginated, never offset. A short page does not mean the end: items the key may not read are dropped after the page is read, so page until `hasMore` is false.
# Rename or move a folder
Source: https://docs.qontext.ai/api-docs/folders/update-folder
api-reference/public-api.json PATCH /v1/folders/{id}
Send exactly one of `name` to rename in place, or `parentId` to move. A move takes the whole subtree and every id in it survives, so ids held by a client stay valid; the paths below it change. Sending both, or neither, is rejected rather than resolved by a precedence rule.
# Overview
Source: https://docs.qontext.ai/api-docs/overview
Build applications and workflows that read, search, and update your context repository.
The Qontext API gives your applications HTTP access to the files and folders in a workspace's context repository. Read existing context, search for relevant information, and create or update content from your own systems.
## Base URL
```text theme={null}
https://api.qontext.ai/v1
```
Authenticate with a workspace API key. The key selects the workspace, so requests do not include a workspace ID.
## Start building
Create a file and read it back with your first API requests.Create a key and configure access to your workspace.Read, create, update, move, and delete files.Organize files and manage folders.Find files by meaning or matching lines with a regular expression.Download the machine-readable contract for the public API.
## API or MCP?
Use the API when your application controls the requests and handles their responses. To give an AI agent tools for working with your context repository, connect it through [MCP](/interfaces/MCP).
The public API documented here covers files, folders, and search. The endpoint reference lists the supported operations and their exact request and response shapes.
# Pagination
Source: https://docs.qontext.ai/api-docs/pagination
List files and folders with cursor pagination and exact-path or parent filters.
File and folder lists use cursor pagination. Search accepts a result limit but does not support paging through further results.
## Read every page
```bash theme={null}
curl --fail-with-body --get https://api.qontext.ai/v1/files \
-H "Authorization: Bearer $QONTEXT_API_KEY" \
--data-urlencode "limit=100" \
--data-urlencode "path_prefix=/support"
```
The response has `object: "list"`, `url`, `data`, `hasMore`, and `nextCursor`.
1. Process the items in `data`.
2. If `hasMore` is `true`, send `nextCursor` as the next request's `cursor`.
3. Keep the same filters and continue until `hasMore` is `false`.
A short or empty page does not establish that the list is complete. Access controls can remove items from a page; use `hasMore` to decide whether to continue.
Treat cursors as opaque strings. Do not construct or parse them. Changing filters requires starting again without a cursor.
## Choose a selector
Use at most one selector per request:
| Selector | Files | Folders |
| - | - | - |
| None | All readable files | Root folders |
| `path` | File at the exact path | Folder at the exact path |
| `path_prefix` | Files below a folder, recursively | Folders below a folder, recursively |
| `parent_id` | Files directly in a folder | Folders directly in a folder |
An exact path with no matching item returns an empty list. It does not return a resource-not-found error.
`GET /v1/folders` is the one exception: a `parent_id` that names no folder returns `404 folder_not_found`. Every selector on `GET /v1/files`, and the other selectors on `GET /v1/folders`, return an empty list instead.
`limit` defaults to `100` and accepts values from `1` to `1000`. See [List files](/api-docs/files/list-files) and [List folders](/api-docs/folders/list-folders) for the complete parameters.
## Search results
Both searches use the list envelope, but return `hasMore: false` and `nextCursor: null`. The result limit caps one response; it is not a page size for a resumable search.
# Quickstart
Source: https://docs.qontext.ai/api-docs/quickstart
Create a Markdown file and read its content back using cURL, Python, or JavaScript.
Create a small file in your context repository, then read it back by ID.
## 1. Create an API key
In the [Qontext app](https://app.qontext.ai), open **Clients → API Keys** and select **+ Create API key**. Copy the key and store it as an environment variable:
```bash theme={null}
export QONTEXT_API_KEY="your-api-key"
```
The key needs permission to create and read files at the example path. See [Authentication](/api-docs/authentication) for access controls.
## 2. Create a file
This request creates `/api-example/hello.md`. Missing parent folders are created automatically.
```bash cURL theme={null}
curl --fail-with-body https://api.qontext.ai/v1/files \
-H "Authorization: Bearer $QONTEXT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"path":"/api-example/hello.md","content":"# Hello\n\nCreated with the Qontext API."}'
```
```python Python theme={null}
import json
import os
from urllib.request import Request, urlopen
request = Request(
"https://api.qontext.ai/v1/files",
data=json.dumps({
"path": "/api-example/hello.md",
"content": "# Hello\n\nCreated with the Qontext API.",
}).encode(),
headers={
"Authorization": f"Bearer {os.environ['QONTEXT_API_KEY']}",
"Content-Type": "application/json",
},
method="POST",
)
with urlopen(request) as response:
file = json.load(response)
print(file["id"])
```
```javascript JavaScript (Node.js) theme={null}
const response = await fetch("https://api.qontext.ai/v1/files", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.QONTEXT_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
path: "/api-example/hello.md",
content: "# Hello\n\nCreated with the Qontext API.",
}),
});
if (!response.ok) throw new Error(await response.text());
const file = await response.json();
console.log(file.id);
```
A successful request returns `201` and a file object. These are the fields you need next:
```json theme={null}
{
"id": "doc_9f2k1x8b3m7q0v",
"path": "/api-example/hello.md",
"lastChangeId": "chg_7t4p2w9c1n6s8k"
}
```
This is an excerpt; see [Create a file](/api-docs/files/create-file) for the full response. Save the returned `id` and `lastChangeId`.
Running the example again at the same path returns `409 path_already_exists`. Choose another path, or [find the existing file](/api-docs/files/list-files) with the `path` filter. Creating a file never overwrites existing content.
## 3. Read the file
Replace the example ID with the `id` returned by your create request.
```bash cURL theme={null}
curl --fail-with-body https://api.qontext.ai/v1/files/doc_9f2k1x8b3m7q0v \
-H "Authorization: Bearer $QONTEXT_API_KEY"
```
```python Python theme={null}
request = Request(
f"https://api.qontext.ai/v1/files/{file['id']}",
headers={"Authorization": f"Bearer {os.environ['QONTEXT_API_KEY']}"},
)
with urlopen(request) as response:
saved = json.load(response)
print(saved["content"])
```
```javascript JavaScript (Node.js) theme={null}
const read = await fetch(`https://api.qontext.ai/v1/files/${file.id}`, {
headers: { Authorization: `Bearer ${process.env.QONTEXT_API_KEY}` },
});
if (!read.ok) throw new Error(await read.text());
const saved = await read.json();
console.log(saved.content);
```
The Python and JavaScript examples continue from the previous step. The response includes the full `content` and the file's `lastChangeId`.
## Next steps
* [Update the file](/api-docs/updating-content) using the version you read.
* [Search your context](/api-docs/search/hybrid-search) by meaning. Newly written content may take a moment to become searchable.
* [Manage files and folders](/api-docs/files-and-folders) using stable IDs and paths.
# Search files by meaning
Source: https://docs.qontext.ai/api-docs/search/hybrid-search
api-reference/public-api.json POST /v1/search/hybrid
Finds the files that match your query and returns their content, best match first. Each result cites the file it came from. It also matches on meaning, which finds files that answer the query without using the same words. A result appears only if this API key can read the file. A new or changed file is not searchable straight away, so search again in a moment if you do not see it.
# Search lines with a regular expression
Source: https://docs.qontext.ai/api-docs/search/regex-search
api-reference/public-api.json POST /v1/search/regex
Finds lines that match an RE2 regular expression. Each result cites the file the lines came from. Results are not relevance-ranked. A result appears only if this API key can read the file.
# Updating content
Source: https://docs.qontext.ai/api-docs/updating-content
Replace file content safely and handle concurrent edits and changes awaiting review.
Read the file before editing it, then send the full new content together with the version you read.
## Read the base version
Call [Get a file](/api-docs/files/get-file). Keep its `content` and `lastChangeId` together: they represent the version your edit starts from.
## Submit the new content
Replace the example IDs with values from your file:
```bash theme={null}
curl --fail-with-body -X PUT \
https://api.qontext.ai/v1/files/doc_9f2k1x8b3m7q0v/content \
-H "Authorization: Bearer $QONTEXT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"baseChangeId": "chg_7t4p2w9c1n6s8k",
"content": "# Hello\n\nUpdated with the Qontext API."
}'
```
`baseChangeId` must be the `lastChangeId` of the version you edited. Sending a newer ID with content based on an older read loses that relationship.
## Handle the outcome
| Status | Meaning | Next step |
| - | - | - |
| `200` | The update was accepted. If another edit changed different sections, the versions may have been combined. | Keep the returned `content` and `file.lastChangeId` as the base for the next edit. |
| `202` | The change is in review. The submitted content has not replaced the live file. | Record the change ID and resolve it in the app. Do not resubmit the same change. |
| `4xx` or `5xx` | The request failed. | Inspect the error `code` and follow [Errors and limits](/api-docs/errors). |
A successful HTTP status does not always mean content was updated. Handle `202` separately from `200`.
A `202` response looks like this:
```json theme={null}
{
"object": "change",
"id": "chg_7t4p2w9c1n6s8k",
"status": "in_review",
"reason": "conflict",
"fileIds": ["doc_9f2k1x8b3m7q0v"],
"createdAt": "2026-08-01T14:03:00.000Z"
}
```
`reason` is `conflict` when edits cannot be combined automatically, or `protected` when protection requires review. `protected` takes precedence if both apply. See [Change reviews](/features/change-reviews) for resolving the change.
## Rename, move, or protect
Use [Update a file](/api-docs/files/update-file) for metadata changes. Send exactly one field per request: `name`, `parentId`, or `protected`. Content replacement uses its own endpoint.
Changing `protected` requires Full access. A key inheriting an owner’s or admin’s permissions can perform this operation. Directly assigned Can read or Can edit permissions do not allow it; use a permitted inheriting key or ask a member with Full access to change protection in the app. See [Access management](/features/access-management#access-controls-for-api-keys).
## Recover after an interrupted request
If the connection closes before a response arrives, the write may already have been processed. Inspect the live file and any changes in review before submitting again. The public API does not provide an idempotency-key parameter.
# Changelog
Source: https://docs.qontext.ai/changelog
Product updates, improvements, and API changes
## Resolve via chat
When a change conflicts with the current file, reviewers can open a context agent from the Changes tab to work through the conflict and apply a resolution. [Learn more](/features/change-reviews#resolving-a-change-via-chat).
* **Bulk discard**: Several changes in review can now be selected and discarded together.
* **Discard reasons**: The reason for discarding a change is visible in its details.
* **Change summaries**: Generated summaries are shorter and easier to scan.
* **Continuous updates**: Enabling them for the first time now shows an explanation before anything is scheduled.
* **Changes**: Long summaries and discard reasons no longer crowd the review dialog.
* **Invitations**: Removing an invitation that already expired no longer fails.
## Public API
Connect applications and workflows directly to a context repository with the Qontext API. Read, create, and update files, manage folders, and search the repository programmatically. [Learn more](/api-docs/overview).
## Qontext Tag
Qontext Tag brings a workspace's context repository into Slack. Mention `@Qontext` in a channel or thread to get an answer where the conversation is already happening. Follow-up questions retain the thread context, and workspace admins can control which files and folders Qontext Tag can read. [Learn more](/features/qontext-tag/slack).
* **Context agents**: Context agents can now use several capabilities in a single turn and reuse results from earlier turns instead of retrieving the same context again.
* **Slack sources**: Legacy message attachments are now included in syncs, and large channel histories are processed more reliably.
* **Skills**: Skills now flag when their folder name differs from the name in `SKILL.md`, with guidance on how to align them.
* **Continuous updates**: Continuous update settings remain enabled while navigating between source pages.
* **Context**: Deleting the currently open file now returns to Context.
* **File reading**: `qontext_cat` now accepts plain file paths such as `/notes/plan.md` directly.
* **Errors**: Tool failures now return structured errors with stable codes and clearer recovery guidance.
## Gong connector
Gong is now a supported data source. Connect Gong to sync structured call summaries into your context repository, including call details, participants, and linked CRM records. A configurable time window controls how much call history is included. [Learn more](/sources/gong).
* **Continuous updates**: Continuous updates can now be enabled for each source after its repository structure is ready.
* **Changes**: Context agents now add clear summaries to file and structure changes, visible in change reviews and file history.
* **File tree**: The file tree refreshes faster when several folders are expanded.
* **Context agents**: Follow-up messages can now be queued while a response is in progress and edited until they are sent.
* **File viewer**: Code blocks now use syntax highlighting, Mermaid code blocks render as diagrams with zoom and pan controls, and Markdown spacing is more consistent.
* **File versions**: Automated updates now show their data source, and version badges link to the corresponding change summary.
* **Salesforce**: Clearer connection setup and more reliable syncs for large Salesforce orgs.
* **Change reviews**: Long Markdown paragraphs now highlight only the changed words instead of the whole paragraph.
* **Context agents**: Chats now recover more reliably from expired sessions and app updates, without interrupting answers in progress.
## Linear connector
Linear is now a supported data source. Connect a Linear workspace to sync its issues, projects, and documents into a context repository, so agents can retrieve the planning context behind the work: what is being built, why, and where it stands. Qontext only reads data, and access stays bounded by the connected user's own Linear permissions. [Learn more](/sources/linear).
* **Access controls**: An Everyone row in the file and folder access panel sets the access level for the whole workspace in one place.
* **Access controls**: Clearer warnings when an edit would lower someone's access to a file or folder.
* **Skills**: `qontext skills add` now supports skills made up of multiple files, not only single-file skills.
## Change attribution
Knowing that a file changed is only half the story. File version history and the Changes page now show who made each change, naming the workspace member, connector, or agent behind it, so every version and pending change carries its author. [Learn more](/features/version-history).
* **Editor**: Folders can now be linked inside a file, the same as other files, and a link to a folder that no longer exists is flagged.
* **Sources**: After a source's filters are changed, a dialog offers to run a full resync so the new filters take effect.
* **Connection status**: A banner now appears when the app loses its connection, instead of leaving the page in an unclear state.
## Groups
Managing access one member at a time does not scale. Groups are named collections of workspace members, created and managed in Settings, that can be granted access to a file or folder in one step from the access picker. Owners and admins can create, rename, and delete groups, and change a group's members. [Learn more](/features/member-settings).
## Continuous updates (Early access)
A repository kept up to date by hand is outdated the moment the work stops. With continuous updates, every record a sync brings in triggers an agent that reads the repository and the relevant structure files, decides what to create, update, or leave alone, and records the result as a change. Continuous updates are in early access; contact [support@qontext.ai](mailto:support@qontext.ai) to enable them for a workspace. [Learn more](/features/continuous-updates).
* **Editor**: Formatting is kept when pasting Markdown into a file.
* **Editor**: The raw Markdown editing mode is now available when creating files, not only when editing existing ones.
## Context agents can ask questions
A context agent no longer has to guess when a request is ambiguous. It can pause and ask a multiple-choice question, shown as option cards in the chat, then continue once an option is picked or a different answer is typed. [Learn more](/features/context-agents).
## Live updates
The file tree and any open file now update as changes land, whether they come from a context agent, a sync, or another browser tab. File content refreshes in near real time, and the tree reflects additions, removals, and renames without a reload. [Learn more](/context-repository/ui).
* **File tree**: Files can now be created at the root of the repository, not only inside a folder.
* **API keys**: An API key can be rotated in place, replacing its secret without rebuilding its access configuration.
* **Member invites**: Invite links to the workspace can now be copied from the members table for direct sharing.
## Salesforce connector
Salesforce is now a supported data source. Connect a Salesforce org to sync its records into a context repository. Qontext only reads data, and access stays bounded by the connected user's own Salesforce permissions. [Learn more](/sources/salesforce).
* **Google Drive**: Google Drive now syncs PDF and Office files (`pdf`, `docx`, `xlsx`, `pptx`), selectable in the Filters tab.
* **Sources**: A Sync latest data action pulls the most recent data from a source on demand.
* **Editor**: Internal links pointing to a file that no longer exists are now flagged in the editor.
* **Changes**: A commit with no file changes now shows an empty state instead of a blank panel.
## Context agents
Turning scattered notes and source data into well-organized context is manual work. Context agents do it from a chat on the Context tab: describe what is needed and the agent builds folder structures, writes and edits files, and draws on connected sources, with every change versioned and shown in the Changes tab. [Learn more](/features/context-agents).
## Structure files
A self-maintaining repository is only useful if it stays organized. A structure file tells Qontext how a folder is organized, what belongs in it, how files are named, and how careful automatic updates must be, so new content lands where the team expects it. [Learn more](/features/structure-files).
## SharePoint connector
SharePoint is now a supported data source. Connect SharePoint sites to sync documents, site pages, and lists into a context repository, with SharePoint's own permissions always respected. Filters and incremental sync work the same as the other connectors. [Learn more](/sources/sharepoint).
* **MCP clients**: The list of connected MCP clients now shows every client, not only those authorized in the last 7 days.
## Raw Markdown editor
The rich editor is the fastest way to write, but sometimes it helps to work with the Markdown directly. A new toggle in the editor top bar switches any editable file to a raw Markdown view, frontmatter included, and back again. [Learn more](/context-repository/ui).
* **Cross-references**: Links between files are now stored by file, so they keep working when the target is renamed or moved. File and folder names are validated on create and rename, and saving a file that links to a missing file now shows a clear error.
* **Diff view**: A file created with no content now shows an empty-file state in the Changes diff instead of a blank panel.
* **Settings panel**: The file settings panel now closes when clicking into the editor.
## Change reviews
A context repository is written to from many directions: members editing files, connectors syncing data sources, and agents writing through the API and MCP server. Change reviews bring every pending change together on a new Changes screen, where each one can be compared against the current file and approved or rejected before it takes effect. Changes that do not conflict are reconciled automatically, so review is reserved for the edits that need a decision. [Learn more](/features/change-reviews).
## Protected files
Some files should never change without a second look. Turning on Require review in a file's settings protects it, so every change is sent for review before it merges, no matter where the change came from. [Learn more](/features/change-reviews).
* **Changes**: A count badge on the Changes item in the sidebar shows how many changes are waiting for review.
* **Changes**: Saving a file that needs review shows a banner linking to the pending change, and protected files are marked with a lock icon.
* **Saving files**: A reason for a change is now optional when saving.
* **Editor**: Version history and retrieval logs moved to a new full-width top bar, giving the editor more room.
* **File tree**: Folders can be renamed and moved directly in the file tree.
* **File tree**: Folders can be created at the root of the shared context tree.
* **Retrieval**: Hybrid search returns better results for conversational queries.
* **Retrieval**: Responses from the [`/v1/retrieval`](/api-docs/migration#previous-api-reference) endpoint are \~80% faster.
## Access controls on files and folders
Access to the files and folders in a context repository can now be restricted for both workspace members and the agents connecting to it, all from the Context screen. Permissions can be granted across the whole workspace, on a folder and all its descendants, or on a specific file. Access levels run from No access through Can read and Can edit to Full access, perfect to mirror how teams are actually organized. [Learn more](/features/access-management).
## Improved API key access controls
Newly created API keys can either inherit the access of the member who created them or be managed independently. Alongside the access set on an individual file or folder, the files and folders an independently managed key can access are also managed from a new Access Controls tab in the API key settings. [Learn more](/features/access-management).
* **Self-update**: `qontext update` updates the CLI in place to the latest release.
* **Version notice**: The CLI now warns once a day when a newer version is available.
## File version history
Every file in a context repository now keeps a version history, shown in the file sidebar. Each version lists its source, so connectors like Slack or Notion are named directly, while manual, MCP, and API-key updates appear as a workspace member. [Learn more](/features/version-history).
## MCP server access with API keys
The Qontext MCP server now accepts API keys in addition to OAuth. Clients connect by sending an `X-API-Key` header, and all MCP tools work for API-key callers. [Learn more](/interfaces/MCP).
* **MCP client usage logs**: MCP client details now include a Usage Logs tab showing past retrievals.
* **Member file deletion**: Workspace members can now delete any file in the workspace, not only files they created.
* **Editor blank lines**: The editor no longer shows blank lines as empty paragraphs.
* **Delete errors**: Deleting a file or folder without permission now shows a clear message instead of a generic error.
* **Longer sessions**: MCP sessions stay connected instead of expiring after a few minutes.
* **Multiple workspaces**: Fixed MCP tool calls failing for users who belong to more than one workspace.
## File and folder management
Folders can now be created and deleted directly in the file tree, including from its empty state. Files can be renamed, removed, moved, and dragged between folders. [Learn more](/context-repository/ui).
## Website source filters
Website data sources now show the Single Page and Deep Crawl options in their Filters tab, matching the other connectors. [Learn more](/sources/website).
* **Unsaved changes guard**: Leaving a file with unsaved edits now prompts before discarding, and drafts are kept so they survive a refresh.
* **File paths in usage logs**: API key usage logs now show file names, with the full path on hover.
* **Saving files**: Saving a file no longer removes blank lines.
## Create and edit files
Files can now be created directly from the file tree. The editor adds a slash command for inserting tables, headings, lists, and code, and links to other files can be added by searching for them inline. [Learn more](/context-repository/ui).
## Website source details
Website data sources now have a Details page, and any source can be enabled or disabled from it. [Learn more](/sources/website).
* **API key usage logs**: API keys now have a Usage Logs tab showing how each key has been used.
* **Loading states**: Smoother loading and empty states for the file tree and data sources.
* **Legacy tabs removed**: The legacy Vaults and Credentials tabs were removed.
## Safe concurrent edits
Writes to a context repository now go through a merge queue. When two changes to the same file happen at once, they merge automatically if they do not overlap, and are flagged for review if they do, so simultaneous writes can no longer corrupt a contextbase.
## Inline source filters
The Filters tab on each data source now has a working editor for Google Drive, HubSpot, Notion, Slack, and Confluence sources.
* **Visual polish**: New file and folder icons, and more consistent page spacing.
* **`hybrid_search` tool**: New tool for retrieving context from a workspace.
## Edit files in the UI
The file viewer is now a full editor. Files open in a markdown editor with a formatting toolbar and inline title editing, a message can be added when saving, and files can be deleted from the file detail page. [Learn more](/context-repository/ui).
## Sync history for data sources
The Syncs tab on a data source now shows a filterable history of past sync runs.
* **`qontext_mv`**: New tool to rename or move files.
* **`qontext_grep`**: New tool to search file contents.
## Markdown rendering
The file viewer now displays document frontmatter as a table instead of raw text, and renders Markdown tables properly.
## Context repositories
Qontext v1 introduces context repositories, a file-based view of all context in a workspace. A file tree and document viewer make it possible to browse and read every file, and the Context page is now the default view. [Learn more](/context-repository/overview).
## Per-file retrieval logs
Every file has a retrieval history showing when it was accessed and which MCP client or API key requested it. [Learn more](/features/retrieval-logs).
## API keys and MCP clients
API keys and MCP clients can now be managed from dedicated workspace pages, including creating and revoking keys and connecting MCP clients, with status and usage logs in one place.
## Workspace settings and user invites
Workspaces now have a dedicated settings area for managing the workspace name, URL, and members. Collaborators can be invited by email and assigned a role, and pending invitations can be revoked before they are accepted. [Learn more](/features/member-settings).
## Workspace skills
Skills can be installed and synced into a workspace through a CLI with a web-based approval flow. [Learn more](/features/skills).
* **Permission-aware controls**: Actions a user cannot perform are now disabled with a tooltip explaining why, and permission errors show a clear message instead of a generic failure.
* **File operations**: New `qontext_mkdir`, `qontext_write`, and `qontext_rm` tools let agents create folders, write files, and delete files.
* **`qontext_find`**: New tool to search for files.
* **Skills CLI**: New CLI to install and sync workspace skills.
# ChatGPT
Source: https://docs.qontext.ai/clients/chatgpt
Connect Qontext to ChatGPT
Connect Qontext to ChatGPT via MCP to use your context repository in ChatGPT conversations.
With Qontext + ChatGPT, you can:
* Retrieve relevant, up-to-date context when you invoke Qontext
* Keep full governance and permissions in Qontext
***
## Installation
Qontext is available as a plugin in ChatGPT and Codex. Install the published plugin, or connect Qontext manually over MCP.
In ChatGPT on the web or in the desktop app, open **Plugins**, search for **Qontext**, and select the Qontext plugin. You can also open the [Qontext plugin directly](https://chatgpt.com/plugins/plugin_asdk_app_698b701366a88191b74fc4a1cf9cf73f).
Click **Install plugin**.
If prompted, click **Connect**, log in to Qontext, and allow access.
This flow connects through OAuth. Qontext also supports [API-key authentication](/interfaces/MCP#connect-with-an-api-key) in MCP clients that accept bearer tokens or custom headers.
Open ChatGPT in your browser and log in. In the bottom left corner, click your profile and open **Settings**.
In Settings, choose **Security and login**.
Turn on **Developer Mode**.
Open **Plugins** from the ChatGPT sidebar and select the **+** button. Enter **Qontext** as the name and add a short description. Under **Connection**, use the following MCP server URL:
```text theme={null}
https://api.qontext.ai/mcp
```
Create the connection and review the tools and metadata ChatGPT discovers from the server.
When prompted, allow ChatGPT access to Qontext.
From now on, ChatGPT will use your context repository to retrieve context when you invoke Qontext.
***
## Using Qontext in ChatGPT
Once Qontext is connected, using it is simple:
Open a new conversation in ChatGPT.
Type **@Qontext** or **Use Qontext** in your message to let ChatGPT retrieve the context needed to give you the best answer.
Add your question or task and send the message.
ChatGPT automatically retrieves relevant context from your connected context repository to complete the task.
### Example prompts
```text theme={null}
@Qontext, what were the key takeaways from last week's sales meeting?
```
```text theme={null}
Summarize what we know about Acme Corp. @Qontext
```
```text theme={null}
@Qontext, draft a follow-up email to Charles Renner from ACME Inc.
```
```text theme={null}
@Qontext, find our pricing guidelines and help me draft a proposal.
```
***
## Troubleshooting
A few things to check:
* Open **Plugins** and confirm that Qontext appears among your installed plugins or MCP connections.
* Ensure **Developer Mode** is on under **Settings → Security and login** before creating a manual MCP connection.
* If your workspace manages plugins or Developer Mode, ask your workspace admin to confirm access.
Install Qontext from the plugin directory instead. In a managed workspace, ask your workspace admin whether Developer Mode is available.
***
## Need help?
If you encounter issues with the ChatGPT connection, reach out at [support@qontext.ai](mailto:support@qontext.ai).
# Claude
Source: https://docs.qontext.ai/clients/claude
Connect Qontext to Claude
Connect Qontext to Claude via MCP to bring up-to-date company context into Claude conversations.
With Qontext + Claude, you can:
* Bring relevant, up-to-date company context into your Claude conversations
* Keep full governance and permissions in Qontext
***
## Installation
Qontext is available as a remote connector in Claude, so you can add it in two ways: install it directly from Claude's connector directory, or add it manually as a custom connector. Once connected, Qontext is available in Claude on the web and in the desktop app without separate setup. For Claude's official connector documentation, see [Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp).
In Claude, click the **+** below the message box where you write your prompt.
Click **Connectors**, then **Browse connectors**.
Search for **Qontext** and click the **+**.
Once added, click **Connect** and log in to Qontext to allow access.
Launch **Claude** in your browser or desktop app.
Go to the **Customize** tab.
Select **Connectors**.
Click the **+** and select **Add custom connector**. If this option is unavailable, an Owner or Primary Owner must add Qontext under **Organization settings → Connectors**. Members can then connect it from **Customize → Connectors**.
Enter the following details:
| Field | Value |
| :- | :- |
| **Name** | Qontext |
| **MCP Server URL** | `https://api.qontext.ai/mcp` |
Once added, click **Connect** and log in to Qontext to allow access.
***
## Set up Qontext for your organization
On Claude Team and Enterprise plans, **Owners and Primary Owners** can add shared organization instructions that apply to everyone in the organization. This gives everyone a shared default for when Claude should retrieve context from Qontext.
In Claude, go to **Organization settings → Organization and access**.
Find **Organization instructions** and add something like:
> Use Qontext as the source of truth for company-specific context. Before answering or acting on tasks involving our products, customers, projects, policies, processes, terminology, or past decisions, retrieve the relevant context from Qontext.
Click **Save changes**.
***
## Using Qontext in Claude
Once connected, using Qontext is simple:
Open a new conversation in Claude.
Type your question or task as usual.
Add **"Use Qontext"** anywhere in your message and send.
Claude automatically retrieves the relevant context from your context repository to complete the task.
### Example prompts
```text theme={null}
Use Qontext. What were the key takeaways from last week's sales meeting?
```
```text theme={null}
Summarize what we know about Acme Corp. Use Qontext.
```
```text theme={null}
Use Qontext to find our pricing guidelines and help me draft a proposal.
```
***
## Need help?
If you encounter issues with the Claude integration, reach out at [support@qontext.ai](mailto:support@qontext.ai).
# Codex
Source: https://docs.qontext.ai/clients/codex
Connect Qontext to Codex
Connect Qontext to Codex via MCP to give your agents access to your context repository.
With Qontext + Codex, you can:
* Retrieve curated high-quality company context while coding
* Access product, customer, process, and project knowledge directly from Codex
* Keep governance and permissions in Qontext
***
## Installation
Qontext is available as a plugin in ChatGPT and Codex. Install it directly from the shared plugin directory, or add it manually as an MCP server in the ChatGPT desktop app. Both options connect to Qontext over MCP.
In the ChatGPT desktop app, open **Plugins**, search for **Qontext**, and select the Qontext plugin. You can also open the [Qontext plugin directly](https://chatgpt.com/plugins/plugin_asdk_app_698b701366a88191b74fc4a1cf9cf73f).
Click **Install plugin**. If Qontext is already installed for your ChatGPT account, it is also available in Codex.
If prompted, click **Connect**, log in to Qontext, and allow access.
A manually added MCP server can use OAuth or a Qontext API key. For API-key configuration and access controls, see [Connect with an API key](/interfaces/MCP#connect-with-an-api-key).
Open the ChatGPT desktop app, then go to **Settings → Plugins**.
In **Plugins**, open **MCP** and click **+ Add server**.
Choose **Qontext** as the name and **Streamable HTTP** as the protocol. Then use the following **MCP server URL**:
```text theme={null}
https://api.qontext.ai/mcp
```
For OAuth, leave the bearer-token and custom-header fields empty. For an API key, store the key in an environment variable and either enter that variable's name under **Bearer token env var**, or add `X-API-Key` under **Headers from environment variables** and use the variable name as its value. Click **Save**, then return to the MCP screen and click **Restart**.
If you chose OAuth, click **Authenticate** and log in to Qontext. Skip this step when using an API key.
When prompted, allow Codex access to Qontext. Skip this step when using an API key.
Start a new Codex task and type `/mcp` in the composer. Confirm that Qontext appears among the connected servers.
A manually configured MCP server is shared with Codex CLI and the IDE extension when they use the same Codex host.
From now on, Codex will use your context repository to retrieve context when you invoke Qontext.
***
## Using Qontext in Codex
After installing the plugin, start a new Codex task and ask Codex to use Qontext. For a manually configured MCP server, start a new task after restarting the desktop app.
Open a new task in Codex.
Type **@Qontext** or add **Use Qontext** to your question or task. Codex then retrieves the context needed to complete the task.
Codex automatically retrieves relevant context from your connected context repository to complete the task.
### Example prompts
```text theme={null}
Use Qontext and create a technical handover document for this feature.
```
```text theme={null}
Use Qontext and update the project file with the implementation status.
```
```text theme={null}
Use Qontext and create a new runbook for this deployment procedure.
```
***
## Need help?
If you encounter issues with the Codex integration, reach out at [support@qontext.ai](mailto:support@qontext.ai).
# Cursor
Source: https://docs.qontext.ai/clients/cursor
Connect Qontext to Cursor
Connect Qontext to Cursor via MCP to give your coding agent access to your context repository.
With Qontext + Cursor, you can:
* Retrieve curated, up-to-date company context while coding
* Access product, customer, process, and project knowledge directly from Cursor
* Keep governance and permissions in Qontext
***
## Installation
Qontext connects to Cursor as a remote MCP server. For Cursor's official MCP documentation, see [Cursor Docs](https://cursor.com/docs/mcp).
In Cursor, open the **Customize** page from the sidebar.
Go to **MCPs** and click **New MCP Server**. Cursor opens your `mcp.json` configuration file.
Add Qontext to the `mcpServers` object with the following configuration, then **save** the file:
```json theme={null}
{
"mcpServers": {
"qontext": {
"url": "https://api.qontext.ai/mcp"
}
}
}
```
Cursor lists the Qontext server with a login prompt. Click **Authenticate** and log in to Qontext to allow access.
From now on, Cursor will use your context repository to retrieve context when you invoke Qontext.
***
## Using Qontext in Cursor
Once the server is connected, using Qontext is simple:
Open a new conversation in Cursor's Agent.
Add **Use Qontext** to your question or task and send the message. Cursor then retrieves the context needed to give you the best answer.
Cursor automatically retrieves relevant context from your context repository to complete the task.
### Example prompts
```text theme={null}
Use Qontext and create a technical handover document for this feature.
```
```text theme={null}
Use Qontext to check our API guidelines before refactoring this module.
```
```text theme={null}
Use Qontext and update the project file with the implementation status.
```
***
## Need help?
If you encounter issues with the Cursor integration, reach out at [support@qontext.ai](mailto:support@qontext.ai).
# Gemini
Source: https://docs.qontext.ai/clients/gemini
Connect Qontext to Gemini via the Agent Development Kit for enterprise context in Google Cloud
Implementing an enterprise-grade connection between **Qontext** and **Gemini** using the **Agent Development Kit (ADK)** lets you provide LLMs with proprietary company context while keeping access secure and permissioned. This guide walks through the integration for Google Cloud: **Secret Manager** for credentials and **ADK Session State** for conversational memory.
## Prerequisites
* A [Qontext](https://app.qontext.ai) account with ingested data
* Access to [Gemini Enterprise](https://console.cloud.google.com/gemini-enterprise) in your Google Cloud project
***
## Installation
### Step 1: Infrastructure and security setup
Set up your Google Cloud project and secure credentials before writing agent code.
Open the [Google Cloud Console](https://console.cloud.google.com/) and create a new project or select an existing one from the project picker in the top bar.
In the left navigation go to **APIs & Services → Enabled APIs & services**, then enable:
* Vertex AI API
* Secret Manager API
* Discovery Engine API
* Generative Language API
* Gemini for Google Cloud API
* Cloud Resource Manager API
If you don’t already have one, [create an app in your project](https://console.cloud.google.com/gen-app-builder/engines).
Store your Qontext API key in Secret Manager so the agent can read them at runtime. Choose either the UI or the CLI.
1. In the left navigation, open **Security → Secret Manager**.
2. Click **Create secret** for each of the following:
* **Name:** `QONTEXT_API_KEY_SECRET` — value: your Qontext API key
* **Name:** `QONTEXT_VAULT_ID_SECRET` — value: your vault ID
3. Grant the agent’s service account access to these secrets:
* Go to **IAM & Admin → IAM**.
* Enable **Include Google-provided role grants** (checkbox at top right).
* Find the Vertex AI Reasoning Engine service agent (e.g. `service-PROJECT_NUMBER@gcp-sa-aiplatform-re.iam.gserviceaccount.com`) and ensure it has:
* **Secret Manager Secret Accessor**
* **Vertex AI Reasoning Engine Service Agent**
Connect your local machine to Google Cloud first: [install and initialize the gcloud CLI](https://cloud.google.com/sdk/docs/install) if needed, then run:
1. Grant your agent’s service account access to the secrets (replace `your-agent-sa` and `your-project` with your service account and project ID):
```bash Shell theme={null}
gcloud secrets add-iam-policy-binding QONTEXT_API_KEY_SECRET \
--member="serviceAccount:your-agent-sa@your-project.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
gcloud secrets add-iam-policy-binding QONTEXT_VAULT_ID_SECRET \
--member="serviceAccount:your-agent-sa@your-project.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
```
2. Log in to your Google account locally:
```bash Shell theme={null}
gcloud auth login # Log in to your account
gcloud config set project YOUR_PROJECT_ID # Set project ID (Find via service account email address)
gcloud services enable secretmanager.googleapis.com # Enable Secret Manager APIs
gcloud config list # Verify changes
```
3. Create the following two secrets:
```bash Shell theme={null}
gcloud secrets create QONTEXT_API_KEY_SECRET --replication-policy="automatic"
gcloud secrets create QONTEXT_VAULT_ID_SECRET --replication-policy="automatic"
```
4. Add the secret values (replace with your real API key and vault ID):
```bash Shell theme={null}
echo -n "your-api-key" | gcloud secrets versions add QONTEXT_API_KEY_SECRET --data-file=-
echo -n "your-vault-id" | gcloud secrets versions add QONTEXT_VAULT_ID_SECRET --data-file=-
```
***
### Step 2: Set up your local development environment
Prepare your machine for ADK development and the example agent.
Run the following to create a dedicated folder for your agent and isolate dependencies in a virtual environment:
```bash Shell theme={null}
mkdir qontext_agent && cd qontext_agent
python3 -m venv .adk_env
source .adk_env/bin/activate
```
Install the Agent Development Kit, Secret Manager client, and an async HTTP client:
```bash Shell theme={null}
pip install google-adk google-cloud-secret-manager aiohttp
```
Use the example agent and requirements file from the Qontext examples repository and add a .env file:
* [**agent.py**](https://github.com/qontext-ai/examples/blob/main/examples/gemini-agent/agent.py) — main agent logic and Qontext retrieval tool
* [**requirements.txt**](https://github.com/qontext-ai/examples/blob/main/examples/gemini-agent/requirements.txt) — dependencies for local and deployed runs
* **.env**: create a .env file in the same folder and save your project ID as `GCP_PROJECT_ID`
Download or clone these into your `qontext_agent` directory. Adjust the agent (e.g. functions, model, or prompt) to match your use case.
***
### Step 3: Local testing and debugging
Test the agent on your machine with the ADK web UI before deploying.
From the parent directory of your agent folder (so ADK can find the agent module), start the web interface:
```bash Shell theme={null}
adk web
```
Open [http://127.0.0.1:8000](http://127.0.0.1:8000) in your browser. Verify that:
* The agent responds to prompts
* It uses the correct Qontext vault
* Conversational memory works across turns (ADK session state)
* If you encounter any problems, reach out to [support@qontext.ai](mailto:support@qontext.ai)
***
### Step 4: Deploy to Vertex AI Agent Engine
After local testing, deploy the agent to Google Cloud’s managed runtime.
From your project root (one level above the agent folder), run:
```bash Shell theme={null}
adk deploy agent_engine \
--project=YOUR_PROJECT_ID \
--region=YOUR_REGION \
--display_name="qontext-agent-example" \
--requirements_file=qontext_agent/requirements.txt \
--adk_app_object=root_agent \
--env_file=qontext_agent/.env \
--trace_to_cloud \
qontext_agent
```
Replace `YOUR_PROJECT_ID` and `YOUR_REGION` (e.g. `europe-west1`).
Save the URL that appears in the command output. You will need it for the agent connection in Step 5 (Google Cloud / Gemini Enterprise).
***
### Step 5: Connect and go live
Connect your deployed agent to Gemini Enterprise so you can use it in chat.
In [Gemini Enterprise](https://console.cloud.google.com/gemini-enterprise), go to your project and region, then open the **Agents** tab for your app (the same app you used in Step 4).
Click on **Add agent** and choose **Custom agent via Agent Engine**.
On the Authorizations step, click **Next** to skip.
Give the agent a meaningful **name** and **description**. In the URL field, enter the **Agent Engine reasoning engine URL** that the CLI returned after Step 4 (when you ran `adk deploy agent_engine`).
Click **Create**. Your agent is then available in Gemini Enterprise. You can use it in chat by typing **@** and selecting your agent name (e.g. `@YourAgentName`).
***
Need Help? If you encounter issues with the Gemini integration, reach out to [support@qontext.ai](mailto:support@qontext.ai).
Also, check the [Vertex AI Agent Development Kit docs](https://docs.cloud.google.com/agent-builder/agent-engine/develop/adk) for more deployment and configuration options.
# Clients
Source: https://docs.qontext.ai/clients/index
Connect AI tools, agents, workflows, and applications to your context repository
## Overview
Connect AI tools to Qontext and give them access to your context repository.
Qontext supports two access methods:
* **MCP** for AI chats and agents that support the Model Context Protocol
* **API** for AI tools, workflows, agents, and custom applications that integrate directly with the Qontext API
Choose the clients you want to connect below.
***
## Company chats
Give your chats the context they need to answer reliably.
These clients connect through MCP or API and can retrieve, search, and update context from your context repository.
}
href="/clients/claude"
>
Connect via MCP for context-aware conversations.
}
href="/clients/chatgpt"
>
Connect via MCP for context-aware conversations.
}
href="/clients/langdock"
>
Connect via MCP in chats, agents, and workflows.
}
href="/clients/gemini"
>
Connect via the Agent Development Kit for context in Google Cloud.
***
## Coding agents
Help coding agents understand the business side.
Connect coding agents to product context, customer information, processes, documentation, and company knowledge.
}
href="/clients/codex"
>
Connect via MCP for context-aware conversations.
}
href="/clients/cursor"
>
Connect via MCP for context-aware conversations.
***
## Workflow builders
Use company context inside automations and operations.
Qontext provides verified integrations for leading workflow platforms, making it easy to integrate your context repository into custom applications, agents, and workflows.
}
href="/clients/n8n"
>
Verified workflow automation with file, folder, and search operations.
}
href="/clients/make"
>
Visual automation platform with custom app integration.
}
href="/clients/zapier"
>
Connect Qontext to 5,000+ apps with Zaps.
***
## Support agents
Power customer-facing agents with governed and up-to-date context.
***
## Build your own
Use Qontext as the context layer inside your own applications.
### **MCP**
If your application supports MCP, connect directly to the Qontext MCP server:
```text theme={null}
https://api.qontext.ai/mcp
```
Please refer to [MCP](/interfaces/MCP) for details.
### API
Use the Qontext API to:
* Read files and folders
* Search the context repository
* Create and update context
* Move, rename, and delete files and folders
Please refer to [API](/api-docs/overview) for details.
***
## Need a custom integration?
If you're building a custom AI tool or need help with a specific integration, reach out to our team at [support@qontext.ai](mailto:support@qontext.ai).
# Langdock
Source: https://docs.qontext.ai/clients/langdock
Connect Qontext to Langdock
Connect Qontext to Langdock via MCP to power conversations and automations with up-to-date company context.
With Qontext + Langdock, you can:
* Connect Qontext directly inside Langdock (chat, agent, or workflow)
* Automatically pull relevant, up-to-date context for every prompt
* Keep full governance and permissions in Qontext
* Use Qontext in **Chat**, **Agent**, and **Workflow** modes
***
## Installation
In your Langdock workspace, go to **Integrations** and click on **Add integration**. Then, choose **Start from scratch** to add a new MCP-based connection.
Choose **Connect remote MCP**. Add the Qontext MCP server URL and choose **OAuth 2.0** as authentication method:
**MCP server URL:**
```text theme={null}
https://api.qontext.ai/mcp
```
Add a logo, name and description to your MCP client. Leave the headers in step 3 empty and click on **+ Add connection** in step 4.
When prompted, complete the OAuth flow: log in to Qontext and allow Langdock to access your Qontext account.
Your connection should now test successfully. Make sure to select the retrieval tool to add it to your Langdock actions and save the configurations.
Open a new chat in Langdock and type **@Qontext** and select the Qontext integration and send your first prompt to it.
This will trigger the retrieval tool. To continue, select the correct connection and **confirm**.
Once connected, Qontext is available across Langdock Chat, Agent, and Workflows. You can use it in any of the three modes described below.
***
## Using Qontext in Langdock
If you haven't set up Qontext in Langdock yet, refer to the [Installation](#installation) steps above.
Qontext works in all three Langdock surfaces: **Chat**, **Agent**, and **Workflow**.
#### Chat
In **Chat**, you can retrieve context in a direct conversation so you always get answers based on up-to-date company context.
#### Agent
Add the **Qontext retrieval tool** as an action to your agent. Once added, the agent can automatically retrieve relevant context from your connected vault when users chat with it.
Search for the retrieval action from the Qontext integration and select it.
#### Workflow
In **Workflow**, you can either use an **Agent** node that has the Qontext retrieval tool as an action, or add the retrieval tool directly as a node.
***
### Example prompts
```text theme={null}
@Qontext. What were the key takeaways from last week's sales meeting?
```
```text theme={null}
Summarize what we know about Acme Corp. @Qontext.
```
```text theme={null}
@Qontext. Find our pricing guidelines and help me draft a proposal.
```
***
## Troubleshooting
Ensure the MCP client is configured with the correct URL (`https://api.qontext.ai/mcp`) and that you have saved and enabled the Qontext tools. Restart or refresh Langdock if needed.
Ask specifically for the URL to access your Qontext vault in the chat. If this does not work, start a new chat and repeat.
In the agent configurator, confirm that the Qontext action is added to the agent and that a connection (and workspace) is selected. In workflows, check that the agent node is configured to use the Qontext integration. Include in the prompt to use the retrieval tool.
***
## Need help?
If you encounter issues with the Langdock integration, reach out at [support@qontext.ai](mailto:support@qontext.ai).
# n8n
Source: https://docs.qontext.ai/clients/n8n
Read, write, and search your Qontext context repository in n8n
With Qontext + n8n, you can:
* Keep your context repository current from automated workflows
* Search company context by meaning or with a regular expression
* Give n8n AI agents tools to find, read, and update context
The [verified Qontext node](https://n8n.io/integrations/qontext/) is available on both **n8n Cloud** and **self-hosted** n8n instances.
***
## Installation
In your n8n dashboard, create a new workflow, select a trigger, and click **+** to open the Nodes panel.
Type **Qontext** in the search bar and select the verified node from the results.
Click **Install node** in the node details panel. An instance owner or admin must first install a verified node. After that, everyone on the instance can use it in workflows.
Select **File**, **Folder**, or **Search**, then choose the operation for your workflow.
Create an API key in the Qontext platform under **Clients → API Keys**. In n8n, add a **Qontext API** credential, paste the key, and leave **Base URL** set to `https://api.qontext.ai`.
The Qontext node is ready to use in your workflows and as a tool for n8n AI agents.
***
## Available resources
| Resource | Use it to |
| - | - |
| **File** | Create, read, update, organize, and delete files |
| **Folder** | Create, browse, organize, and delete folders |
| **Search** | Find files by meaning or match lines with an RE2 regular expression |
The API key determines the workspace. File and folder fields let you select an item by ID or from a list, and supported operations also accept a path.
See the [API Reference](/api-reference/introduction) for endpoint documentation and examples.
***
## Important behavior
* **Create is not an upsert.** If a file or folder already exists at the path, the operation returns a conflict instead of overwriting it.
* **Get Many uses cursor pagination.** Enable **Return All** to let the node follow every page automatically.
* **Update Content starts with Get.** Read the file first, then pass its `lastChangeId` into **Base Change ID** together with the complete new content.
**Update Content has two successful outcomes:**
* `object: "edit"` means the file was updated immediately. The response includes a `file` field.
* `object: "change"` means the update was held for review because the file is protected or conflicts with changes made after the workflow read it. This response does not include a `file` field.
Check `object` before a following node uses fields such as `$json.file`.
***
## Upgrading from 0.1.x
Version 1.0 replaced the previous Ingestion and Retrieval resources. Existing workflows using those resources must be reconfigured:
* Replace text ingestion with **File → Create**, or **File → Update Content** when the file already exists.
* Replace retrieval with **Search → By Meaning**.
* The API key now determines the workspace.
* Replace the saved credential with a new API key from **Clients → API Keys**. Keys created for 0.1.x do not work with version 1.0. Leave **Base URL** set to `https://api.qontext.ai`.
The previous website ingestion operation has no direct replacement in the Qontext node. A workflow can process website content with other n8n nodes and write the result into Qontext with **File → Create**.
***
## Using Qontext in n8n
Use Qontext as a regular workflow step or connect it to an n8n AI Agent as a tool. Common patterns include:
* Writing updates from a system of record into a structured folder
* Searching company context before drafting a support or sales response
* Letting an agent read a file, revise it, and write the new content back
* Listing every file below a path to review or report on a section of the repository
For custom HTTP requests, see the [public API documentation](/api-docs/overview).
***
## Need help?
If you need assistance setting up the Qontext node in n8n, reach out to [support@qontext.ai](mailto:support@qontext.ai).
# Managing files via MCP
Source: https://docs.qontext.ai/context-repository/MCP
Manage files via MCP to read, search, write, and organize your context
## Overview
Use [MCP](/interfaces/MCP) clients to let agents read, search, and update your context repository through structured tools. Qontext exposes a hosted MCP server at:
```text theme={null}
https://api.qontext.ai/mcp
```
Connect this server to tools like [Claude](/clients/claude), [ChatGPT](/clients/chatgpt), or your own MCP client to work with the same governed context that users see in the **Context** tab.
***
## Reading
MCP clients can list folders, inspect the repository structure, and read files directly.
Supported read operations include:
* List the contents of a folder
* Recursively browse a folder or the full context repository
* Read one or more Markdown files
* Resolve relevant context by file path before expanding into related files
***
## Searching
MCP clients can search across the context repository when the relevant file path is unknown.
Supported search operations include:
* Search file contents across the repository
* Find files by name, path, or content
* Use the `retrieval-tool` MCP tool for hybrid search, combining semantic relevance with exact matches
***
## Writing
MCP clients can create and update context programmatically, subject to the client’s access controls.
Supported write operations include:
* Create a new Markdown file
* Overwrite an existing file
* Create folders
* Rename or move files
* Delete files or folders
***
Qontext automatically logs queries executed by your MCP clients. The MCP access history for a given file can be viewed in the [Retrieval logs](/features/retrieval-logs) section of the UI.
# Organize your context repository
Source: https://docs.qontext.ai/context-repository/organization
Folder structures, file templates, and naming rules that keep context findable
## Overview
Three consumers read your folder structure:
* **People** browsing the **Context** tab.
* **Retrieval agents** traversing paths with `qontext_ls`, `qontext_find`, `qontext_grep`, and hybrid search.
* **Continuous update agents** placing each incoming record.
All three need the same thing: shallow folders with non-overlapping purposes, and one home per entity.
Qontext proposes a structure when your repository is first built. You can change it at any time.
***
## Recommended structure
Organize the top level by **ownership and lifecycle**, not by topic:
| Folder | Holds | Lifecycle |
| - | - | - |
| `agents/` | Reusable agent instructions and resources, including `skills/` | As long as agents use it |
| `company/` | Organization-wide knowledge: strategy, policies, positioning | Superseded, never closed |
| `teams/` | Responsibilities, processes, and relationships owned by one team | Ends when the responsibility moves |
| `projects/` | Initiatives with a defined outcome and end | Ends when the initiative does |
This resolves the ambiguous case: a customer account belongs to the team that owns it, while a time-boxed migration for that same customer belongs in `projects/` and links back to the account.
Matches the [repository root structure file](/features/structure-files#organize-the-repository-root) template.
**By business function instead.**
`engineering`, `growth`, `operations`, `product` works when every topic has one departmental home. It breaks as soon as work crosses functions, because a cross-team initiative then has several plausible homes.
***
## Principles
* **One entity, one primary record.** One file per customer, person, project, or topic. Search before creating; update rather than add a second record.
* **Link instead of copying.** References are returned inline as file IDs, so an agent follows a link straight into `qontext_cat`. A copy diverges silently; a link cannot.
* **Keep folder purposes non-overlapping.** When continuous updates are enabled for a source, its agents read the structure files of every folder that could hold a record. Where two folders both qualify, strictness decides placement, not your intent.
* **Name for retrieval.** Agents traverse paths before reading content. `teams/sales/customers/acme/overview.md` says what it contains; `teams/sales/docs/file-2.md` does not.
* **Create folders when content arrives.** Every empty folder is a path an agent must consider and rule out.
**Access boundaries follow your folder tree.**
Access widens deeper in the tree but never narrows — restricting a subtree means setting the narrower access on its parent. Content that only some members or [API keys](/features/access-management#access-controls-for-api-keys) should reach needs its own subtree from the start, not a restricted file inside an open folder. See [Access management](/features/access-management).
***
## Naming conventions
| Convention | Example |
| - | - |
| Lowercase with hyphens | `northstar-industries.md` |
| ISO date prefix on dated records | `2026-09-04-quarterly-review.md` |
| `overview.md` for an entity's primary record | `teams/sales/customers/acme/overview.md` |
| Name the entity, not its category | `jane-smith.md`, not `contact-1.md` |
| Preserve required names exactly | `SKILL.md`, `.qontext.structure.md` |
Date prefixes sort chronologically and make a record's period visible in a `qontext_ls` listing without reading it.
***
## Folder patterns
### Sales and customer knowledge
| Location | Contains |
| - | - |
| `customers/` | One folder per customer company |
| `pipeline/` | One folder per prospective company |
| `overview.md` | Status, owner, sources, snapshot, contacts, motivation, dated history |
| `meetings/` | One dated record per meeting |
| `support/` | One record per distinct issue |
| `contacts/` | One record per person |
| `rev-ops/` | Sales definitions and procedures shared across accounts |
Northstar has only `overview.md` because nothing else exists yet — the subfolders appear when content does.
One location per company. Let your CRM decide `pipeline` or `customers`; when the status changes, move the folder in the **Context** tab rather than creating a second record. Use the [sales structure file](/features/structure-files#aggregate-customer-knowledge) template to automate this layout.
### Projects
One primary home per cross-team project, linked from each team involved. Goal, owner, status, milestones, risks, and next steps go in `overview.md`; decisions and meetings get their own files. Use the [project summaries structure file](/features/structure-files#keep-project-summaries-current) template.
### Agent skills
One folder per skill, named to match the `name` in `SKILL.md`. Supporting files go in `references/`, `scripts/`, or `assets/` and load only when needed. Link to shared company knowledge rather than copying it into each skill. See [Skills distribution](/features/skills#organize-a-skill).
***
## File templates
Fictional examples. Adapt the sections, not the content.
### Entity overview
**Place at:** `/overview.md`
**Use when:** A customer, prospect, person, product, or team needs one record answering the common questions.
```md overview.md theme={null}
# Acme
| Metadata | Value |
| --- | --- |
| Status | POC |
| Owner | Maya Chen |
| Sources | HubSpot: Acme; Slack: #acme-x-qontext; Notion: [Weekly] Team check-out |
## Snapshot
One open POC in the Customers pipeline: a six-week test with Acme's support organization. The workspace holds roughly 400 files after one restructure. As of 2026-09-04, two groups and nine users are active.
## Contact person
Jane Smith — Head of Support: project sponsor and Qontext admin. Requested the separate testing workspace. Email: jane.smith@acme.example.
Tom Alvarez — role not recorded: joined the initial scoping meeting. Email: tom@acme.example.
## Why they want to work with us
Phase one gives support agents policy and account context from Salesforce and public Slack channels. Phase two tests whether the same layer serves the sales organization; the Head of Support has brought two engineers in to evaluate it.
## History
2026-09-05: Three users could not complete SSO login. Cause not confirmed; tracked as [SSO login failure](support/sso-login-failure.md).
2026-09-04: The [quarterly review](meetings/2026-09-04-quarterly-review.md) confirmed Salesforce and Slack as the initial sources.
2026-08-21: Acme restructured the repository and began testing. Retrieval was about 1.1 seconds across several hundred files.
## Other
Customers pipeline; POC; open; high priority.
Open support: SSO login failure affecting accounts created before 2026-08-20.
Recommended setup: repository default member access set to no access, department folders shared to groups.
```
An overview carries **durable state** — what is true now, and the dated history behind it. Action items and open questions belong in the [meeting record](#meeting-record) that raised them; here they go stale within days and lose their origin.
Mark what a source does not establish, in place: "role not recorded", "cause not confirmed". Otherwise an agent answering from this file presents your inference as fact.
### Meeting record
**Place at:** `/meetings/YYYY-MM-DD-.md`
**Use when:** A conversation produced decisions or actions that later work depends on.
```md 2026-09-04-quarterly-review.md theme={null}
# Quarterly review — Acme
**Date:** 2026-09-04
**Attendees:** Maya Chen, Jane Smith, Tom Alvarez
**Source:** HubSpot meeting note
## Decisions
- Salesforce and Slack are the initial sources for the pilot.
## Discussion
- Support volume has doubled since June; Acme wants agents to answer from account history.
- The sales expansion depends on a successful support pilot.
## Actions
- Maya: confirm the Salesforce scope by 2026-09-11.
- Jane: validate the SSO fix with three test users.
## Open questions
- Whether the sales expansion needs a separate agreement.
```
One meeting per file, and the home for action items and open questions — both stay tied to the conversation that produced them. Where the meeting exists in a source, link it and update this file when the source note changes.
### Decision record
**Place at:** `projects//decisions/YYYY-MM-DD-.md`
**Use when:** A choice constrains later work and its reasoning must outlive the people who made it.
```md 2026-09-02-authentication.md theme={null}
# Authentication for the customer portal
**Date:** 2026-09-02
**Status:** Accepted
**Owner:** Tom Alvarez
## Decision
Use the existing SSO provider for the customer portal instead of building a separate login.
## Context
Two options: extend the current SSO provider, or run a standalone identity service for external users.
## Reasoning
Extending SSO reuses the audited login path and avoids a second set of credentials. The standalone service would have supported per-customer branding, which no customer has asked for.
## Consequences
- External users need accounts in the SSO provider.
- Per-customer branding requires revisiting this decision.
## Supersedes
Nothing.
```
Mark a superseded decision and leave it in place rather than deleting it.
### Issue record
**Place at:** `/support/.md`
**Use when:** A distinct problem needs its own investigation thread, separate from the entity overview.
```md sso-login-failure.md theme={null}
# SSO login failure
**Status:** Open
**Reported:** 2026-09-05 by [Jane Smith](../contacts/jane-smith.md)
**Affects:** [Acme](../overview.md)
## Symptom
Three Acme users cannot complete SSO login. The provider returns a valid assertion and no session is created.
## Confirmed
- Reproduced for two of the three reported accounts.
- Only accounts created before 2026-08-20 are affected.
## Not confirmed
- Whether the provider's recent metadata change is the cause.
## Next steps
- Compare the assertion for an affected and an unaffected account.
```
The **Confirmed** and **Not confirmed** split is the point: an agent answering from this file must not pass an open hypothesis off as established.
***
## Anti-patterns
| Pattern | Failure | Fix |
| - | - | - |
| One company under both `customers/` and `pipeline/` | Two partial answers, neither current | One folder per company, moved on status change |
| A `misc/`, `general/`, or `docs/` folder | Nothing is decidably out of scope | Name folders by what belongs in them |
| `teams/sales/emea/enterprise/accounts/acme/` | Every level is another path to traverse | Keep only levels that carry meaning |
| A policy copied into several folders | Copies diverge; none is authoritative | One record, linked |
| Restricted content in an open folder | Access cannot narrow further down the tree | Give it its own subtree |
| Placeholder files and empty folders | Paths that return nothing | Create them when content exists |
| Dates inside the file but not in its name | Same-topic records collide in a listing | Prefix with the ISO date |
***
## Check your structure
Each case should have exactly one answer:
| Case | One correct home |
| - | - |
| A meeting note for an existing customer | That company's `meetings` folder |
| A prospect becomes a customer | The existing company folder, moved |
| A policy published in Confluence | The policies folder under `company` |
| A migration for one customer, staffed across two teams | `projects/`, linked from both teams |
| A reusable instruction set for an agent | Its own folder under `agents/skills/` |
| A person working at two accounts you track | One contact record, linked from both |
Two plausible homes means that boundary is not distinguishable yet. Tighten the folder definitions, then record the rule in the folder's [structure file](/features/structure-files).
***
## Set up your structure
In the **Context** tab, create your top-level folders. Every one is a boundary you will maintain, so keep the count small.
Add `/.qontext.structure.md` from the [repository root template](/features/structure-files#organize-the-repository-root). Root guidance is inherited by every folder, so shared conventions belong here and nowhere else.
Set restrictions on the parent of the subtree you want to limit. See [Access management](/features/access-management).
Give folders with their own rules — accounts, policies, projects — a [structure file](/features/structure-files) covering only what differs from the root.
Watch the **Changes** tab. Misplacements and duplicates point at a folder boundary that needs sharpening, not a missing folder.
***
## Prompts to get started
* "List my top-level folders and tell me which two have the most overlapping purpose."
* "Find companies that appear in both `customers` and `pipeline`, and propose which record should survive."
* "Which folders contain no files, or only a single placeholder file?"
* "Draft an `overview.md` for `teams/sales/customers/acme` from everything you can find about Acme."
# What is a "Context Repository"?
Source: https://docs.qontext.ai/context-repository/overview
What the context repository is and how it works
## Overview
Your **context repository** is the structured company context Qontext builds for your workspace.
It contains normalized Markdown files organized in a folder tree, for example customers, employees, products, projects, and processes. Each file captures shared context about one entity or topic and can reference source objects and related files. Depending on your guidance, a file can synthesize information from several sources or preserve a source document word for word.
Each workspace has one context repository. It updates continuously as connected sources change.
***
## What a context repository looks like
The context repository is organized as files and folders. Each file contains structured facts, relationships, source references, and metadata extracted from your connected sources.
Example structure:
When your repository is first created, Qontext proposes a folder structure based on your connected sources.
You can review and adjust the folder structure before it is finalized and alter it anytime.
See [Organize your context repository](/context-repository/organization) for a recommended folder structure, naming conventions, and file templates you can adapt to your company. Use [structure files](/features/structure-files) to tell Qontext how each folder should be maintained.
You can edit files and folders manually [via the UI](/context-repository/ui) or [via MCP](/context-repository/MCP), and Qontext can continue updating them as source data changes.
***
## How the context repository is built and updated
Detects key entities like people, companies, and concepts.
Connects related entities across your data sources.
Builds a context graph that reflects real-world relationships.
Keeps your context current as connected sources change.
***
## Why the context repository matters
* **One shared context layer:** Store company context once and expose it consistently to agents, MCP clients, APIs, and workflows.
* **Agent-readable structure:** Provide agents files, folders, references, and metadata instead of fragmented source data.
* **Relationship-aware retrieval:** Let agents follow connected context instead of relying on isolated search results.
* **Governance:** Control which users and clients can access which context.
* **Operational reliability:** Reduce duplicated, stale, or conflicting context across tools.
***
## FAQ
It depends on data volume. Small workspaces typically complete in minutes; large ones with many sources can take more time .
Yes. You can browse and edit any file in the context repository from the [Qontext app](https://app.qontext.ai). See [here](/context-repository/ui) for details.
# Managing files via the UI
Source: https://docs.qontext.ai/context-repository/ui
View, create, edit, and review retrieval logs for files in Qontext
## Overview
A file in Qontext is a structured context object inside your context repository. It captures normalized, shared context about one core entity, for example a customer, product, project, process, or deal.
Files are versioned, governed, and continuously updated from connected sources. They can reference source objects and link to related files. Therefore, agents can follow entity, temporal, semantic, and causal relationships across your context repository.
***
## Viewing files
Files are available in the **Context** tab.
The context repository is shown as a folder tree. Selecting a file renders its Markdown content in the detail panel.
### Relationships and links
Files are connected through explicit references between entities, facts, and source objects. This enables:
* **Targeted context:** Load the most relevant file first, then follow links only when more context is needed.
* **Graph traversal:** Follow entity, temporal, semantic, and causal relationships across files.
* **Single source of truth:** Update context once and reuse it across clients, APIs, and workflows without duplicate copies.
### Retrieval logs
Each file includes retrieval logs showing when it was accessed and how.
Logs are scoped to the selected file and include access types such as listed or read. This helps you see what an AI agent accessed, trace outputs back to specific context, and identify the most impactful files on AI responses.
***
## Creating files
In the **Context** tab, select the folder where you want the file to live, then choose **Add → New file**. To create a file directly in the workspace root, use **Create file or folder** above the tree and select **New file**.
The new file opens in the editor. Rename it and add your content, then click **Save**, optionally add a reason, and confirm.
***
## Moving and renaming
* **Files:** Open **File settings** to change the file's **Name** or **Location**. Select **/** as the location to move it to the workspace root.
* **Folders:** Select the folder and open **Settings** to change its **Name** or **Location**. Moving a folder also moves everything inside it. Select **/** as the location to make it a top-level folder.
***
## Editing files
Open the **Context** tab and select a file from the repository tree.
Update content using the formatting toolbar or Markdown shortcuts.
Click **Save**, optionally add a reason, and confirm to finalize the edit.
Additionally, you can:
* **Rename** files directly in the editor by changing the title and confirming the update.
* **Delete** a file directly in the Qontext app by using the delete action and confirming it. Deletion is permanent.
* Switch to the **raw Markdown editor** via the selector at the top right to edit the raw Markdown directly.
# Access management
Source: https://docs.qontext.ai/features/access-management
Control access to files and folders for users, API keys, and Qontext Tag
## Overview
Access controls decide who can **read, edit or change permissions to each file and folder** in your context repository.
They apply to three kinds of principals:
* **Users**: workspace members
* **API keys**: credentials used by Clients and agents to access your context repository
* **Qontext Tag**: the read-only Client that answers questions from the context repository in Slack
Access controls build on role-based, workspace-wide permissions. Roles (**Owner**, **Admin**, **Member**) set a baseline for the whole workspace; access controls refine that baseline down to individual files and folders. See [Member settings](/features/member-settings) for how roles work.
***
## Access levels
Every grant is one of four levels.
| Level | What it allows |
| - | - |
| **No access** | Cannot see or retrieve the file or folder |
| **Can read** | Read and retrieve content only |
| **Can edit** | Read and change content |
| **Full access** | Read, edit, and manage access (grant or revoke access for others) |
***
## How access is inherited
Access is evaluated as a chain, from the top of the repository down to the file or folder you are looking at:
1. The **workspace baseline** set by each member's role
2. The access set on each **parent folder**, from the outermost folder inward
3. The access set on the **file or folder** itself
The most specific grant wins. Granting access on a folder applies to everything inside it, so you can manage a whole folder subtree in one place and refine individual files or subfolders where needed.
**Access can be widened deeper in the tree, not narrowed.**
A file or folder can grant *more* access than it inherits, but it cannot take away access that was granted higher up. To restrict a folder subtree, set the narrower access on the parent folder.
***
## Access controls for users
Every member gets a default level of access across the whole repository. You can then customize access for individual files and folders on top of that default.
### Default access
The access that applies across the repository by default is managed in your **context repository settings**. Set it once here, and every file and folder inherits it unless a more specific grant overrides it.
Open your **context repository settings**.
Choose **Can read**, **Can edit**, or **Full access**, or set **No access** to remove the default grant.
### Customize access for a file or folder
Grant individual members access to a specific file or folder. This is how you give a group **Can edit** on its own area of the repository while keeping everyone else at **Can read**, or hide a sensitive folder from everyone except its owners.
Access for a file or folder is managed in the **Access management** section of its settings.
In **Context**, open the settings of the file or folder you want to manage.
Add a member or change the level of one already listed.
Choose **Can read**, **Can edit**, or **Full access**, or set **No access** to remove the grant.
**Roles still apply.**
Access controls build on top of workspace roles. A member's role sets their baseline across the workspace; default, folder, and file access refine it. See [Member settings](/features/member-settings).
**Groups**
Members can be organized into [groups](/features/member-settings#managing-groups): named collections of workspace members. Support for granting a group access to files and folders is rolling out, so you can manage access for a whole group at once instead of member by member.
***
## Access controls for API keys
An API key's access decides what the clients and agents using it can retrieve and change. When you create a key, you choose how it gets that access:
* **Inherit permissions**: the key inherits its creator’s permissions and stays in sync as those permissions change. This is the default. A key inheriting an owner’s or admin’s permissions can also manage file protection.
* **Manually manage**: set the key's access yourself, so it is independent of any user. A manually managed key can hold different levels on different files and folders, letting you scope each client to exactly the context it needs.
### In API key settings
Use this when you are working from a key and want to decide which parts of the repository it can reach. This is the per-key view of everything you would otherwise set file by file.
Open **Clients** and select the API key you want to manage.
Go to its **Access Controls** tab to see every file and folder the key can reach.
Add a file or folder and choose **Can read** or **Can edit**, or change an existing grant.
### In file / folder settings
Use this when you are working from a file or folder and want to decide which keys can reach it.
API keys appear in the same **Access management** section as users.
In **Context**, open the settings of the file or folder and go to **Access management**.
Add a key or change the level of one already listed.
Choose **Can read** or **Can edit**, or set **No access** to remove the grant.
**Direct grants and inherited permissions differ.**
Permissions assigned directly to a key are limited to **Can read** or **Can edit**. This limit does not cap inherited permissions: a key inheriting an owner’s or admin’s permissions can perform operations that require **Full access**, including changing file protection.
***
## Access controls for Qontext Tag
Qontext Tag has its own read-only access to the context repository. Its access does not change based on the permissions of the person asking a question in Slack.
Open **Clients** and select **Qontext Tag**.
In the access card, grant **Can read** across all files and folders or choose individual files and folders.
Qontext Tag can answer only from the files and folders it can read. Its replies are visible to everyone with access to the Slack channel where the question was asked. See [Qontext Tag in Slack](/features/qontext-tag/slack) for installation and usage.
# Change reviews
Source: https://docs.qontext.ai/features/change-reviews
Review changes to protected files before they're applied
## Overview
Change reviews let you approve or discard changes to a file before they're applied to your context repository. Use them to keep sensitive files under human control while everything else stays self-maintaining.
Reviews happen in the **Changes** tab. Select a change from the list to review it.
***
## Requiring review
Review is set per file. Open a file's settings and turn on **Require review**. From then on, any change to that file is held for review instead of being applied automatically.
Requiring review is a governance control, so it's available to members who can manage access on the file.
***
## Reviewing a change
The **Changes** tab has two lists:
* **To review**: changes waiting for a decision
* **Completed**: changes that were approved, discarded, or cancelled
Each change shows a **change summary** with an explanation of the change, its status, when it was created, and the sources it's based on, followed by the file diffs.
A change is one of two types:
* **Automated change**: produced from a connected [source](/sources)
* **Manual update**: a direct write to the file, made in the platform or through MCP or the API
***
## Approving or discarding
For a change that's in review, you can:
* **Accept changes**: the change is applied to the file
* **Discard**: the change isn't applied. A reason is required and kept on the record for that change.
Multiple changes in **To review** can be selected and discarded together using Cmd + click. Discard reasons are visible in the details of completed changes.
If the files in a change are deleted before it's reviewed, the change is cancelled automatically and no review takes place.
***
## Resolving a change via chat
If a change conflicts with the current file, **Accept changes** points to **Resolve via chat**. Open it from the change in the **Changes** tab to start a conversation with a context agent.
The agent can compare the proposed change with the current file, ask how to handle conflicts, and confirm the combined text before applying the resolution. The resolved change then appears in **Changes**.
# Context agents
Source: https://docs.qontext.ai/features/context-agents
Agents that create, edit, and synthesize context in your repository
## Overview
Context agents create and edit files in your context repository from a chat prompt. Open the chat on the **Context** tab, describe what you want, and the agent does the work: it builds folder structures, writes and edits files, and moves or removes what's outdated.
Context agents also have access to your synced data. That means you can prompt them to replicate, aggregate, or synthesize context from your connected [sources](/sources): for example, turning scattered source documents into one curated file.
Every edit a context agent makes is a regular change to the repository: versioned, visible in the **Changes** tab, and held for review on files that require it.
***
## Opening the chat
Context agents work inside the context repository, so the chat is available on the **Context** tab only.
The chat icon sits in the top right corner. Clicking it opens the chat as a side panel next to your files. Drag the divider to resize it.
Type what you want done and send it. If you have a file open, the agent knows which one, so "summarize this file" just works.
***
## What context agents can do
Browse folders, read files, and search the repository by meaning or by exact text.
Create folders, write new files, edit existing ones, move files, and delete what's no longer needed.
Search and read the raw artifacts synced from your connected sources, beyond what's already curated in the repository.
Combine repository files and synced data into new context: replicate a document, aggregate scattered notes, or distill many sources into one file.
Some prompts to start with:
* "Summarize everything our synced sources say about the ACME account into one file under /Customers."
* "Create a folder structure for our sales playbooks and move the existing playbook files into it."
* "Compare this file against the latest synced data and update anything that's outdated."
***
## How edits land in the repository
Context agents never bypass the repository's governance. Every edit is recorded as a change:
* It appears in the **Changes** tab with a change summary and file diffs.
* It creates a new [file version](/features/version-history), so you can always look back or restore.
* On files with **Require review** turned on, the change is held for [review](/features/change-reviews) and only applied once someone accepts it. All other changes are applied automatically.
***
## Permissions
A context agent acts with your permissions and never beyond them. It can only read files you can read and edit files you can edit; anything outside your access is invisible to it. Access to synced data is checked the same way.
**Permission-aware by design.**
Two members can send the same prompt and get different results, because each agent only sees what its user is allowed to see. See [Access management](/features/access-management).
***
## Working in a conversation
Responses stream in live, and the agent shows its work: each action it takes, like reading, searching, or writing files, appears in the transcript and can be expanded to see the details. Files the agent mentions are linked, so you can jump straight to them in the repository.
While a response is in progress, another message can be written and queued. The queued message remains editable until the current response finishes, then sends automatically.
When a request is ambiguous, the agent can pause and ask a multiple-choice question in the chat; choose an option card or type a different answer, and it continues from there.
You stay in control while it runs:
* **Stop** an in-flight response at any time; the partial answer is kept.
* **Start a new chat** with the plus button in the panel header.
* **Resume past conversations** from the chat dropdown; conversations are saved per member.
# Continuous updates
Source: https://docs.qontext.ai/features/continuous-updates
Continuously check your sources and work every relevant change into your context repository
**Early access.** Continuous updates are not generally available yet. Contact [support@qontext.ai](mailto:support@qontext.ai) to enable them for your workspace.
## Overview
Company knowledge doesn't stand still: deals progress, decisions are made, documents change. A repository you'd have to update by hand would be outdated the moment you stop. Continuous updates are what make the context repository self-maintaining.
Each source can run continuous updates after its initial sync. When **Continuous updates** is enabled for a source, every new or changed record from later syncs triggers an agent. The agent reads your repository and the structure files of the folders that could hold that record, decides what to create, update, or leave alone, and records the result as a change.
Continuous updates are disabled by default for new sources. Open the source and turn on **Continuous updates** under **Key information** once the repository structure is ready. Only owners, admins, and the source creator can change this setting.
***
## How it works
Each connected [source](/sources) syncs on its schedule. The initial sync imports the source data whether continuous updates are enabled or not.
After the initial sync, new or changed records trigger an agent only while **Continuous updates** is enabled for that source. A sync that brings nothing changes nothing.
The agent looks at the folders that could hold the record and reads their [structure files](/features/structure-files), including guidance inherited from parent folders and the workspace root. That guidance says what belongs where, how files are named, and how sure the agent has to be before touching anything.
The agent updates the file the record belongs to, or creates one where your structure says it belongs. It can also delete or reorganize where the folder's guidance allows it. If the record clears no folder's strictness bar, the agent skips it and explains why, rather than forcing a fit or inventing a folder for it.
Nothing is silently overwritten. Every update and every new file goes through the same change process as any other edit.
**Folder structure files.**
The structure files carry your instructions for a folder: what belongs in it, how files are named, and how careful the agent has to be before changing anything. Whatever you leave unsaid, the agent decides on its own. Read more about them [here](/features/structure-files).
```md .qontext.structure.md theme={null}
---
strictness: firm
---
One file per customer, named after the company.
Meeting notes belong in the Meetings subfolder.
```
Change a structure file while updates are running and the new guidance applies from the next time the agent reads it, which means to every record it has not processed yet.
***
## Reviewing continuous updates
Every continuous update appears in the **Changes** tab as an **Automated change**, with a change summary, file diffs, and the sources it's based on, linked so you can trace each update back to the underlying data.
* Each update creates a new [file version](/features/version-history), so you can always look back or restore.
* On files with **Require review** turned on, updates are held for [review](/features/change-reviews) and only applied once someone accepts them. The same happens when an update conflicts with a concurrent edit.
* All other updates are applied automatically.
***
## Update frequency
For a source with continuous updates enabled, its **sync frequency** determines how often Qontext checks for changes and can start an agent. To get fresher updates from a specific source, raise its sync frequency in the source's settings.
# Member settings
Source: https://docs.qontext.ai/features/member-settings
Workspace roles, permissions, and managing members
## Overview
Each workspace has role-based user permissions.
Every member is assigned one role: **Owner**, **Admin**, or **Member**. The role defines what they can view, create, update, and delete across the workspace.
***
## Roles
| Role | Description |
| - | - |
| **Owner** | The workspace creator. Has full control over all resources, including deleting the workspace itself. There is exactly one owner per workspace. |
| **Admin** | A trusted manager. Can invite and remove members, change roles, and manage all shared resources. |
| **Member** | A regular collaborator. Can create and use resources, but can only update or delete the things they created themselves. |
***
## Permissions by resource
### Workspace
**Creators have full permissions to their own resources.**
The member who created a resource (e.g. connector credential, source, API key, etc.) can always update and delete it, regardless of their workspace role.
***
## Managing memberships
Owners and admins can manage workspace members in **Settings → Members**.
### Inviting workspace members
Open **Settings** and go to the **Members** tab.
Enter the email address of the person that should be invited and select the appropriate role.
The invitee receives an email link to join the workspace.
If the email does not arrive, open the member's action menu and choose **Copy invite URL** or **Resend invitation**.
### Removing workspace members
Open **Settings** and go to the **Members** tab.
Find the member you want to remove and open their action menu.
Select **Revoke access** and confirm the deletion in the modal opening up.
### Changing a workspace member's role
Open **Settings** and go to the **Members** tab.
Find the member whose role you want to change and open their action menu.
Select the new role: **Admin** or **Member**.
**Admins cannot demote themselves.**
An admin can change the role of other admins, but cannot demote their own account. If you need to change your own role, contact the workspace owner.
***
## Managing groups
Groups are named collections of workspace members. Use a group to manage a set of people together (for example a team or department) instead of one member at a time.
Owners and admins can manage groups in **Settings → Groups**.
### Creating a group
Open **Settings** and go to the **Groups** tab.
Select **Create group** and give the group a name.
Confirm to create the group. You can add members to it next.
### Adding and removing members
Open **Settings → Groups** and select the group you want to edit.
To add people, use the member field to add one or more workspace members. Only existing workspace members can be added to a group.
To remove someone, open their action menu in the group's member list and select **Remove**.
### Renaming or deleting a group
Open the group in **Settings → Groups**.
Rename the group from its settings, or use **Delete group** to remove it. Deleting a group does not remove its members from the workspace.
**Only owners and admins can manage groups.**
Members can belong to groups, but cannot create, rename, delete, or change the membership of a group.
# Native connectors
Source: https://docs.qontext.ai/features/native-connectors
Connect tools via connectors to sync data into Qontext
## Overview
Native connectors connect Qontext to the tools where your company context lives.
Each connector keeps selected source data up to date in the Qontext platform through syncs. This data is then used to create and continuously update your context repository. Sync logs in the platform let you monitor runs and troubleshoot.
Native connectors include tools such as [HubSpot](/sources/hubspot), [Google Drive](/sources/google-drive), [Notion](/sources/notion), and [Slack](/sources/slack). When a native connector is not available, use the API to send source data into Qontext programmatically.
***
## Connect a data source
To add a data source, open the **Sources** tab in the Qontext platform and click **Connect data source**.
You can set filters per data source to control what data gets synced.
For setup instructions for a specific connector and a roadmap for our upcoming connectors, please refer to the [Sources](/sources/index) section.
***
## Sync logs
Each connected source has its own sync logs in the **Sources** tab of the Qontext platform.
Use them to see when a sync started and finished, whether it failed, which items were skipped, and which source triggered the sync.
***
## When no native connector exists
* **Use MCP:** Connect an MCP client to write and manage context directly in your repository.
* **Use the API:** Create an API key under **Clients**, then write custom data into your context repository from your own scripts or workflow tools such as [n8n](/clients/n8n) and [Make](/clients/make).
* **Request a native connector**: To request a connector we don't offer yet, submit a request [here](https://tally.so/r/mVkKMj). We will try our best to build a connector for you.
***
## Best practices
**Prefer native connectors when available**
They keep the context repository in continuous sync with minimal setup. Use [Sources](/sources/index) to see which native connectors are available.
**Use MCP or API when no connector exists**
You can also bring data in through **self-built pipelines**: workflow tools such as [n8n](/clients/n8n) or [Make](/clients/make), or custom scripts, can write into your context repository until a native connector is available.
**Monitor sync logs**
Check sync logs after large or first-time syncs to confirm success and spot configuration or permission issues early.
***
## FAQ
In **Sync settings**, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch. If the issue persists, contact [support@qontext.ai](mailto:support@qontext.ai), so that we can resolve the issue.
It depends on the data volume of your sync. Initial syncs with large amounts of data can take up to 12 hours. Subsequent syncs process incremental changes and typically complete much faster than the initial sync.
# Qontext Tag in Slack
Source: https://docs.qontext.ai/features/qontext-tag/slack
Ask your context repository from any Slack channel
## Overview
**Qontext Tag** puts Qontext inside a tool your team already works in. In Slack, you tag `@Qontext` in a channel or a thread and it answers from your [context repository](/context-repository/overview).
The answer to most questions asked in Slack already exists somewhere: a document, a CRM record, an earlier thread. Finding it means leaving the conversation or interrupting whoever knows. Qontext Tag answers in place, from one source that stays current.
Slack can also work in the other direction. As a **data source**, Slack syncs messages and thread replies from the channels you choose into your context repository. See [Slack as a data source](/sources/slack).
***
## Install Qontext for Slack
In the [Qontext app](https://app.qontext.ai), go to **Clients** and select **Qontext Tag**.
Click **Add to Slack**, review the requested permissions on Slack's consent screen, and click **Allow**.
In Slack, type `/invite @Qontext` in each channel where it should answer.
You need a Qontext workspace, and a Slack admin or a member permitted to install apps.
***
## How it works in Slack
Add `@Qontext` to a question in any channel or thread it belongs to. It searches your context repository and answers as a threaded reply. Follow-up questions in the same thread keep context.
| Use case | Example |
| - | - |
| Settle a question without interrupting anyone | `@Qontext do we have a standard answer for the SOC 2 question in RFPs?` |
| Check what was already decided | `@Qontext what did we agree on for the Acme renewal?` |
| Look up a process mid-conversation | `@Qontext which onboarding steps apply to an enterprise customer?` |
| Brief yourself before a call | `@Qontext summarize where we stand with Acme` |
***
## What Qontext Tag can do
* Answer from the files and folders it can access, in the thread where you asked
* Answer in any channel it has been added to
* Hold a conversation: follow-ups keep context
Its boundaries:
* **Read-only.** It never changes your context repository. To write context, use the [Qontext app](https://app.qontext.ai), the [API](/api-docs/overview), or an [MCP client](/interfaces/MCP).
* **It only posts its own replies.** It never edits or deletes anything in Slack.
* **Slack history is not automatic.** It answers from Slack conversations only if you sync those channels as a [data source](/sources/slack).
Workspace admins control which files and folders Qontext Tag can read from **Clients > Qontext Tag**. These access controls apply to Qontext Tag itself, not separately to each person asking in Slack. Answers are posted where the question was asked, so everyone with access to that channel can see them.
***
## Privacy & security
* In Slack, Qontext only sees the channels you add it to.
* All data is encrypted in transit (TLS) and at rest.
* ISO 27001 certified and GDPR-compliant, hosted in the EU (AWS Frankfurt), with on-premise deployment available.
* Your data is never used to train or fine-tune AI models.
[Privacy policy](https://qontext.ai/legal/privacy-policy) · [Security](https://qontext.ai/security) · [Trust center](https://trust.qontext.ai)
# Retrieval logs
Source: https://docs.qontext.ai/features/retrieval-logs
Access retrieval logs for visibility and auditability
## Overview
Retrieval logs show which context was accessed by which client.
Use them to:
* Understand what context an agent retrieved
* Trace outputs back to specific files
* Verify that clients use the expected context
* Audit access to your context repository
Logs are available per client and per file.
***
## **Per API key**
To inspect retrieval activity for a specific client:
Open **Clients → API Keys**, select an API key, and go to **Retrieval logs**.
Typical use cases include:
* Debugging an agent
* Verifying client configuration
* Understanding retrieval patterns
* Investigating unexpected outputs
***
## **Per MCP client**
To inspect retrieval activity for an MCP client:
Open **Clients → MCP Clients**, select an MCP client, and go to **Retrieval logs**.
***
## **Per file**
To inspect retrieval activity for a specific file:
Open a file in the **Context** tab and open the **Retrieval logs** dropdown in the editor top bar.
Typical use cases include:
* Understanding how often a file is used
* Seeing which context agents accessed
* Investigating why a file influenced a response
# Skills distribution
Source: https://docs.qontext.ai/features/skills
Create, publish, and install reusable AI instructions across your workspace
## Overview
A **skill** is a reusable package of instructions that an AI agent loads on demand. You can define a skill once with a name, description, and instructions body. The agent can activate it whenever a relevant task comes up.
In Qontext, skills are managed centrally so they stay consistent across members and machines. Members install them once and keep them current with `qontext skills sync`. Skills managed in Qontext are interoperable, so you can use them on any client that supports the open Agent Skills format.
***
## Anatomy of a skill
A machine-readable identifier, lowercase with hyphens (e.g. `competitor-analysis`).
What the skill does and when to use it. The agent reads this at startup to decide when to activate the skill.
The full task instructions. Define what the agent should do, what data to draw on (data scope), and what format to produce (output format).
Optional scripts, reference documents, and templates, bundled in the skill folder and loaded only when needed.
**Open format.**
Qontext skills follow the open [Agent Skills specification](https://agentskills.io/specification). Skills work with any compatible AI tool and can be imported from a context repository.
### Organize a skill
Keep each independently reusable skill in its own folder. The folder name must match the `name` in `SKILL.md`.
Put the core instructions in `SKILL.md`. Use focused supporting files when the skill needs more detail:
* `references/` for documentation and detailed guidance
* `scripts/` for executable helpers
* `assets/` for templates, images, and other resources
Agents load supporting files only when needed. Keep shared company knowledge in its primary repository location and link to it rather than copying it into every skill.
***
## Importing skills to Qontext
Use the [import-repo](https://github.com/qontext-ai/examples/blob/main/skills/import-repo) skill to migrate existing skills from GitHub or a local folder into your context repository.
**The import-repo skill is designed for initial imports.**
After a successful import it removes itself from `~/.claude/skills/import-repo/`. To import again later, reinstall it from the [Qontext examples repository](https://github.com/qontext-ai/examples/tree/main/skills/import-repo).
Make sure Claude Code or another client is installed. The import-repo skill detects and sets up the [Qontext MCP](/interfaces/MCP) automatically if it is not already configured. You will be prompted to complete an OAuth flow on first run.
Download the [import-repo skill](https://github.com/qontext-ai/examples/tree/main/skills/import-repo) from the Qontext examples repository and place it in your Claude Code skills folder (`~/.claude/skills/import-repo/`).
In Claude Code, ask it to import your skills:
> "Import my skills from \[GitHub URL or local path] to Qontext."
The skill guides you through scope, file handling, and target path, then bulk-imports everything into your workspace. Folder descriptions such as `index.md` or `README.md` become the folder's [structure file](/features/structure-files), and relative links are rewritten to Qontext references.
Once complete, the imported skills appear as files in the context repository, visible under **Context** in your workspace.
***
## Distributing skills
Once a skill is stored in Qontext, teammates can install it into compatible clients using the Qontext CLI (see [CLI](/interfaces/cli) and [GitHub](https://github.com/qontext-ai/cli)).
Install the CLI:
```bash theme={null}
curl -fsSL https://cli.qontext.ai | sh
```
Log in to your workspace and approve the access request to your workspace:
```bash theme={null}
qontext login
```
Install a skill by passing its link to the CLI:
```bash theme={null}
qontext skills add
```
To get the link, open the **Context** tab in the app, select a skill, and click **Install skill**. You can then copy either the full install command or the short link.
To keep skills up to date, use:
```bash theme={null}
qontext skills sync
```
# Structure files
Source: https://docs.qontext.ai/features/structure-files
Guide how Qontext organizes and maintains each folder
## Overview
A structure file holds your instructions for a folder: what belongs there, which sources to use, how to organize the information, and how it should be updated.
For example, you can ask Qontext to:
* Preserve published policies word for word from Confluence.
* Aggregate customer knowledge into one folder per company.
* Keep concise project summaries current from documents and discussions.
Any folder can carry one structure file, named `.qontext.structure.md` and stored directly in the folder. The workspace root can also have one at `/.qontext.structure.md`.
Structure files are folder configuration, not knowledge. They are never retrieved as content and never appear in the context your AI tools get from Qontext.
Start with the outcome you want. Add naming rules, source authority, and details about what each file should contain only where they help Qontext make a real decision. A useful structure file can be a few clear paragraphs.
***
## Anatomy of a structure file
A structure file has two parts:
* **Strictness** in the frontmatter sets how confident the continuous update agent must be before changing the folder or its contents when continuous updates are enabled for a source.
* **Guidance** in the body describes the result you want in plain language.
### Strictness levels
| Level | The agent acts when |
| - | - |
| `permissive`, `lenient` | The content plausibly fits; when in doubt, it acts |
| `moderate` (default) | The case clearly holds |
| `firm`, `strict` | The fit is unambiguous; a marginal or partial match does not qualify |
A folder without a structure file, or without a recognizable strictness value, uses `moderate`. When new information clears no folder's bar, continuous updates skip it and explain why.
Set strictness according to the cost of a wrong change. Use stricter guidance for canonical records or word-for-word mirrors. Use more permissive guidance where capturing useful material matters more than exact placement.
### Inheritance
Guidance flows down the folder tree:
* Guidance from the workspace root and parent folders applies to their descendants.
* When two rules conflict, the structure file closest to the content takes precedence.
Put shared conventions at the root and add folder-specific instructions closer to the content. This keeps each structure file short and avoids repeating the same rules.
***
## What to include
A structure file should answer the questions that matter for its folder:
* What belongs here, and where should near-matches go?
* Which sources should Qontext use? Which source controls facts such as status or ownership?
* Should Qontext preserve the source wording, summarize it, or combine several sources?
* What does each file or subfolder represent?
* When should Qontext update an existing record instead of creating a new one?
* Which changes should be surfaced for review?
Use concrete instructions. “One file per customer, named after the company” gives Qontext a rule it can apply. “Keep this folder organized” does not.
### Subfolders
Write a rule for the subfolders. Do not write a list.
Make a list of the subfolders only when each subfolder has a different purpose and the set does not change often. Example: `tables`, `metrics`, `policies`.
When the subfolders follow one pattern, write the pattern. Example: “Make one subfolder for each customer. Name it after the company, in lowercase, with hyphens.” Do not list the customers.
A list becomes out of date when a new subfolder is created. Then the continuous update agent does not find the new subfolder in the list. The agent decides that the new content does not belong there.
Structure guidance steers continuous updates for sources where the setting is enabled. Use [file protection](/features/change-reviews) when a change must be technically held for review.
***
## Templates
The following templates are starting points. Change their folder names, sources, and record contents to match your workspace.
### Organize the repository root
**Place at:** `/.qontext.structure.md`
**Use when:** Your top-level folders are `agents`, `company`, `teams`, and `projects`.
```md .qontext.structure.md theme={null}
---
strictness: moderate
---
# Repository organization
Route reusable agent instructions and supporting resources to agents. Route company-wide knowledge, strategy, and policies to company. Route ongoing responsibilities, processes, and relationships to the team that owns them under teams. Route initiatives with a defined outcome and lifecycle to projects.
Give each entity or topic one primary record. Search for an existing record before creating another. Combine relevant information from several sources into that record and link to detailed evidence instead of copying the same content into several places.
Use lowercase-hyphen names except for required names such as SKILL.md. Create folders only when substantive content needs them; do not create empty folders or placeholder files.
If information could belong in several places, use the most specific existing home. If no destination is clear, report the ambiguity rather than guessing. Surface top-level folder changes, record merges, and deletions for review.
```
See [Organize your context repository](/context-repository/organization) for the matching folder tree.
### Aggregate customer knowledge
**Place at:** `/teams/sales/.qontext.structure.md`
**Use when:** You keep current customers in `customers`, prospective customers in `pipeline`, and shared sales processes in `rev-ops`.
```md .qontext.structure.md theme={null}
---
strictness: firm
---
# Sales knowledge
Organize account knowledge into one lowercase-hyphen folder per company under customers or pipeline. Use HubSpot to determine the account location, status, and owner. Keep shared sales definitions and processes in rev-ops. Do not infer CRM status from meetings or messages.
Each company folder contains overview.md: a concise synthesis of the relationship, verified contacts, needs, key developments, risks, and next steps from HubSpot and clearly matched Slack conversations. Link material claims to their evidence. Keep detailed records in meetings, support, and contacts subfolders, creating those folders only when substantive content exists.
Keep one dated file per HubSpot meeting note and preserve the complete note word for word, including links. Match the source meeting to its existing file when it changes. Keep one support file per distinct issue and one contact file per person.
Search customers and pipeline before creating a company folder. Avoid duplicates, unsupported facts, empty folders, and updates that only repeat CRM activity counters. Surface company moves, merges, renames, and deletions for review.
```
Customize the authoritative CRM, the sources used to enrich overviews, and whether meeting records should be copied or summarized. The matching [sales folder pattern](/context-repository/organization#sales-and-customer-knowledge) shows the intended result.
### Preserve policies word for word
**Place at:** `/company/policies/.qontext.structure.md`
**Use when:** Published policies in a Confluence space must remain faithful to their source.
```md .qontext.structure.md theme={null}
---
strictness: strict
---
# Company policies
Maintain one Markdown file per published policy from the Confluence HR Policies space.
Copy each policy word for word. Preserve its headings, lists, tables, visible text, and links. You may convert the formatting to equivalent Markdown, but do not summarize, reinterpret, combine, or omit content. Include the Confluence page link separately so the source remains traceable.
Treat the Confluence page as the stable identity of the policy. When its content or title changes, update the existing file instead of creating another one.
Exclude drafts, comments, meeting notes, and pages outside the HR Policies space. If a source policy disappears, surface it for review instead of deleting the repository copy.
```
Customize the source system, space, and publishing state. Keep `strict` when small wording changes would be costly.
### Keep project summaries current
**Place at:** `/projects/.qontext.structure.md`
**Use when:** Each project needs one current summary supported by more detailed records.
```md .qontext.structure.md theme={null}
---
strictness: moderate
---
# Projects
Keep one lowercase-hyphen folder per project. Each project has an overview.md that concisely combines verified information from its project documents and clearly matched team discussions.
Organize the overview into Goal, Owner, Status, Scope, Milestones, Risks, and Next steps. Update it when a source changes a material fact. Do not infer an owner, commitment, date, or completion status that no source confirms.
Keep one dated file per meeting in meetings and one dated file per decision in decisions. Link those records from the overview where they support a claim. Preserve earlier decisions when a newer decision supersedes them so the history remains understandable.
Search for the project before creating a new folder. Do not create empty folders, placeholder sections, or a second project record for a new name or source. Surface merges and deletions for review.
```
Customize the overview sections, source systems, and definition of a project.
***
## Check your guidance
Before relying on a structure file, test a few realistic updates against it:
| Incoming information | Expected result |
| - | - |
| An existing meeting note changes | Update its existing meeting file |
| A customer reports a new problem | Create or update one support case |
| A meeting reveals a material business need | Update the company overview and link the evidence |
| A published policy changes | Update the corresponding policy file without changing its meaning |
| The account identity is unclear | Report the ambiguity instead of creating a duplicate |
| A new customer appears | Create the folder from the pattern, with no change to the structure file |
Review the resulting changes for incorrect placement, duplication, unsupported claims, and unnecessary detail. Refine the guidance when you see a recurring problem.
***
## Setting up a structure file
In the **Context** tab, open a folder and select **Structure** at the top. The workspace root has the same entry above its top-level items.
Click the row to create or open the folder's `.qontext.structure.md`. Describe the outcome you want and set the strictness in the frontmatter.
Continuous updates follow the guidance when they place or change content in the folder. Review updates in the **Changes** tab and refine the guidance when needed.
Delete a structure file to remove its guidance from the folder. Structure files are Markdown files, so you can edit them directly or ask a [context agent](/features/context-agents) to draft one for you.
***
## Prompts to get started
* “Look at how `/customers` is organized and draft a short structure file that maintains one folder per company.”
* “Preserve every published policy from our Confluence HR space word for word, and update the same file when its source page changes.”
* “Which folders do not have structure guidance yet? Suggest guidance for the three busiest ones.”
# Version history
Source: https://docs.qontext.ai/features/version-history
Track every change to files in your context repository
## Overview
Version history shows how a file changed over time. Use it to understand when a file changed, where the change came from, and which version is currently active.
Version history is available from the **Version history** dropdown in the editor top bar.
***
## Version entries
Each entry represents one version of the selected file.
A version entry shows:
* **Source**: Where the change came from, such as a connected source or workspace member
* **Change type**: Whether the change was automated or a manual update
* **Version**: Either `latest` or a short version identifier
* **Timestamp**: When the version was created
The latest version represents the current editable version of the file.
***
## Change types
### Automated change
An automated change is created from connected source data.
For example, Qontext may update a customer file after new CRM activity, new documentation, or other connected source changes.
### Manual update
A manual update is created through the Qontext platform, MCP, or API.
For example, a user or agent may create or update a file directly in the context repository.
***
## Viewing previous versions
Select a version from the list to inspect that version of the file.
Previous versions are shown in read-only mode, so you can review historical content without changing the current file.
To return to the current file, select the version marked `latest`.
# Pricing
Source: https://docs.qontext.ai/get-started/pricing
Plans, Credit costs, and overage fees
## Overview
Every plan includes a monthly allowance of **Credits**. Credits are spent on the operations your workspace and your agents perform against the context repository.
Storage, file and folder operations, members, and Groups are not metered.
Included Credits reset every month. They don't roll over on monthly plans; on annual plans, unused Credits carry into the following month.
***
## Credit costs
Five operations consume Credits. The three repository operations are metered per unit, at the rates below. The two agent operations are metered on the work each run actually does, so their figures are averages.
### Context repository
| Operation | Credits | What counts as one |
| - | - | - |
| Hybrid search | 1,500 per 1,000 searches | One retrieval query, whether it runs against your repository or your synced data. |
| Write | 400 per 1,000 writes | One completed write to a file. |
| Synced record | 300 per 1,000 records | One record a [source](/sources) brings in or updates during a sync. |
**Writes are billed on merge.** A write consumes Credits once its change is applied. Changes that are rejected, or that expire in [review](/features/change-reviews), cost nothing.
### Context curation
Agent operations have no fixed price. Each run consumes Credits according to the work it actually does, so the figures below are averages rather than set rates: a pass that reads and writes a lot costs more than one that barely touches anything.
| Operation | Average Credits | What counts as one |
| - | - | - |
| Continuous update | \~990 per update | One [continuous update](/features/continuous-updates) agent pass. |
| Context agent run | \~10 per run | One [context agent](/features/context-agents) run from the chat on the **Context** tab. |
**Continuous updates run automatically for enabled sources.** Every new or changed record from a source with **Continuous updates** turned on starts its own agent pass, so a source that changes often can consume Credits without anyone prompting it. Use the source setting to control whether agents run and its **sync frequency** to control how often Qontext checks for changes.
***
## Overage fees
Overage is optional and cappable on Build and Scale. Past your allowance, Credits are billed at the Enterprise pay-as-you-go rate, which falls as your total volume grows.
| Total Credit volume | Per 1,000 Credits |
| - | - |
| 0 – 5M | €0.45 |
| 5M – 10M | €0.40 |
| 10M – 50M | €0.35 |
| 50M+ | €0.30 |
For example:
* **Build, 1.4M Credits used.** 400k Credits over the 1M allowance — €180.
* **Scale, 6M Credits used.** 1M Credits over the 5M allowance — €400.
Because the bands run on total Credit volume, Scale's included 5M puts its first overage Credit a tier down, at €0.40.
Explore has no overage. Prices exclude all taxes, levies, and duties.
***
## Feature overview
| | Explore | Build | Scale | Enterprise |
| - | - | - | - | - |
| Price | Free | €500 / month | €2,000 / month | Custom |
| Included Credits / month | 100k | 1M | 5M | Custom |
| Credit overage | — | Opt-in | Opt-in | Pay-as-you-go |
| Context agents | Included | Included | Included | Included |
| Continuous updates | — | Included | Included | Included |
| Sources | 3 | 5 | 10 | Unlimited, incl. custom |
| Sync frequency | — | Daily | Hourly | Real-time |
| Members and Groups | Unlimited | Unlimited | Unlimited | Unlimited |
| Change reviews | — | Included | Included | Included |
| User permissions | — | Included | Included | Included |
| Access controls | — | Included | Included | Included |
| Version and log history | 7 days | 90 days | 180 days | 365 days |
| MCP, API, and CLI access | Included | Included | Included | Included |
| Skill distribution | Included | Included | Included | Included |
| SSO | Google, Microsoft | Google, Microsoft | Google, Microsoft | Google, Microsoft, SAML |
| Hosting | Cloud | Cloud | Cloud | On-premise available |
| Support | Business hours | Business hours, private Slack | 24/5 | 24/7 with SLA |
Continuous updates are in early access and are not generally available yet. Contact [support@qontext.ai](mailto:support@qontext.ai) to enable them for your workspace.
***
## Need help?
If you encounter any problems or questions, contact us at [support@qontext.ai](mailto:support@qontext.ai).
# Quickstart
Source: https://docs.qontext.ai/get-started/quickstart
Qontext is the self-maintaining context repository powering your AI agents
This guide takes you from an empty workspace to a context repository that your AI agents can use.
Create your workspace and [sign in](https://app.qontext.ai/) to the Qontext platform.
Your context repository becomes useful once it contains company context. There are three common ways to get started.
If you already have structured company knowledge (e.g. a repository in GitHub), import it into Qontext using the [import-repo](https://github.com/qontext-ai/examples/blob/main/skills/import-repo) skill.
Connect a [native connector](/features/native-connectors) and let Qontext continuously build and maintain your repository.
Examples include:
* [Google Drive](/sources/google-drive)
* [HubSpot](/sources/hubspot)
* [Notion](/sources/notion)
* [Slack](/sources/slack)
[See all](/sources/index).
You can create and maintain files via the [UI](/context-repository/ui) or [MCP](/context-repository/MCP).
Qontext exposes a hosted MCP server:
```text theme={null}
https://api.qontext.ai/mcp
```
Once your repository contains context, connect your AI agents via [MCP](/interfaces/MCP) or [API](/api-docs/overview).
Examples include:
* [ChatGPT](/clients/chatgpt)
* [Claude](/clients/claude)
* [Codex](/clients/codex)
* [n8n](/clients/n8n)
[See all](/clients/index).
***
## Next steps
Connect to Claude or ChatGPT via MCP to chat with your context repository.
Explore ingestion and retrieval options via the API.
Power your AI workflows in n8n, make.com, or zapier with context from Qontext.
Continuously sync HubSpot, Google Drive, and Notion data using our connectors.
***
## Need help?
If you encounter any problems or questions, contact us at [support@qontext.ai](mailto:support@qontext.ai).
# MCP
Source: https://docs.qontext.ai/interfaces/MCP
Interact with Qontext via MCP
## Overview
MCP (Model Context Protocol) allows AI tools to connect directly to your context repository.
Once connected, AI agents can retrieve, search, and update context while respecting the permissions and access controls configured in Qontext.
Examples include:
* [ChatGPT](/clients/chatgpt)
* [Claude](/clients/claude)
* [Codex](/clients/codex)
* [Langdock](/clients/langdock)
***
## Connecting via MCP
Qontext exposes a hosted MCP server:
```text theme={null}
https://api.qontext.ai/mcp
```
You can connect with OAuth or an API key. Both authentication methods provide access to the same MCP tools.
### Connect with OAuth
Configure the MCP server URL in your client and complete the authentication flow. The client uses the permissions of the workspace member who authorizes it.
### Connect with an API key
Use an API key when a client needs its own access controls or a connection without an interactive OAuth flow. Using a separate key for each client or use case also makes retrieval activity easier to trace and lets you rotate or revoke its access independently.
[Create an API key](/api-docs/authentication#creating-an-api-key). If the client needs its own scope, choose **Manually manage**, then open the API key's settings and configure the required files and folders under **Access Controls**. See [Access management](/features/access-management#access-controls-for-api-keys) for more details.
Add Qontext as a remote MCP server:
| Setting | Value |
| - | - |
| MCP server URL | `https://api.qontext.ai/mcp` |
Then authenticate with the API key using either option:
| Client option | Configuration |
| - | - |
| **Bearer Auth** | Use the Qontext API key as the bearer token |
| **Custom header** or **Header Auth** | Add an `X-API-Key` header with the Qontext API key as its value |
Both options authenticate the same API key and use its configured access controls.
Please refer to the [Clients](/clients/index) section for client-specific setup instructions.
***
## Available operations
The MCP server exposes the context repository through a POSIX-like set of operations.
### Read
Browse the file system and read content.
| Operation | Description |
| - | - |
| `qontext_ls` | List the direct children of a path (files and folders). |
| `qontext_find` | Recursively list all descendants under a path. Filterable by kind (file / folder) or the date of the last update to the descendant. |
| `qontext_cat` | Read the full content of one or more files. If any item in the batch cannot be read, the whole call fails. |
References between files are returned inline as file IDs, so a client can traverse the interconnected file system by passing a returned ID straight into `qontext_cat`.
### Search
Locate context by content or by meaning.
| Operation | Description |
| - | - |
| `qontext_grep` | Exact content search across the repository. Allows searching literally or using regex. |
| `retrieval-tool` | Hybrid search over the repository. Takes a qualitative, natural-language query and returns the most relevant context. |
### Write
Create and maintain context.
| Operation | Description |
| - | - |
| `qontext_write` | Create or update a file at an absolute path. If the path includes folders, its parent folder must already exist. |
| `qontext_mkdir` | Create a folder. |
| `qontext_mv` | Rename or move one file per call. Use `/` as the destination to move it to the workspace root. Moving and renaming are separate operations; manage folders in the **Context** tab. |
| `qontext_rm` | Delete a file or folder. Deleting a non-empty folder requires `recursive: true` and removes everything inside it. |
Writes flow through Qontext's versioning: every edit is captured in the [version history](/features/version-history) and reconciled into the repository, so concurrent edits are tracked rather than silently overwritten.
# API
Source: https://docs.qontext.ai/interfaces/api
Read, search, and update your context repository from applications and workflows.
Use the Qontext API to read, create, update, and delete files and folders, or search your context repository by meaning or regular expression. Requests use a workspace API key and respect its access controls.
The [API documentation](/api-docs/overview) contains the guides and endpoint reference.
Make your first requests and read and write context.
Create an API key and configure access.
# CLI
Source: https://docs.qontext.ai/interfaces/cli
Interact with Qontext via the command line
## Overview
The [Qontext CLI](https://github.com/qontext-ai/cli) (`qontext`) brings your context repository to the command line.
Today it installs and maintains workspace [Skills](/features/skills) on your local machine: install a skill once, then keep it in sync with a single command. Skills follow the open [Agent Skills specification](https://agentskills.io/specification), so they work with any compatible AI tool.
***
## Install
```sh theme={null}
curl -fsSL https://cli.qontext.ai | sh
```
```powershell theme={null}
irm https://raw.githubusercontent.com/qontext-ai/cli/main/install.ps1 | iex
```
If you'd rather not pipe a script into a shell:
1. Download the archive for your platform from the [Releases](https://github.com/qontext-ai/cli/releases) page.
2. Verify it against `SHA256SUMS-.txt` from the same release:
* macOS / Linux: `shasum -a 256 -c SHA256SUMS-.txt`
* Windows: `Get-FileHash -Algorithm SHA256 `
3. Extract and move `qontext` (or `qontext.exe`) onto your `PATH`.
***
## Authentication
Log in to connect the CLI to your workspace and approve the access request:
```bash theme={null}
qontext login
```
***
## Managing skills
Pass a skill's link to the CLI:
```bash theme={null}
qontext skills add
```
To get the link, open the **Context** tab in the [Qontext app](https://app.qontext.ai), select a skill, and click **Install skill**. Copy either the full install command or the short link.
Pull the latest version of every installed skill:
```bash theme={null}
qontext skills sync
```
Please refer to [Skills](/features/skills) for how skills are created, imported, and distributed across a workspace.
***
## Updating the CLI
Keep the CLI current with a single command:
```bash theme={null}
qontext update
```
This replaces the installed binary in place with the latest release. The CLI also checks for updates in the background and warns you once a day when a newer version is available.
***
## Command reference
| Command | Description |
| - | - |
| `qontext login` | Authenticate the CLI with your workspace. |
| `qontext skills add ` | Install a skill from your context repository. |
| `qontext skills sync` | Update all installed skills to their latest version. |
| `qontext update` | Update the CLI in place to the latest release. |
***
## FAQ
Any tool that supports the open [Agent Skills specification](https://agentskills.io/specification), such as Claude Code. The CLI places skills in the client's local skills folder.
Run `qontext skills sync`. Skills stay centrally managed in your workspace, so every installed copy updates from a single source of truth.
# Confluence
Source: https://docs.qontext.ai/sources/confluence
Connect Confluence with Qontext
## Overview
The Confluence connection allows Qontext to read pages and blog posts from a connected Confluence instance and ingest their text content into your context repository.
Only spaces and pages that the connected Confluence account can access will be ingested into your context repository.
**Supported data types:**
| Object | Description |
| - | - |
| `Pages` | Confluence pages including nested child pages |
| `Blog posts` | Blog posts published within Confluence spaces |
| `Comments` | Footer and inline comments, fetched and appended to their parent page or blog post |
| `Tasks` | Tasks on pages, fetched and appended to the parent page content |
Comments and tasks are not ingested as standalone items. They are included in the content body of their parent page or blog post.
**Unsupported:**
| Object | Description |
| - | - |
| `Attachments` | Files attached to pages (e.g. images, PDFs, spreadsheets) |
| `Databases` | Confluence databases |
| `Whiteboards` | Confluence whiteboards and visual collaboration content |
***
## Recommended setup
Use a **dedicated integration user** in your Confluence instance to ensure a stable and uninterrupted connection.
Create a service account such as `qontext@yourcompany.com` and grant it access to the spaces you want Qontext to ingest. This prevents sync disruptions when employee accounts or permissions change.
The integration user will:
* Authenticate the connection between Qontext and Confluence.
* Access shared spaces and pages with read-only permissions.
***
## Setting up the connection
You can connect Confluence from your Qontext workspace, authorize access in Confluence, then choose what to sync and how often. The steps below walk you through the full flow.
You can also manage all your credentials, including Confluence, from the **Sources** tab.
In the [**Qontext app**](https://app.qontext.ai/), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
You can **reuse existing Confluence credentials** (if you've already connected this account to Qontext) or **create a new connection**.
If you create a new credential, sign in to Atlassian when prompted. On the consent screen, review the requested permissions and click **Accept** to grant Qontext read access to your Confluence content.
Select the spaces and pages you want Qontext to ingest into your context repository. Use the search bar to find specific spaces and pages or navigate through the list.
Click the **+** next to a page to add it, or click the page name to navigate into it for a more granular selection. Selected items appear at the top. To remove them from the selection, click the **x** next to it.
Choose how often Qontext should refresh data from Confluence (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (name, frequency, selected pages), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Managing permissions
### Confluence OAuth scopes
When connecting, you will see a consent screen titled **Qontext for Confluence is requesting access to your Atlassian account**. It lists the permissions Qontext needs; they are read-only. You'll see categories such as:
```text theme={null}
- View: Blogpost, Comments, Folder, Page, Space details, Task, User details, Content attachments, Custom content, Database, Smart Link, Content templates, Whiteboard
- Search: confluence
```
Granting these scopes is required for the connection to work. Qontext only reads data from Confluence to ingest it into your context repository; it does not create, edit, or delete any content.
### Confluence permissions
* Use a **single integration user** to manage Confluence access for Qontext to avoid permission conflicts.
* If you don't see a space or page during filter setup, verify that the connected account has permission to view it in Confluence.
***
## Sync latency
The initial sync time depends on the number of spaces and pages in scope. Large Confluence instances with many pages can take **up to 12 hours** to fully index.
Subsequent syncs process **incremental changes** and typically complete much faster than the initial sync.
***
## FAQ
Any user with **Confluence access** and permission to authorize third-party apps can set up the connection. We recommend using a dedicated service account with stable access to the spaces you want to ingest.
Qontext currently supports **Confluence Cloud** only. If you use Confluence Data Center, contact [support@qontext.ai](mailto:support@qontext.ai) to discuss your options.
Yes. You can create multiple Confluence connections from the **Sources** tab in your Qontext workspace. Add each site as a separate data source. You can also manage all your credentials from the **Source** tab in your Qontext workspace. Add each site as a separate data source. You can also manage all your credentials from the **Sources** tab.
Manual refresh for Confluence connections is available via the **Sources** tab. Navigate to the respective Confluence connection and open the **Syncs** tab. In the Sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
Disconnecting stops further syncs. Content already ingested from Confluence remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
Initial sync time varies: small instances may finish in under an hour; large instances with many spaces and pages can take up to 12 hours. Subsequent syncs are incremental and faster.
Yes. All data is encrypted in transit (TLS). Qontext only accesses spaces and pages you explicitly authorize via the Atlassian OAuth flow.
By default, Qontext only ingests content the connected account can access. Additionally, you can add [filters](#configure-what-to-sync-filters) to every connection as described in the setup flow.
Yes. Confluence page-level and space-level restrictions are respected. Qontext can only access content visible to the connected account.
Go to the **Sources** page, find your Confluence credentials, and use the action dropdown to **Validate** that it is still valid. If the credential is expired or broken, select **Reconnect**. Also verify that the connected account still has access to the required spaces. If the issue persists, contact [support@qontext.ai](mailto:support@qontext.ai).
# Gong
Source: https://docs.qontext.ai/sources/gong
Connect Gong with Qontext
## Overview
The Gong connection allows Qontext to read your recorded sales calls from Gong and sync their content into the context repository. Qontext syncs a structured summary of each call, not the raw transcript, so your AI clients get the substance of a conversation without the noise.
Only calls that the connected Gong account can access will be synced into your context repository.
**Supported data types:**
| Object | Description |
| - | - |
| `Calls` | Recorded calls, each synced as a single file |
Each call file includes:
* **Call details** — title, date and time, duration, direction, scope, media type, language, purpose, and a link back to the call in Gong.
* **Participants** — each participant's name, email, phone number, and whether they are internal or external.
* **Associated CRM records** — the deals, contacts, and other records Gong has linked to the call from your connected CRM (such as Salesforce, HubSpot, or Microsoft Dynamics).
* **Call outline** — Gong's structured, timestamped summary of what was discussed.
**Unsupported:**
| Object | Description |
| - | - |
| `Raw transcripts` | Full word-for-word transcripts are not synced; Qontext uses Gong's call outline instead |
| `Audio and video` | Call recordings and other media files |
***
## Recommended setup
Gong connects with an **API key** (an access key and its secret) rather than a personal login. Use a key generated for Qontext specifically, so the connection stays stable when individual employee accounts change.
Have a Gong administrator generate a dedicated API key for Qontext. Because the key inherits the permissions of your Gong API, this keeps access consistent and easy to revoke without affecting anyone's personal account.
***
## Setting up the connection
You generate an API key in Gong, then add it to Qontext and set how often it should sync. The steps below walk you through the full flow.
Generating a Gong API key requires a Gong user with **Technical Administrator** permissions. If you don't have them, ask your Gong administrator to complete the first step.
Open Gong's [API settings page](https://app.gong.io/company/api) and click **Create** under **Public API Access**.
Gong generates two values: an **Access Key** and an **Access Key Secret**. You need both. The secret is masked on the page; use **Show** or **Copy to clipboard** to retrieve it.
In the [Qontext app](https://app.qontext.ai), open your workspace, go to the **Sources** tab, and click **+ Connect data source**.
Choose **Gong** from the list of available data sources, and give the credential a name (for example, `Sales Gong recordings`). The name is only used to identify the connection inside Qontext.
Paste the value from Gong into **Access key**, and the matching secret into **Access key secret**, then confirm. Both fields are required.
Qontext verifies the credential against Gong before saving it. If verification fails, the message names the reason: a rejected credential, missing permissions, a rate limit, or Gong being unreachable.
New connections sync calls from the previous 12 months by default. Choose a different start date, or clear the time window to sync all available call history.
Changing the time window later affects future syncs. Calls already stored in the context repository are not removed.
Choose how often Qontext should refresh data from Gong (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices and confirm to create the connection. Qontext starts the initial sync shortly after.
***
## Managing permissions
Qontext uses your Gong API key to **read** calls only; it never creates, edits, or deletes anything in Gong. The connection can access exactly the calls your Gong API is permitted to see, no more.
* Use a **single, dedicated API key** for Qontext so access is easy to audit and revoke.
* To revoke access, delete or rotate the key on Gong's [API settings page](https://app.gong.io/company/api). The connection stops syncing as soon as the key is invalid.
***
## Sync latency
The initial sync time depends on how many calls are in scope. Large call histories can take **up to 6 hours** to fully sync.
Subsequent syncs are **incremental** and also check for calls that arrived in Gong after their original call date, so they complete much faster than the initial sync without missing late additions.
***
## FAQ
Anyone in your Qontext workspace can add the connection, but generating the API key in Gong requires a Gong user with **Technical Administrator** permissions. In practice, a Gong administrator generates the key and hands it to whoever sets up the source in Qontext.
Qontext syncs calls that the Gong API key can access and that fall within the selected time window. Each call becomes one record containing its details, participants, associated CRM records, and Gong's call outline.
No. Qontext syncs Gong's structured call outline rather than the raw word-for-word transcript. This keeps the context focused on what was discussed, decided, and agreed.
Yes. You can create multiple Gong connections from the **Sources** tab in your Qontext workspace, each with its own API key.
Disconnecting stops further syncs. Content already synced from Gong remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
Check that the key is still valid on Gong's [API settings page](https://app.gong.io/company/api) and hasn't been rotated or revoked. If it has, generate a new key and reconnect the source in Qontext with the new access key and secret. If the issue persists, contact [support@qontext.ai](mailto:support@qontext.ai).
# Google Drive
Source: https://docs.qontext.ai/sources/google-drive
Connect Google Drive with Qontext
## Overview
The Google Drive connection allows Qontext to ingest documents, presentations, tables, and text files from a connected Google Drive into your context repository.
Only files and folders that the connected Google account can access will be ingested into your context repository.
**Supported file types:**
| Type | Description |
| - | - |
| `Google Workspace files` | Google Docs, Google Slides, and Google Sheets, synced as text |
| `Documents & other files` | `docx`, `pptx`, `xlsx`, `pdf`, `rtf`, `txt`, `csv`, `md`, `odt`, `odp`, `ods`, and `html` (up to 10 MB per file) |
**Unsupported:**
| Type | Description |
| - | - |
| `Other file types` | Images, audio, video, and file types not listed above |
| `Scanned PDFs` | Image-only PDFs contain no extractable text and are not OCR processed |
| `Large files` | Files over 10 MB are skipped |
***
## Recommended setup
Use a **dedicated integration user** in your Google Workspace to ensure a stable and uninterrupted connection.
Create a service account such as `qontext@yourcompany.com` and grant it access to the files and folders you want Qontext to ingest. This prevents sync interruptions if employee accounts change or are deactivated.
The integration user will:
* Authenticate the connection between Qontext and Google Drive.
* Access required resources with read and download permissions.
***
## Setting up the connection
You can connect Google Drive from your Qontext workspace, authorize access in Google, then choose what to sync and how often. The steps below walk you through the full flow.
You can also manage all your credentials, including Google Drive, from the **Sources** page.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **Google Drive** from the list of available data sources. This starts the Google Drive connection flow.
You can **reuse existing Google Drive credentials** (if you’ve already connected this account to Qontext) or **create a new connection**.
If you create a new connection, select the Google account that has access to the files you want to ingest, and approve the requested OAuth scopes.
Select the folders and files you want Qontext to ingest into your context repository. You can add folders or individual files.
Click the **+** next to a folder to add it; open the folder to add subfolders or individual files and select them the same way. Files over 10MB or in an unsupported format cannot be selected. Any such files inside a selected folder are excluded from sync automatically.
Selected items appear at the top. Click **All file types** next to a folder to limit which file types are synced from that folder. Use the checkmark next to an item to remove it from the selection.
Choose how often Qontext should refresh data from Google Drive (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (account, filters, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Managing permissions
### Google Drive OAuth scopes
When connecting, you will be asked to grant scopes that allow Qontext to read and download files. Example scope descriptions you may see:
```text theme={null}
- See and download all your Google Drive files
- See information about your Google Drive files
```
These are required for Qontext to read data from Google Drive and ingest it into your context repository.
### Google Drive permissions
* Use a **single person** or **service account** to manage Drive permissions for Qontext. This avoids accidental permission changes that break syncs.
* If you don’t see a file in Qontext’s Drive tree, verify download permissions using the file’s **File info -> Details** and ensure `Viewers and commenters can see the option to download, print, and copy` is enabled.
***
## Sync latency
Qontext preprocesses Drive content before ingesting it into the context repository. The initial synchronization time depends on the volume and type of files. Workspaces with many files may take up to 12 hours to fully index.
Subsequent syncs process **incremental changes** and typically complete much faster than the initial sync.
***
## FAQ
Qontext supports native Google Docs, Google Slides, and Google Sheets, along with `docx`, `pptx`, `xlsx`, `pdf`, `rtf`, `txt`, `csv`, `md`, `odt`, `odp`, `ods`, and `html` files. Files larger than 10MB, in an unsupported format, or without extractable text are skipped.
Yes. You can create multiple Google Drive connections at any time in the **Sources** tab in your Qontext workspace.
Manual refresh for Google Drive connections is available via the **Sources** tab. Navigate to the respective Google Drive connection and open the **Syncs** tab. In the Sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
If you disconnect the Drive connection, no new files will be ingested. Content already ingested from Drive will remain in your context repository. For data removal requests, contact [support@qontext.ai](mailto:support@qontext.ai).
Yes. All data is encrypted in transit (TLS) and at rest. Qontext only accesses files you explicitly authorize via Google OAuth scopes.
By default, Qontext only ingests files the connected Google account can access. Additionally, you can add [filters](#configure-what-to-sync-filters) to every connection as described in the setup flow.
# HubSpot
Source: https://docs.qontext.ai/sources/hubspot
Connect your HubSpot CRM with Qontext
## Overview
The HubSpot connection lets Qontext securely and regularly read CRM data from your connected HubSpot account. That data is structured and stored in your context repository so your AI tools can use it for retrieval and answers.
Only data that the connected HubSpot user can access is synced. Use an account with access to the contacts, companies, and deals you want in Qontext.
**Supported data types:**
| Object | Description |
| - | - |
| `Contacts` | People and their key details from your CRM |
| `Companies` | Organizations linked to your contacts and deals |
| `Deals` | Sales opportunities and their pipeline stages |
| `Leads` | Lead records and their properties |
| `Notes` | Insights and updates added to CRM records |
| `Tasks` | To-dos and follow-ups tracked in HubSpot |
| `Emails` | Email conversations tracked and linked to contacts, companies, or deals |
| `Meetings` | Scheduled or logged meetings with prospects or clients |
| `Calls` | Call records associated with a contact or company |
***
## Recommended setup
Use a **dedicated integration user** in your HubSpot workspace to ensure a stable connection.
Create a service account such as `qontext@yourcompany.com` with **Super Admin** rights. This keeps the integration active even if employee accounts change or are deactivated.
The integration user will:
* Authenticate the connection between Qontext and HubSpot.
* Maintain consistent access to required HubSpot data.
***
## Setting up the connection
You can connect HubSpot from your Qontext workspace, authorize access in HubSpot, then choose what to sync and how often. The steps below walk you through the full flow.
You can also manage all your credentials, including HubSpot, from the **Sources** page.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **HubSpot** from the list of available data sources. This starts the HubSpot connection flow.
You can **reuse existing credentials** (if you’ve already connected this HubSpot account to Qontext) or **create a new connection**.
If you create a new connection, sign in to HubSpot when prompted and select the HubSpot account you want to use.
On the HubSpot consent screen, review the requested permissions and click **Connect app** to approve. This completes the OAuth flow and grants Qontext read access to the CRM data you authorize.
By default, Qontext can sync a broad set of data. You can narrow it using one or more of these options so only the data you need is ingested into your context repository.
Pick specific contacts, companies, or deals by searching and selecting them. Use this when you only want a defined set of records.
Sync data from one or more HubSpot lists or segments. Useful when you already manage audiences in HubSpot and want the same scope in Qontext.
Ingest deals from selected pipelines. Only deals in the chosen pipelines will be synced.
Choose which object types to sync. This controls the breadth of data without picking specific records.
Choose how often Qontext should refresh data from HubSpot (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (account, filters, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## HubSpot OAuth scopes
When you create a new connection, you’ll see a consent screen listing the permissions (scopes) Qontext needs; they are read-only. You'll see a section like *("Manage and view your CRM data")* with scopes such as:
```text theme={null}
- View details about contact lists.
- View properties and other details about appointments.
- View properties and other details about carts.
- View details about commerce payments.
- View properties and other details about companies.
- [...]
- View properties and other details about contacts.
- View properties and other details about courses.
- View details about custom objects in the CRM.
- View properties and other details about deals.
- View details about submissions to any of your feedback surveys.
```
Granting these scopes is required for the connection to work. Qontext does not write or delete data in HubSpot.
***
## Sync latency
Qontext preprocesses and structures your HubSpot data before ingesting it into the context repository. The **first sync** can take a while depending on how much data you are syncing (contacts, companies, deals, etc.).
As a guideline, allow **up to 12 hours** after creating the connection for the initial sync to finish.
***
## FAQ
Yes. You can connect multiple HubSpot accounts by following the steps above for each connection. Add each account from the **Sources** tab in your workspace.
Manual refresh for HubSpot connections is available via the **Sources** tab. Navigate to the respective HubSpot connection and open the **Syncs** tab. In the Sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
If you disconnect your HubSpot account from a connected workspace, no new data will be synced. Existing HubSpot data in the context repository will remain available for now. An upcoming update will introduce configurable data retention options upon disconnection. If you need to remove data for compliance or testing reasons, please contact [support@qontext.ai](mailto:support@qontext.ai).
Absolutely. All HubSpot data processed through Qontext is encrypted in transit and at rest. Qontext only accesses data you explicitly authorize via HubSpot OAuth scopes, ensuring your information remains secure and private.
By default, Qontext only ingests the data authorized through HubSpot’s OAuth scopes. Additionally, you can set [filters](#configure-what-to-sync-filters) when creating the HubSpot connection.
If the connected HubSpot user’s permissions are reduced or revoked, Qontext may lose access to certain data. To maintain uninterrupted syncs, we recommend using a **dedicated HubSpot service account** with stable permissions.
Sync failures usually occur due to expired OAuth tokens or insufficient permissions. Try reconnecting HubSpot in your **Sources** tab. If the issue persists, contact our team at [support@qontext.ai](mailto:support@qontext.ai) for faster troubleshooting.
# Sources
Source: https://docs.qontext.ai/sources/index
Connect your data sources to Qontext
Qontext uses native connectors to sync data from your existing tools into your context repository, where Qontext normalizes it and uses it to create and continuously update structured context.
***
## Available connectors
}
href="/sources/confluence"
>
Connect your knowledge base and documentation.
}
href="/sources/gong"
>
Sync your recorded sales calls and their summaries.
}
href="/sources/google-drive"
>
Sync documents, presentations, and text files from Google Drive.
}
href="/sources/hubspot"
>
Sync contacts, companies, deals, and notes from your CRM.
}
href="/sources/linear"
>
Sync issues, projects, and documents from your Linear workspace.
}
href="/sources/notion"
>
Connect your Notion workspace to sync pages and databases.
}
href="/sources/salesforce"
>
Sync accounts, contacts, deals, and notes from your CRM.
}
href="/sources/sharepoint"
>
Sync documents, pages, and lists from your SharePoint sites.
}
href="/sources/slack"
>
Sync conversations from your Slack workspace.
}
href="/sources/website"
>
Crawl and sync content from your website or any public website.
***
## Coming soon
We are actively expanding our native integrations. Here's what's on the roadmap:
* **Zendesk**: Sync tickets, conversations, help center articles, and customer support activity.
* **Microsoft Teams**: Sync channels, conversations, meetings, and collaboration history.
***
## Request a native connector
If your tool isn’t listed, you can request it [here](https://tally.so/r/mVkKMj). We prioritize based on customer demand.
# Linear
Source: https://docs.qontext.ai/sources/linear
Connect Linear with Qontext
## Overview
The Linear connection lets Qontext read issues, projects, and documents from your Linear workspace and sync them into your context repository. Each record becomes a structured text document (its key fields together with the discussion around it) so your agents can retrieve the planning context behind your product: what is being built, why, where it stands, and what was said about it. Qontext connects to Linear through the GraphQL API over OAuth.
Qontext only reads data; it never creates, edits, or deletes anything in Linear. Access is always bounded by the connected user's own Linear permissions, so Qontext can only sync what that account can already see.
**Supported objects:**
| Object | Description |
| - | - |
| `Issues` | Issues with their title, description, state, priority, assignee, labels, Linear team, and project |
| `Comments` | Issue comment threads, synced inline as part of their issue rather than as separate records |
| `Projects` | Projects with their short description, full markdown overview, status, lead, and target date |
| `Project updates` | The status narrative posted against a project over time, synced inline as part of their project |
| `Documents` | Standalone Linear documents (PRDs, specs, RFCs) attached to a project, a Linear team, or an issue |
**Unsupported:**
| Object | Description |
| - | - |
| `Initiatives` | The org-level grouping above projects. Not synced, and documents attached to an initiative are excluded as well |
| `Cycles` | A cycle carries only a name and a date range; the issues inside it are already synced |
| `Linear teams, users, and labels` | Available as filter options and as metadata on synced issues, but not synced as records of their own |
| `Attachments and embedded uploads` | Files hosted on `uploads.linear.app` require an authenticated fetch. Their links are preserved in the synced text, but the files themselves are not synced |
| `Emoji reactions` | No content value |
***
## Recommended setup
Use a **dedicated integration user** in your Linear workspace to ensure a stable and uninterrupted connection.
Create a service account such as `qontext@yourcompany.com`, add it to your Linear workspace, and give it access to the Linear teams you want Qontext to sync. This prevents sync disruptions when employee accounts or permissions change.
The integration user will:
* Authenticate the connection between Qontext and Linear.
* Access the selected issues, projects, and documents with read-only permissions.
Qontext requests a single Linear scope, `read`, and uses OAuth with PKCE. It deliberately does not request `admin`, which Linear only requires for managing webhooks.
***
## Setting up the connection
You can connect Linear from your Qontext workspace, authorize access with your Linear account, then choose what to sync and how often. Linear needs no workspace URL or subdomain, so authorizing is a single step.
You can also manage all your credentials, including Linear, from the **Sources** page.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **Linear** from the list of available data sources. This starts the Linear connection flow.
You can **reuse existing Linear credentials** (if you have already connected this account to Qontext) or **create a new connection**.
If you create a new credential, sign in with Linear when prompted. On the consent screen, review the requested access and authorize Qontext to read your workspace.
Choose which projects, issues, and documents Qontext should sync into your context repository. By default all three are included and scoped to everything in the workspace.
See [Filtering what gets synced](#filtering-what-gets-synced) below for the full set of options.
Choose how often Qontext should refresh data from Linear (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (workspace, selection, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Filtering what gets synced
Linear filters are organized as three independent rules: one for **projects**, one for **issues**, and one for **documents**. Each rule can be switched off entirely, and each carries its own scope, because the same word means different things per content type. An issue belongs to exactly one Linear team, a project can span several, and a document hangs off whichever container it was created in.
By default all three rules are on and set to sync everything.
* **All**: every project in the workspace.
* **Filtered**: narrow by Linear team, by status (Backlog, Planned, In Progress, Paused, Completed, Canceled), by project label, by project lead, and by last-updated date.
* **Specific**: hand-pick individual projects.
* **All**: every issue in the workspace.
* **By team**: only issues belonging to the Linear teams you select.
* **From included projects**: only issues belonging to the projects your Projects rule already includes, so the two selections stay consistent.
An issue does not have to belong to a project, and in most workspaces many do not. The **From included projects** mode therefore also offers a checkbox to **include issues without a project**, which adds those back.
Whichever scope you pick, issues can be narrowed further by state (Triage, Backlog, Todo, In Progress, Done, Canceled), by issue label, by assignee, and by last-updated date.
Issue labels and project labels are separate things in Linear, so they are chosen in separate pickers and cannot be used interchangeably.
* **All**: every document in the workspace, whether it is attached to a project, a Linear team, or an issue.
* **From included projects and issues**: only documents attached to a project or an issue that is already in scope, which keeps your documents aligned with the rest of the selection.
Documents can also be limited by last-updated date. Documents attached to an initiative are not synced in either mode.
***
## Sync latency
The initial sync time depends on how many issues, projects, and documents are in scope. Large workspaces can take **up to 6 hours** to fully sync.
Subsequent syncs are **incremental**: Qontext processes only the records that were added or changed since the last sync, which runs much faster than the initial sync.
***
## Managing permissions
### Linear OAuth scope
When connecting, you authorize Qontext against your Linear workspace. Qontext requests one scope:
```text theme={null}
- read Read the workspace data the connected user can already see
```
Qontext uses this access only to **read**. It never creates, edits, or deletes anything in Linear, and because `read` operates as the connected user, Qontext can only ever see what that account can see.
### Linear permissions
* Use a **single integration user** to manage Linear access for Qontext to avoid permission conflicts.
* If a project, Linear team, or document does not appear during filter setup, check that the connected account has access to it in Linear.
* Linear access tokens are short-lived, and Qontext refreshes them automatically in the background. If a refresh is rejected, for example because the authorization was revoked in Linear, the connection stops syncing and prompts you to reconnect it from the **Sources** tab.
***
## FAQ
Any workspace member with a Linear account that has access to the relevant content. Qontext syncs exactly what that account can see, so an account with access to every Linear team gives the most complete result.
No. Qontext only reads issues, projects, and documents. It never creates, edits, or deletes data in Linear, and it never comments on an issue.
Yes, by default. An issue in Linear belongs to exactly one Linear team but does not need a project. If you scope issues to **From included projects**, use the **include issues without a project** checkbox to keep those issues in scope.
They are retrievable as part of the record they belong to. A comment thread is synced with its issue, and project updates are synced with their project, so agents read the discussion in the context that gives it meaning rather than as a detached fragment.
Yes. You can create multiple Linear connections from the **Sources** tab in your Qontext workspace. Add each Linear workspace as a separate data source.
Manual refresh is available via the **Sources** tab. Navigate to the respective Linear connection and open the **Syncs** tab. In the sync settings, you can select **Resync all data**.
Disconnecting stops further syncs. Content already synced from Linear remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
By default, Qontext only syncs content the connected Linear account can access. Additionally, you can add [filters](#configure-what-to-sync-filters) to every connection as described in the setup flow.
# Notion
Source: https://docs.qontext.ai/sources/notion
Connect Notion with Qontext
## Overview
The Notion connection allows Qontext to read pages and database pages from a connected Notion workspace and ingest their text content into your context repository.
Only pages and content that the connected Notion user can access will be ingested into your context repository.
**Supported data types:**
| Object | Description |
| - | - |
| `Pages` | Public and shared pages with text, headings, and inline content |
| `Database Pages` | Notion databases (rows, properties, and their page content) |
**Unsupported:**
| Object | Description |
| - | - |
| `Attachments` | Content behind URLs and attachments (e.g. audio, images, video, embeds) |
***
## Recommended setup
Use a **dedicated integration user** in your Notion workspace to ensure a stable and uninterrupted connection.
Create a service account such as `qontext@yourcompany.com` and grant it access to the pages or teamspaces you want Qontext to ingest. This prevents sync disruptions when employee accounts or permissions change.
The integration user will:
* Authenticate the connection between Qontext and Notion.
* Access shared pages and teamspaces with the minimum required permissions.
***
## Setting up the connection
You can connect Notion from your Qontext workspace, authorize access in Notion, then choose what to sync and how often. The steps below walk you through the full flow.
You can also manage all your credentials, including Notion, from the **Sources** page.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **Notion** from the list of available data sources. This starts the Notion connection flow.
You can **reuse existing Notion credentials** (if you’ve already connected this Notion account to Qontext) or **create a new connection**.
In the Notion dialog, grant permission for Qontext to view the pages you select.
Then, select the teamspace from which you want to provide information to Qontext. Confirm to complete the OAuth flow.
It is recommended to select the whole teamspace and filter it in the next step via the Qontext UI. This makes it easier to manage and adapt your Notion connection.
Select the pages and database pages you want Qontext to ingest into your context repository. Use the search bar to find them or navigate through subpages by clicking on **Page**.
Click the **+** next to a page to add it and the **x** next to a selected page at the top to remove it from the selection.
Choose how often Qontext should refresh data from Notion (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (workspace, pages, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Managing permissions
* Use a **single integration user** to manage Notion access for Qontext to avoid permission conflicts.
* Prefer a **share-by-default** approach for large sections and exclude pages you do not want indexed.
* Avoid multiple users creating separate Qontext connections for the same Notion pages. This can cause duplication or access conflicts.
### Share additional pages with Qontext
To share a specific page or database page from Notion:
1. Open the page in Notion.
2. Open the menu by clicking the three dots and add the Qontext connection.
3. Ensure parent pages are shared where relevant to maintain hierarchy.
***
## Sync latency
The initial sync time depends on workspace size and structure. Large or deeply nested workspaces can take **up to 12 hours** to fully index.
***
## FAQ
Every **Notion Member** can set up the Notion connection. Make sure that the account has the required access to the pages you want to ingest.
Yes, you can connect multiple Notion accounts to one Qontext workspace. Ideally, connect each Notion workspace only once to avoid duplication or access conflicts.
Manual refresh for Notion connections is available via the **Sources** tab. Navigate to the respective Notion connection and open the **Syncs** tab. In the Sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
Disconnecting stops further syncs. Content already ingested from Notion remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
By default, Qontext only ingests pages the connected Notion account has full access to. Additionally, you can add [filters](#configure-what-to-sync-filters) to every connection as described in the setup flow.
Initial sync time varies: small workspaces may finish in under an hour; very large or complex workspaces can take up to 12 hours. Subsequent syncs are incremental and faster.
Reconnect the integration and verify that the relevant pages are shared with the Qontext integration. If the issue persists, contact [support@qontext.ai](mailto:support@qontext.ai).
# Salesforce
Source: https://docs.qontext.ai/sources/salesforce
Connect Salesforce with Qontext
## Overview
The Salesforce connection lets Qontext read records from your Salesforce org and sync them into your context repository. Qontext connects to Salesforce through the REST API over OAuth.
Qontext only reads data; it never creates, edits, or deletes anything in Salesforce. Access is always bounded by the connected user's own Salesforce permissions, so Qontext can only sync records that account can already see.
**Supported objects:**
| Object | Description |
| - | - |
| `Accounts` | Company and customer records |
| `Contacts` | People associated with accounts |
| `Opportunities` | Sales deals in the pipeline, including stage, amount, and close date |
| `Leads` | Unconverted prospects and their qualification state |
| `Cases` | Support cases and their case comments (public comments by default) |
| `Emails` | Emails logged against a record (`EmailMessage`) |
| `Tasks` | Logged activities: to-dos, logged calls, and other actions against records |
| `Events` | Calendar events and meetings tied to records |
| `Call transcripts` | Service Cloud Voice calls, synced as a turn-by-turn text transcript |
| `Notes` | Enhanced Notes (`ContentNote`) attached to records |
| `Custom objects` | Any custom object (`*__c`) you select; all of its queryable fields are synced |
**Unsupported:**
| Object | Description |
| - | - |
| `Files and attachments` | Binary files stored in Salesforce (documents, images) are not synced. Text notes are synced (see `Notes` above) |
| `Chatter` | Feed posts and comments |
| `Reports and dashboards` | Derived aggregates rather than source records, so there is no underlying text to sync |
| `Call recordings` | The audio of a call is not synced; only its text transcript is |
***
## Recommended setup
Use a **dedicated integration user** in your Salesforce org to ensure a stable and uninterrupted connection.
Create a service account such as `qontext@yourcompany.com`, assign it a read-only profile or permission set, and grant it access to the objects and records you want Qontext to sync. This prevents sync disruptions when employee accounts or permissions change.
The integration user will:
* Authenticate the connection between Qontext and Salesforce.
* Access the selected records with read-only permissions.
Qontext requests the `api`, `refresh_token`, and `id` OAuth scopes: `api` to read records over the REST API on behalf of the connected user, `refresh_token` to keep syncing without re-authentication, and `id` to identify the connected org and user. The connection uses OAuth with PKCE.
***
## Setting up the connection
Connecting Salesforce has two parts: a Salesforce administrator installs the Qontext app once in the Salesforce org, then a Salesforce user authorizes the connection. After that, choose what to sync and how often.
You can also manage all your credentials, including Salesforce, from the **Sources** page.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **Salesforce** from the list of available data sources. This starts the Salesforce connection flow.
When creating the first connection to a Salesforce org, Qontext asks you to install the Qontext app in that org. The app only needs to be installed once per Salesforce org.
Select **Open install page**. In Salesforce, choose **Install for All Users** (recommended), then finish the installation. If you install the app for administrators only or for specific profiles, only those users can connect Salesforce to Qontext.
Installing the app requires the `Download AppExchange Packages` permission, which Salesforce administrators have by default. If you do not have this permission, send the installation link to your Salesforce administrator.
Return to Qontext and select **Continue connecting**.
You can **reuse existing Salesforce credentials** (if you've already connected this account to Qontext) or **create a new connection**.
If you create a new credential, sign in with Salesforce when prompted. On the consent screen, review the requested permissions and click **Allow** to grant Qontext read access to your Salesforce data.
Select what Qontext should sync into your context repository. By default, Qontext syncs every record of the standard objects (accounts, contacts, opportunities, leads, cases, emails, tasks, events, call transcripts, and notes).
You can narrow this down, sync only specific records, add related records, restrict by date, and include custom objects. See [Filtering what gets synced](#filtering-what-gets-synced) below for the full set of options.
Choose how often Qontext should refresh data from Salesforce (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (account, selection, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Filtering what gets synced
When configuring the connection, you choose how Qontext selects records. The default is to sync **all records of the standard objects**; the options below let you scope that down or extend it.
Sync every record of the object types you select. Clear the objects you don't need, or add custom objects you do. This is the default.
Instead of syncing everything, hand-pick specific records of a single object (for example a set of key accounts), then let Qontext pull in the related records connected to them, such as their contacts, opportunities, cases, and emails. You can expand up to two levels of relationships (related records, and the records related to those).
Limit a sync to records created on or after a chosen date. This is useful for high-volume objects like tasks and events, where you rarely need the full history.
Custom objects (`*__c`) are off by default. Select the specific custom objects you want (for example `Project__c` or `Contract__c`) and Qontext syncs their records with all queryable fields.
When cases are in scope, Qontext syncs **public case comments only** by default. You can enable **Include private comments** to also sync internal comments. Because private comments are meant for internal handoffs, enabling this makes their content retrievable by anyone with access to the source, so it is off by default and opt-in.
***
## Sync latency
The initial sync time depends on how many objects and records are in scope. Large orgs can take **up to 12 hours** to fully sync.
Subsequent syncs are **incremental**: Qontext processes only the records that were added or changed since the last sync, which runs much faster than the initial sync.
***
## Managing permissions
### Salesforce app installation
The Qontext app must be installed once in each Salesforce org you want to connect. Installation requires the `Download AppExchange Packages` permission, which Salesforce administrators have by default.
Installing the app makes the OAuth connection available in the org, but it does not give Qontext unrestricted access to Salesforce data. Qontext can only sync records available to the connected Salesforce user.
### Salesforce OAuth scopes
When connecting, you authorize Qontext against your Salesforce org. Qontext requests these scopes:
```text theme={null}
- api Access and read your data through the REST API, as the connected user
- refresh_token Keep the connection active so scheduled syncs run without re-authentication
- id Identify the connected Salesforce org and user
```
Qontext uses this access only to **read** records. It never creates, edits, or deletes anything in Salesforce, and the `api` scope operates on behalf of the connected user, so Qontext can only ever see what that account can see.
### Salesforce permissions
* Use a **single integration user** to manage Salesforce access for Qontext to avoid permission conflicts.
* If you don't see an object or record during filter setup, verify that the connected account has access to it in Salesforce.
***
## FAQ
A Salesforce administrator must first install the Qontext app in the Salesforce org. Once it is installed, any Qontext workspace member whose Salesforce user has access to the installed app and the relevant records can connect the data source.
No. Qontext only reads records. It never creates, edits, or deletes data in Salesforce.
Qontext connects to Salesforce production orgs by default. If you need to connect a sandbox org, contact [support@qontext.ai](mailto:support@qontext.ai).
Yes. Custom objects are opt-in: select the specific custom objects you want during filter setup, and Qontext syncs their records with all queryable fields.
Objects that depend on Service Cloud, such as cases and Voice call transcripts, simply return nothing if your org doesn't use them. The rest of the connection works the same way.
Yes. You can create multiple Salesforce connections from the **Sources** tab in your Qontext workspace. Add each org as a separate data source and install the Qontext app once in each org.
Manual refresh is available via the **Sources** tab. Navigate to the respective Salesforce connection and open the **Syncs** tab. In the sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
Disconnecting stops further syncs. Content already synced from Salesforce remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
By default, Qontext only syncs records the connected Salesforce account can access. Additionally, you can add [filters](#configure-what-to-sync-filters) to every connection as described in the setup flow.
# SharePoint
Source: https://docs.qontext.ai/sources/sharepoint
Connect SharePoint with Qontext
## Overview
The SharePoint connection allows Qontext to read documents, site pages, and lists from your SharePoint sites and sync their text content into your context repository. It connects to SharePoint Online through the Microsoft Graph API.
Only sites and content that the connected Microsoft account can access will be synced into your context repository. SharePoint permissions are always respected.
**Supported data types:**
| Object | Description |
| - | - |
| `Documents` | Files in document libraries: `docx`, `pptx`, `xlsx`, `pdf`, `rtf`, `txt`, `csv`, `md`, `odt`, `odp`, `ods`, and `html` (up to 50 MB per file) |
| `Site pages` | SharePoint pages, including news posts and other modern pages |
| `Lists` | SharePoint lists with their items and columns |
**Unsupported:**
| Object | Description |
| - | - |
| `Other file types` | Images, audio, video, and file types not listed above |
| `Scanned PDFs` | Image-only PDFs contain no extractable text and are not OCR processed |
| `Large files` | Files over 50 MB are skipped |
***
## Recommended setup
Use a **dedicated integration user** in your Microsoft 365 tenant to ensure a stable and uninterrupted connection.
Create a service account such as `qontext@yourcompany.com` and grant it read access to the SharePoint sites you want Qontext to sync. This prevents sync disruptions when employee accounts or permissions change.
The integration user will:
* Authenticate the connection between Qontext and SharePoint.
* Access the selected sites with read-only permissions.
The connection uses Microsoft's read-only `Sites.Read.All` permission, which requires **admin consent** in most Microsoft 365 tenants. Have an administrator approve the consent request the first time you connect.
***
## Setting up the connection
You can connect SharePoint from your Qontext workspace, authorize access with your Microsoft account, then choose what to sync and how often. The steps below walk you through the full flow.
You can also manage all your credentials, including SharePoint, from the **Sources** page.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **SharePoint** from the list of available data sources. This starts the SharePoint connection flow.
You can **reuse existing SharePoint credentials** (if you've already connected this Microsoft account to Qontext) or **create a new connection**.
If you create a new credential, sign in with Microsoft when prompted. On the consent screen, review the requested permissions and click **Accept** to grant Qontext read access to your SharePoint content.
Select what Qontext should sync into your context repository. Add entire sites, or open a site to select specific document libraries, folders, individual files, pages, and lists.
Click the **+** next to an item to add it, or click its name to navigate into it for a more granular selection. Selected items appear at the top. Use the file type dropdown next to a selected library or folder to limit which file types are synced from it.
Choose how often Qontext should refresh data from SharePoint (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (account, selection, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Managing permissions
### SharePoint OAuth scopes
When connecting, you'll see a Microsoft consent screen listing the permissions Qontext needs; they are read-only:
```text theme={null}
- Sign you in and read your profile
- Read items in all site collections
- Maintain access to data you have given it access to
```
"Read items in all site collections" is Microsoft's wording for the `Sites.Read.All` permission. It applies on behalf of the connected user, so Qontext can only ever see what that account can see. Qontext does not create, edit, or delete anything in SharePoint.
### SharePoint permissions
* Use a **single integration user** to manage SharePoint access for Qontext to avoid permission conflicts.
* If you don't see a site or library during filter setup, verify that the connected account has access to it in SharePoint.
***
## Sync latency
The initial sync time depends on how many sites, documents, pages, and lists are in scope. Large environments can take **up to 12 hours** to fully sync.
Subsequent syncs are **incremental**: Qontext uses SharePoint's built-in change tracking to process only what was added, changed, or removed since the last sync. Renamed or moved files are updated in place instead of duplicated.
***
## FAQ
Any workspace member with a Microsoft account that has access to the relevant SharePoint sites. Because the `Sites.Read.All` permission requires admin consent in most tenants, a Microsoft 365 administrator may need to approve the connection the first time.
Qontext supports **SharePoint Online** (Microsoft 365). On-premises SharePoint Server deployments are not supported. If you use SharePoint Server, contact [support@qontext.ai](mailto:support@qontext.ai) to discuss your options.
Yes. You can create multiple SharePoint connections from the **Sources** tab in your Qontext workspace. Add each account or tenant as a separate data source.
Manual refresh for SharePoint connections is available via the **Sources** tab. Navigate to the respective SharePoint connection and open the **Syncs** tab. In the Sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
Disconnecting stops further syncs. Content already synced from SharePoint remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
By default, Qontext only syncs content the connected Microsoft account can access. Additionally, you can add [filters](#configure-what-to-sync-filters) to every connection as described in the setup flow.
# Slack
Source: https://docs.qontext.ai/sources/slack
Connect Slack with Qontext
## Overview
The Slack connection allows Qontext to read messages and threads from channels in a connected Slack workspace and ingest their text content into your context repository.
Only channels and content that the connected Slack app can access will be ingested into your context repository.
Slack can also work in the other direction. With **Qontext Tag**, you mention `@Qontext` in a channel or thread and get answers from your context repository inside Slack. See [Qontext Tag in Slack](/features/qontext-tag/slack).
**Supported data types:**
| Object | Description |
| - | - |
| `Channel messages` | Messages posted in channels the app is invited to |
| `Threads` | Replies and thread conversations linked to channel messages |
***
## Setting up the connection
You can connect Slack from your Qontext workspace, authorize access in Slack, then choose how often to sync. The steps below walk you through the full flow.
In the [Qontext app](https://app.qontext.ai), open your workspace and go to the **Sources** tab, then click **+ Connect data source**.
Choose **Slack** from the list of available data sources. This starts the Slack connection flow.
You can **reuse existing credentials** (if you've already connected this Slack workspace to Qontext) or **create a new connection**.
If you create a new credential, sign in to Slack when prompted and select the workspace you want to connect. On the Slack consent screen, review the requested permissions and click **Allow**. At this step the Qontext app is added to your Slack workspace so it can read the channels you authorize in the next step.
Select the channels you want Qontext to ingest. Only channels in which the Qontext app is a member can be ingested.
**Public channels** are automatically joined by the Qontext app when you select them.
For **private channels**, the Qontext app must be added as a member first. In Slack, open the channel and type `/invite @Qontext`.
You can add a **time filter** to limit how far back messages are synced. The time filter is only available after a channel has been selected: click **All** at the top next to the selected channel to open the date range option.
Choose how often Qontext should refresh data from Slack (e.g. daily, weekly, monthly). More frequent syncs keep the context repository up to date but use more resources.
Review your choices (workspace, channels, time filter, frequency), then confirm to create the connection. Qontext will start the initial sync shortly after.
***
## Managing permissions
### Slack OAuth scopes
When you connect Slack, you’ll see a consent screen titled **Allow the 'Qontext' app to access Slack**. It lists the permissions (scopes) Qontext needs; they are read-only. You’ll see categories such as:
```text theme={null}
- Content and info about channels & conversations — Messages, files, and other content in public and private channels, direct messages, and group conversations.
- Content and info about your workspace — User lists, channel lists, workspace settings, and other workspace-level metadata.
```
Granting these scopes is required for the connection to work. Qontext only reads data from Slack to ingest it into your context repository; it does not post messages or change anything in your workspace.
***
## Sync latency
The initial sync time depends on how many channels and messages are in scope. Large workspaces with many active channels can take **up to 12 hours** to fully index.
Subsequent syncs process **incremental changes** and typically complete much faster than the initial sync.
***
## FAQ
Any Slack workspace **Admin** or member with permission to install apps can set up the Slack connection. Ensure the account can invite the Qontext app to the channels you want to ingest.
Yes. You can connect multiple Slack workspaces from the **Sources** tab in your Qontext workspace. Add each workspace as a separate data source.
Manual refresh for Slack connections is available via the **Sources** tab. Navigate to the respective Slack connection and open the **Syncs** tab. In the Sync settings, select **Sync latest data** to pull recent changes, or **Resync all data** to rebuild the source from scratch.
Disconnecting stops further syncs. Content already ingested from Slack remains in your context repository. For data removal, contact [support@qontext.ai](mailto:support@qontext.ai).
Initial sync time varies: small or lightly used workspaces may finish in under an hour; very active workspaces with many channels and messages can take up to 12 hours. Subsequent syncs are incremental and faster.
Reconnect the integration and validate that the Qontext app is still invited to the relevant channels and has the required scopes. If the issue persists, contact [support@qontext.ai](mailto:support@qontext.ai).
Yes. All data is encrypted in transit (TLS) and at rest. Qontext only accesses channels and messages you explicitly authorize via the Slack OAuth flow.
For **private channels**, the Qontext app must be added as a member first. In Slack, open the channel and type `/invite @Qontext`.
}
href="/clients/chatgpt"
>
Connect via MCP for context-aware conversations.