Knowledge Base

The six AI surfaces that call KB retrieval — Specialist agents, voice, Sidekick, Self-Learning, the in-app editor, and public help center search.

Settings and usage guidance for the five section and role blocks — Section grid, Section list, Section bar, Role grid, and Role bar.

Settings and usage guidance for the seven search and listing blocks — Hero search, Compact search, Quick links, and the category and article listing blocks.

A minimal, complete Python script that upserts Markdown articles into the KB via /api/v1/kb — creates by slug, updates existing, upserts categories by name.

After an API push: embeddings rebuild automatically within ~10 minutes, translations need an explicit sync, and roles/sections/settings stay editor-only.

Settings and usage guidance for the six communication and layout blocks — Announcement, What's new, Contact CTA, System status, Spacer, and Video embed.

Authoring habits that make articles rank in AI retrieval — customer wording, answer-first leads, one topic per article, and the keywords field.

Run translations on demand from a language's Translation Sync card. Nothing auto-translates — edits and new articles wait for the next Sync Translations run.

What a doc-as-code push script must do: slug-based lookup, PATCH-or-POST upserts, categories before articles, and the frontmatter contract.

The five known gotchas in a GitHub-to-KB sync pipeline — 500-article pagination, duplicate categories, embedding lag, manual translation sync, leaked keys.

Yes — subscribe to the kb.article.created/updated/deleted webhook events so an external system can react when your knowledge-base content changes.

Reference for translation coverage in Atender — the Translation Sync card shows per-language counts for articles, categories, and subcategories. Job statuses are pending, scanning, translating, completed, failed.

Reference for the retrieval pipeline. Hybrid keyword + vector search over chunks, fused with Reciprocal Rank Fusion, then dedeplicated to the article level. Roles do not affect retrieval — they are browsing-visibility only.

A 90-day review cadence — list articles by lastReviewedAt, walk the oldest, decide keep / update / archive. Keeps the help center honest without turning it into a project.

A working doc-as-code setup. Markdown articles in a GitHub repo, a Python push script, a GitHub Actions workflow that syncs to Atender's v1 API on every push to main. Copy-paste workflow inside.

Open Settings → API Keys, click Create Key, select knowledge:read and knowledge:write, give it a name, and copy the key once it appears — it's only shown one time.

Toggle a language off with the Active switch to hide it without losing translations. Click the trash icon to delete the language and its translations permanently. The primary language can't be deleted.

Open Settings → Knowledge → Templates and click Add Template. Fill in name, description, and the content you want every new article of this type to start from. Authors pick the template when creating articles.

Open Settings → Knowledge → Markets and Languages → Markets, then add the regions and countries your customers care about. Global is always on. Removing a market hides any market-specific filters in the public help center.

The most common cause is that the language is Disabled, or the article hasn't been translated yet because Sync Translations hasn't run since you edited it. Walk through the four checks in this article.

A naive POST creates a duplicate with a -1 slug suffix. A push script that looks up the slug first and PATCHes when it exists stays idempotent. The v1 API doesn't deduplicate on its own.

Yes — three lever points. Article status is the kill switch. Capability scope narrows what each AI agent can retrieve. Roles do not affect retrieval — they control browsing visibility only.

Markets are regions (countries, continents, or "global") that let visitors filter content. Languages are the translation axis. They live on the same settings tab but answer different questions — geography vs. text.

Author articles in a Git repo, sync them to Atender on every commit. This is the same pattern Atender uses for its own help center. The v1 API gives you idempotent upserts when paired with a small client-side push script.

The Page Settings panel in the layout builder has four toggles that switch global help-center features on or off — breadcrumbs, search, dark mode, and the language selector.

The Improve action rewrites for clarity and flow — more invasive than Clean Up, less invasive than starting over. Use it when content is solid but the writing reads stiff.

The Clean Up action in the article editor fixes typos, grammar, and awkward phrasing without changing the article's structure or meaning. It's a fast proofread before publish.

Change an article's status to needs-review when it should be looked at before going live or before staying live. It hides from the public and the AI while staying visible to admins with a flag.

Flip the four page-level toggles — breadcrumbs, search, dark mode, language selector — in Settings → Knowledge → Design → Layout → Page Settings.

Archive a Knowledge Base article when the feature it describes is gone or the article has been superseded. Archived articles stay in the database but disappear from the public site and AI retrieval.

An article you've published isn't showing up on the public site? Walk through the five most common causes — status, role assignment, category visibility, custom domain routing, and cache.

After you publish or edit a published article, your AI agents start using the new version within about a minute. The embedding pipeline runs automatically — there's no rebuild button to press.

Every Knowledge Base article moves through the same shape — draft, review, published, eventual review again, and archived. Knowing the cadence keeps your help center accurate without ceremony.

The article editor includes an AI Writing Assistant with three direct actions — Clean Up, Improve, and a free-form prompt input. Each one does a specific job; knowing which to reach for is the whole skill.

Tags, roles, and sections all group articles in different ways. Tags describe content. Sections present articles. Roles control who sees what. Pick by what you're trying to do.

All 18 blocks in the Knowledge Base layout builder at a glance, grouped by family, with links to the detailed settings reference for each family.

Atender Knowledge Base articles have four statuses. Each controls whether the article is visible publicly, indexed by AI, and surfaced in the editor's review queues.

A two-week plan to launch a Knowledge Base from zero — categories, the first 25 articles, branding, custom domain, and AI agents pulling from it.

The editor has an AI write helper that drafts an article from a title and a few notes. It speeds up first drafts; it doesn't replace your review.

Roles in the Knowledge Base are browsing-visibility tags. Tag an article with a role and only visitors viewing that role see it on the public help center. Roles do not bias AI retrieval.

Map your help center to a domain like help.example.com. You configure the host in Atender, add a DNS record, and the SSL certificate provisions automatically.

Generate an API key with knowledge:write, ensure the category exists with POST /api/v1/kb/categories, then POST or PATCH the article with /api/v1/kb/articles. Embeddings rebuild on the server.

Categories are the top-level buckets on your help site. Subcategories are an optional second level. Both are created from the Knowledge Base's category tree.

Protect terms that should never be translated, or specify how a term translates in a particular language. Useful for brand names, product names, and locale-specific terminology.

Add a language in Settings → Knowledge → Markets and Languages. New languages start disabled; toggle Active when ready. Translations run on demand via the Translation Sync card.

Open Settings → Knowledge → Design, drag blocks onto each page (homepage, category, article), edit each block's settings, and save. The public site usually updates shortly after save; anonymous public pages can lag briefly because of CDN caching.

Open the Knowledge Base, pick a category, click New article, and write. Status, summary, and category are required; everything else can be filled in later.

Open Settings → Knowledge → Sections, click New section, choose between rule-based auto-fill or a manual article list, and save.

Upload your logo, set primary and accent colors, configure light and dark themes, and choose the favicon and Open Graph image — all from Settings → Knowledge → Design.

Select multiple articles in the article list and apply a status change, category move, or archive in one click.

An article that exists but doesn't show up in search is almost always one of five things. Walk through the list before assuming the search is broken.

The Knowledge Base is your public help center — a place customers self-serve answers, and the same place your AI agents read from when they answer for you.

Sections are an alternative way to group articles — separate from categories. Use them for "Most popular", "For developers", "Recently updated" lists that cut across your category structure.

Write articles in your default language. Atender translates them on demand into every active language. Protected terms stay untranslated. Customers see the language their browser prefers, with a manual override.

Atender's KB search blends keyword matching with semantic vector search. The same retrieval pipeline powers the public help-center search box and AI agents like Sidekick, Web Chat, and voice.

Your public help center is built from blocks dropped onto a layout. Each page — homepage, category, article — has its own block stack, drag-and-drop in the layout builder.

Atender exposes a stable v1 API at /api/v1/kb/* for managing your Knowledge Base from outside the in-app editor. Use it for doc-as-code pipelines, automated content imports, or sync with another system.