Knowledge sources API

The external AskAnyDocs API is currently focused on read-only team, bot, conversation, and message data. Knowledge-source management is not part of the public bearer-token API reference today.

Current API boundary

The public external API does not currently expose endpoints for:

• creating website resources
• adding sitemap resources
• submitting URL lists
• uploading files
• deleting knowledge sources
• triggering indexing from a bearer-token integration

Those flows exist inside the dashboard experience and are designed for authenticated app users. This boundary prevents integrations from accidentally changing bot knowledge without the review and selection steps available in the UI.

What you can do today

Today, the public external API is focused on:

• reading account stats
• reading plan and usage data
• reading bots
• reading bot stats
• reading conversations
• reading messages
• retrieving read-only bot, conversation, and message data

This is useful for analytics, reporting, support review, and exporting conversation data into internal systems.

How to manage knowledge sources

Use the AskAnyDocs dashboard to add and manage bot content. The dashboard supports:

• website discovery
• sitemap discovery
• URL lists
• uploaded files
• page selection before indexing
• indexing status review

The dashboard is the recommended place to manage content because it shows what will be indexed and helps avoid accidental inclusion of irrelevant pages.

Why source management is separate

Knowledge sources directly affect what the assistant can answer. A poorly selected sitemap, outdated file, or broad website crawl can reduce answer quality. Keeping source management in the dashboard makes it easier for a human to review selected pages and understand plan capacity before indexing.

This is especially important for:

• pricing and plan pages
• policy documents
• technical specifications
• customer support articles
• internal documentation

Recommended integration approach

If you need to manage knowledge sources programmatically right now, the practical approach is:

1. manage bot content through the dashboard
2. use the external API for reporting or downstream analytics
3. use the website widget flow separately from the external bearer-token API
4. review conversations to decide which source documents need improvement

For most teams, this is enough to support an operational workflow: content managers maintain the source material in the dashboard, while developers use the external API to analyze usage and conversation history.

Common misconception

The widget embed script and dashboard resource flows are not the same as the external API. The widget lets visitors chat with a specific bot. The dashboard lets authenticated users manage content. The external API lets server-side integrations read team and bot data with a bearer token.

Keeping these surfaces separate makes permissions and security easier to reason about.

Planned documentation boundary

This section exists so external API users do not confuse internal dashboard routes with supported bearer-token integration endpoints. If public source-management endpoints become available, they should be documented as explicit external API operations with authentication, request examples, response examples, and failure modes.

Related articles