Document an API in your Chatonio knowledge base

Chatonio’s knowledge base has a built-in API endpoint block that renders one HTTP endpoint with method + path + summary + multiple request and response examples — the same shape Stripe and other API docs use. Each block lives inside an article alongside normal prose, so a single article can describe a feature in plain language and document its endpoints in the same place. The AI grounds answers on the same text, so customers and the AI stay on one source of truth.

Step 1 — Open the article editor

Go to Admin → Projects → [your project] → Knowledge Base, pick (or create) a category, then New article. The Tiptap WYSIWYG editor opens.

Step 2 — Insert an API endpoint block

In the editor toolbar, click the Insert API endpoint button (the icon with two stacked rows). A card drops into the document at the cursor position with default fields filled in. Type over them.

Step 3 — Method, path, and summary

• Method — dropdown, color-coded per verb (GET green, POST blue, PUT/PATCH amber, DELETE red). The pill in the rendered output picks up the same color.
• Path — the endpoint path, e.g. /v1/orders/{order_id}/refund. Curly-brace placeholders are kept verbatim.
• Summary — one or two sentences saying what the endpoint does and when to use it. This is what the AI sees first.

Step 4 — Add request examples

The Request section starts with one example called Default. Click + Add example to add more — useful when the same endpoint accepts both a JSON body and a form-encoded body, or when there are different shapes for different intents (partial vs full refund, for example). Each example has its own label, language picker, and body field. Pick the language so the code block gets the right syntax highlighting in the rendered view.

Step 5 — Add response examples (success and error)

This is where most API docs fall short. The Response section accepts as many examples as you want, each with its own HTTP status code. Status codes are color-coded by family in both the editor and the rendered output:

• 2xx — green, success.
• 3xx — blue, redirect.
• 4xx — amber, client error.
• 5xx — red, server error.

Document at least one success and the most common error responses customers will hit (400 validation, 404 not found, 409 conflict). The AI sees all of them at once — so when a customer pastes an error message, it can find the right entry without you writing a separate troubleshooting article.

Step 6 — Use code blocks for non-endpoint code

For SDK snippets, configuration files, shell commands, etc., use the regular Code block button in the toolbar. When the cursor is inside a code block, a language picker appears next to the toolbar; pick json, bash, http, javascript, or typescript for syntax highlighting:

$ curl https://api.example.com/v1/health \
    -H "Authorization: Bearer $TOKEN"

Both inline and rendered surfaces show a copy button on hover.

Sample — a refund endpoint

This is exactly what an endpoint block looks like once published. The customer sees the rendered card; the AI sees the text content stripped to a clean ordered list of method/path/summary/examples.

{
  "amount_cents": 1500,
  "reason": "customer_request",
  "request_id": "req_a3f8"
}

{
  "reason": "duplicate_charge",
  "request_id": "req_b2c9"
}

{
  "id": "rf_29df",
  "order_id": "ord_8821",
  "amount_cents": 1500,
  "status": "succeeded"
}

{
  "error": "amount_cents exceeds order total"
}

{
  "error": "order not found"
}

{
  "error": "order already fully refunded"
}

Tips

• One endpoint per block. Don’t pack two endpoints into one card — you’ll lose color coding and the AI grounds worse.
• Keep examples small and realistic. Customers and the AI both retain less from a 50-line response than from a 5-line one.
• Document the errors. Customers paste error messages — the AI matches them directly to a documented response and answers in one turn.
• Visibility matters. Set the article to PUBLIC if you want it on the public helpdesk, INTERNAL if it’s ops-only. The AI uses both tiers — visibility only gates rendering for end users.