​

Octen Documentation

Mintlify-based product docs for Octen (docs.octen.ai).

​

Setup

• Local preview: mint dev --port 3000 (run from repo root)
• Navigation, theme, and redirects live in docs.json
• Check links before publishing: mint broken-links

​

Core rules

1. Never fabricate. Do not guess URLs, slugs, parameters, product behavior, or numbers. Verify against source files (api-reference/openapi.json, existing pages) or ask. If unsure, leave a {/* TODO: ... */} and ask; never invent.
2. Be concise. No redundancy. If one sentence is enough, don’t write two.
3. Match existing docs. Before writing a page, read similar existing pages and follow their structure, terminology, and formatting.
4. No unrequested changes. Do not restructure navigation, rename pages, or touch files beyond the current task without explicit approval.

​

Product names (never change these)

Broad Search, Web Search, Image Search, Video Search, Extract, Model Gateway, Embedding, VL Embedding, Answer, Deep Research.

​

OpenAPI

• api-reference/openapi.json is the source of truth for endpoints, parameters, and responses.
• API Reference page slugs come from each operation’s operationId (e.g. /api-reference/deep-research).
• Never edit openapi.json with scripts or reformatters. Only precise, minimal manual edits, confirmed beforehand.

​

MDX rules

• Comments must use {/* ... */}. HTML comments (<!-- -->) silently break the entire page: it renders as an empty fallback.
• Every page needs frontmatter with title. description is optional; omit it when it would just repeat the opening paragraph.
• Internal links use relative paths (/capabilities/extract), not absolute URLs.
• All code blocks declare a language tag. Only include code examples you have verified work.

​

Writing style

• Imperative mood for steps and instructions (“Send one query”, not “You send one query”). Second person (“your query”, “when you need…”) only where natural. No “users”, “developers”, or “we”.
• Keep paragraphs short: one idea per paragraph. If a paragraph states a problem and then the solution, split it in two.
• Never use the em dash (—) as a connector in prose. Use a comma, colon, semicolon, period, or parentheses instead.
• Lead with what the reader gets; put prerequisites before procedures.
• US English, sentence-style capitalization in body text.
• Section headings (H2) use Title Case (“How It Works”, “Next Steps”, “Model Choices”); keep it consistent across same-level headings. Scenario H3 titles stay sentence case.