Describe your product and Netiva’s agent builds the documentation site: guides, endpoint reference, search and release notes rendered from collections, with a live preview and code you own.
Build a documentation website for a developer tools company. Model sections, doc pages, API endpoints and releases as collections. A doc page has a title, summary, body, page type, status and the release it applies to; an endpoint names the release too, plus a method, path, parameters and request and response examples. Render section landing pages, a page per guide, a versioned reference page per endpoint and a changelog grouped by release. Put a version switcher in the header and a search box over titles, summaries, bodies and endpoint paths for that version. Give writers a desk of drafts, pages in review and pages past their review date.
Developer docs go stale in predictable places. The quickstart still shows last year’s endpoint, the changelog sits in a repo file nobody links to, and support answers the same question three times a week because search returns nothing useful. A documentation site built with Netiva keeps sections, pages, endpoints and releases in collections, so a guide carries the version it applies to, a retired endpoint says what replaced it, and the release note goes out the day the version ships.
Model each kind of page the way readers use it — a tutorial to learn, a how-to guide to finish a task, a concept page to understand, reference to look something up — then bind those collections to the site.
Each page and endpoint carries the release it applies to, blank where it is true for every version. Readers pick a version in the header and see what matches; writers keep saved views of what still needs rewriting for the release in flight.
Ask the agent for a search page and it reads the same collections the site renders: titles, summaries, bodies and endpoint paths, narrowed to the version the reader is on.
Each release is a record with its version, date and changes grouped by type, so the changelog page, the version switcher and the announcement email all draw on the same entry.
Netiva keeps your records in built-in collections. Here’s a starting structure — the agent adapts it to your prompt, and you can change it any time.
The shelves your sidebar is built from, in the order readers should meet them.
Every tutorial, how-to guide, concept page and troubleshooting page on the site.
One record per operation, rendered as the reference side of the docs.
Each version of your product, with the changes that shipped in it.
Required field. Types are Netiva collection field types.
A typical first version. Ask the agent for more, or annotate the preview to change any of them.
Section cards, the two or three pages a new reader should start with, and a search box, with the version switcher in the header.
PublicOne guide or concept page with its sidebar, on-page contents, the release it applies to and a link to the current version.
PublicMethod, path, parameters and copyable request and response examples for one operation, at the version in the URL, with a notice when it has been replaced.
PublicMatches across titles, summaries, bodies and endpoint paths for the selected version, grouped by section and page type.
PublicReleases newest first, each with its date and its changes grouped by type, and breaking releases flagged at the top.
PublicDrafts, pages in review, pages past their review date and endpoints still marked beta, for whoever owns docs this sprint.
Your teamTell Netiva which versions you support, how the sidebar is organized and whether you publish an endpoint reference. The agent drafts the sections, doc pages, endpoints and releases collections.
Write pages in the collection grid or paste in what you already have, then ask the collection assistant to fill missing summaries, tidy headings or draft endpoint records from a list you give it.
Open the live preview and annotate the sidebar, the version switcher and a search result. Keep chatting until a first-time reader reaches the quickstart in one step.
Publish in one click, then keep changing pages as the product moves. Every edit is checkpointed, so a restructure that reads worse than the old one can be compared and rolled back.
| Criterion | With Netiva | Traditional build |
|---|---|---|
| Versioned pages | A release field on every page and endpoint, and a switcher that renders the matching version from the collections | A branch or a folder per release in a static site generator, rebuilt by a pipeline |
| Endpoint reference | Endpoint records edited in the grid and rendered as reference pages in the same design as the guides | A separate spec toolchain that emits reference pages, then restyling to make them match the site |
| Getting started | Describe what you need in chat and watch it take shape in a live preview | Hire developers, or stitch together templates, plugins and a hosting plan |
| Content and data | Built-in collections with nine field types, bound straight to your pages | Set up and connect a separate database or CMS |
| Making changes | Ask the agent; every change is checkpointed and reversible | File a ticket, wait for a sprint, redeploy |
| Hosting and domain | Global hosting and automatic SSL; connect a custom domain from the Starter plan | Buy hosting, then install and renew SSL certificates yourself |
| Code ownership | Clean production code you own and can export | Locked into a template, plugin or agency setup |
Two engineers, no writer. The quickstart, five how-to guides and the endpoint reference live in collections, and filling in the release record is part of shipping, so the changelog stops lagging a month behind the product.
Customers on the old major still need their docs while the new one lands. Pages carry the release they apply to, so one switcher serves both, and deprecated operations send readers to the call that replaced them.
Service and API docs written for other engineers in the company, published behind a sign-in, with a review date on each page so the owning team sees what has drifted since the last quarter.
Netiva doesn’t pull Markdown out of Git or run a docs-as-code pipeline, and nothing syncs back to a repository. If your engineers write docs in pull requests today, agree who moves a page into the collection and when.
You can ask for a scheduled job that reads the OpenAPI description you publish and flags endpoint records whose method or path no longer matches. Judging what a changed parameter now means is still a person’s work.
Keeping every release online means several pages say nearly the same thing. Google doesn’t require you to mark a canonical, but a canonical link from older version pages to the current one tells it which version to show — save redirects for a version you have retired entirely.
Publishing at docs.yourcompany.com means adding the records Netiva lists at whoever runs your company domain, which is often another team. Custom domain connection starts with the Starter plan; SSL and hosting are handled for you.
Yes, once you model it. Doc pages and endpoint records both carry the release they apply to — blank where they are true for every version — so a switcher in the header filters the site to one release and holds the reader’s place where a matching page exists. Older releases stay published and readable, and you decide which ones the sidebar still links to and which become archives.
You describe it and the agent builds it. Because guides, endpoint records and release notes all live in collections, the search page reads titles, summaries, bodies and endpoint paths directly and narrows results to the version the reader selected. It matches the words you stored rather than handling typos or synonyms, so name the fields and filters you want it to search. There is no separate index to rebuild and no third-party search widget to embed.
You can keep the two in step. Endpoint records hold the method, path, parameters and examples that readers see. Apps built with Netiva can call any REST API with keys stored securely, so a scheduled job can read the OpenAPI description you publish and flag records whose method or path has changed. Writing the description and reviewing differences stays with your team.
Yes. Readers can sign in, and pages you mark private render only for signed-in accounts, which covers a closed beta or a partner-only integration guide while the rest of the site stays public. Netiva doesn’t give your readers roles or permission levels, so keep the rule simple: a page is public, signed-in only, or unlisted and shared by link.
Give each endpoint a lifecycle value — stable, beta or deprecated — and a relation to whatever replaced it. The reference page then shows a notice with a link to the new operation, and the entry for that release lists it under deprecated, alongside added, changed, removed, fixed and security, the change types most teams already keep in a changelog.
Yes. Netiva writes clean, framework-standard code that you can read, edit and export whenever you want, with no proprietary runtime, and your pages sit in collections you control. Every change the agent makes is checkpointed as well, so you can compare a restructure with what was there before and roll it back if the new order reads worse.
Drafted with AI assistance from Netiva’s product pages and reviewed by the Netiva team. Example data models, screens and prompts are illustrative starting points, not customer projects.
Describe it in a sentence and watch Netiva’s agent build it. Free to start — no credit card required.