1. Add public docs and test real questions
Free is permanent: one site, up to 10 pages, and 100 messages per month with no credit card. Check the answers and sources, then embed the widget when you are ready.
Technical documentation chatbot
Add a chatbot to your technical documentation
Start with your public docs, test real technical questions, and check the linked sources before you add the widget to your site.
Permanent Free: 10 pages, 100 messages/month, no cardSupported answers can link back to source content
Start with a small documentation test
Generic AI
Why generic chatbots fail your users
General-purpose AI chatbots try to be conversationalists. Without source grounding, they can answer confidently from the wrong context.
- They may suggest non-existent features
- They can give outdated code examples
- They can reference competitors' products
- They can frustrate technical users
ChattyBox
How ChattyBox is different
We use retrieval-augmented generation against your published docs and site content, then show source links where answers came from.
For teams that need visible evidence in every answer, compare the workflow for a source-cited AI chatbot that keeps documentation traffic connected to supporting pages.
- Answers grounded in your docs and source pages
- Direct citation links to source pages
- Fallback behavior when source info is missing
- Code examples stay tied to indexed source pages
Documentation chatbot in practice
Questions a documentation chatbot should answer
Use questions your support and community channels already see. Check each answer and its linked source page before publishing the widget.
01
“How do I get started, authenticate, and make my first request?”
02
“What does this error mean, and where is the fix documented?”
03
“What are the plan limits, rate limits, and pricing for this feature?”
04
“Do I need to migrate my docs platform, or can this sit beside my current site?”
For engineering audiences, review the API documentation checks, or learn how to measure support ticket outcomes from your existing content.
Choose your stack
AI Chatbot for Docusaurus with CitationsAdd an AI chatbot to your Docusaurus docs. Answers cite the exact pages used, setup is one script tag, and a free plan lets you test before you pay.
MkDocs AI Chatbot for Source-Cited DocsAdd an AI chatbot to MkDocs or Material for MkDocs that answers from your docs and cites source pages. No Python pipeline or custom RAG required.
API documentation needs precise source boundaries
Use the chatbot to help developers find endpoints, authentication steps, parameters, SDK methods, and known errors, then return to the reference for full context. A plausible code example or a visible citation is not proof of correct API behavior.
- Check extracted content first. The crawler does not execute page JavaScript; interactive reference pages may not expose endpoint details in fetched HTML. A discovered URL alone does not mean the reference was indexed completely.
- Scope versions deliberately with selected URLs or separate projects. Check method, path, required fields, permissions, pagination, and rate limits against the intended version, without blending old SDK examples or migration steps.
- Test undocumented endpoints, unknown error codes, ambiguous versions, and requests involving credentials. Require a clear limitation or next step rather than guessed behavior. Never put secrets into a public source set or test prompt.
Evaluation guide, not measured results
A reusable evaluation framework for technical documentation
Build the test set from real documentation tasks, attach a gold source and expected facts to every answerable question, and include questions the assistant must decline. Score each category separately so a strong API result cannot hide weak migration or authentication guidance.
- Technical author
- ChattyBox Engineering
- Technical reviewer
- ChattyBox Documentation Review
- Last updated
- Information checked
- July 9, 2026
Re-run the suite before launch, after material documentation or retrieval changes, and on a scheduled monthly sample after launch.
| Question area | Test fixture | Pass condition |
|---|---|---|
Question area API | Test fixture Endpoint, required fields, response shape, and rate limit. | Pass condition Uses the documented method and path; required values and citation agree with the reference. |
Question area SDK | Test fixture Install and initialize one supported SDK version. | Pass condition Package, import, initialization, and code syntax match that language and version. |
Question area CLI | Test fixture Install, authenticate, run a command, and interpret output. | Pass condition Flags and ordering are valid; the answer does not invent interactive prompts. |
Question area Authentication | Test fixture Credential location, header format, scopes, and one forbidden flow. | Pass condition Never exposes a secret, distinguishes client and server use, and cites the security requirement. |
Question area Pagination | Test fixture First page, continuation, terminal page, and maximum page size. | Pass condition Uses the documented cursor or offset model and states only documented limits. |
Question area Errors | Test fixture Known error code, likely cause, recovery step, and unknown code. | Pass condition Maps known errors correctly and falls back for undocumented causes. |
Question area Migrations | Test fixture Breaking change, prerequisite, ordered steps, and rollback note. | Pass condition Preserves sequence and warnings without blending old and new procedures. |
Question area Versioned docs | Test fixture Ask the same behavior question for current, prior, and unspecified versions. | Pass condition Answers the named version, asks when ambiguous, and cites that version. |
Primary sources and reproducible evidence
Explicit acceptance rules
Publish the rules before testing. Reviewers should reach the same result from the answer, expected facts, and cited source without relying on how persuasive the response sounds.
| Dimension | Accept only when |
|---|---|
Dimension Answer quality | Accept only when All required facts are correct, relevant, non-contradictory, and use the requested API, SDK, CLI, or documentation version. |
Dimension Citation accuracy | Accept only when Every material claim has a resolving citation that directly supports it on the correct versioned page. |
Dimension Fallback behavior | Accept only when Missing, ambiguous, conflicting, or unauthorized evidence produces a clear limitation and a useful next step instead of a guess. |
Dimension Launch gate | Accept only when Zero unsupported critical authentication or migration claims, 100% pass on critical cases, at least 90% overall acceptance, and at least 95% citation accuracy. |
Example evaluation fixture, not measured results
Method: write 24 questions before running the assistant, three for each matrix area. For every question, record the intended version, gold page, required facts, forbidden claims, and whether fallback is expected. Two reviewers independently score the frozen answers, reconcile disagreements against the source, and retain the prompts and outputs for regression testing.
Every figure below is a hypothetical example for a 24-question fixture, not a measured ChattyBox result, production average, or promise of future performance.
| Example result, not measured | How to use the example |
|---|---|
Example result, not measured Example: 22 of 24 accepted (91.7%) | How to use the example Example interpretation: 20 supported answers and two correct fallbacks. |
Example result, not measured Example: 20 of 22 substantive answers cited directly supporting pages (90.9%) | How to use the example Example interpretation: below the 95% launch gate, so version ranking needs correction. |
Example result, not measured Example: 2 of 2 expected fallbacks were correct (100%) | How to use the example Example interpretation: no answerable case incorrectly fell back in this small fixture. |
Example result, not measured Example: 1 of 24 contained an unsupported pagination detail (4.2%) | How to use the example Example interpretation: block launch until the unsupported claim is removed and the regression passes. |
Core Capabilities
Built for documentation and support sites
Purpose-built workflows that keep answers traceable, grounded, and useful for technical users.
Instant Scraping
Enter your docs, website, or sitemap URL. ChattyBox crawls and indexes the pages users already read.
Strict Guardrails
The answer flow is configured to use retrieved context and avoid unsupported API, feature, pricing, or policy claims.
Source Linking
Answers can include links back to the documentation pages where the relevant information lives.
Documentation chatbot rollout checklist
Treat launch as a documentation release with owners, gates, observability, and a rollback path.
- 1Inventory public and restricted sources; assign an owner and intended audience to each.
- 2Exclude secrets, drafts, duplicate pages, unsupported versions, and private paths from the public chatbot source set.
- 3Create answerable, unanswerable, ambiguous, adversarial, and version-conflict test cases across all eight matrix areas.
- 4Run the acceptance suite, inspect citations manually, and block launch on any critical unsupported claim.
- 5Pilot on a limited audience; record feedback, unresolved questions, latency, and escalation behavior.
- 6Publish an owner, re-index schedule, incident path, rollback condition, and recurring regression cadence.
Post-launch metrics that lead to action
Segment every metric by topic, documentation version, locale, and audience where sample size permits. Trends and reviewed samples are more useful than one aggregate score.
| Metric | Definition and action |
|---|---|
Metric Answer rate | Definition and action Share of questions receiving a substantive answer. Review low-rate topics for missing content; do not improve the number by weakening fallback. |
Metric Unresolved questions | Definition and action Questions with fallback, negative feedback, repeated rephrasing, or escalation. Sample them weekly for answer and retrieval defects. |
Metric Content gaps | Definition and action Unresolved clusters where no authoritative page exists. Route these to the docs backlog with frequency and user impact. |
Metric Citation support rate | Definition and action Reviewed material claims with a direct supporting citation. Investigate drops by source and version. |
Metric Ticket deflection | Definition and action Eligible sessions that resolve without a support ticket, measured with a defined window and compared with a baseline. Report association unless an experiment establishes causality. |
Use the RAG architecture and evaluation guide to diagnose retrieval, the citation workflow to review evidence, the API documentation checks for engineering-specific use cases, and the technical launch checklist for deployment steps.
Documentation chatbot FAQ
Common questions about AI documentation chatbots
These answers summarize how ChattyBox reads source content, cites documentation pages, handles missing information, and installs alongside an existing docs stack.
Can I use a chatbot for API documentation?
Yes, when endpoint references, parameters, authentication guides, SDK examples, and error details are present in indexed public content. It does not execute API calls or inspect private accounts. Retrieved context and citations do not eliminate invented API behavior; test important claims against the reference.
Is Free a trial?
No. Free is a permanent small-scope proof: one site, up to 10 pages, and 100 messages per month with no credit card.
Which documentation pages should I start with?
Start with the public pages that answer common setup, troubleshooting, pricing, and product questions. You can expand the source set after you have checked the first answers.
When should I add more documentation?
Add more pages when the first test set is useful and the supporting sources are current. Keep private, outdated, and unrelated pages out of the chatbot.
Can I test answers before I install the widget?
Yes. Crawl the selected public docs, ask real technical questions, and open the cited source pages to review answers before installing the widget on your docs site.
What happens when the docs do not support an answer?
The assistant should state the limitation or offer a useful next step instead of guessing. Treat unsupported answers as a test case and a possible documentation gap to review.
Prove the answers before you install
Start with the permanent Free proof for selected public pages, test technical questions, and inspect sources before embedding the widget.
Permanent Free: 10 pages and 100 messages/month