Should your help docs and API docs live in the same place?

When my co-founder Nishanth said Pageloop's knowledge base should be Git-based, I was intimidated.

I spent my career in Support, maintaining help docs on tools like Zendesk, Intercom and Freshdesk. My idea of a help center lived inside one of those tools. Technical docs, like API docs and SDK docs, have lived on Git for years. They were just out of reach for people like me, because using Git meant getting far more technical than my role expected.

If your product and help docs sit in a help center while your API and SDK docs sit in a developer docs tool, you know the result. Two tools, two sets of logins, two places to update after every release, and AI agents that can't easily work across both.

Let me quickly sum this up - A help center is built for support teams writing for end users, and a developer docs tool is built for engineers writing for other developers in Git. Keep them separate when different teams own them for different audiences and rarely overlap. Bring them together when they describe the same product, when many teams need to contribute, and when you want AI agents to read and update all of it.

The four kinds of documentation tools

When I mapped the docs market for our own positioning, almost every platform fell into one of four groups, defined by who writes, how they write and what the docs are for:

• For developers: Mintlify, Fern, GitBook and Docusaurus. Docs live in Git, engineers write them, and the product is usually an API or an SDK.

• For external support: Help centers like Zendesk, Intercom or Pylon, and standalone knowledge bases like Archbee, KnowledgeOwl or Document360. They use visual, HTML-based editors, and support teams or technical writers write in them.

• For technical writers: MadCap Flare, Paligo and Heretto. Structured authoring and DITA, often in large regulated companies, where almost nobody outside the docs team touches the docs.

• For everyone: Notion, Confluence, Slite, Coda and Google Docs, plus Guru, Tettra and Slab. They work for internal and external use but are positioned mostly as internal company knowledge.

The market splits into docs-as-code platforms for devs or legacy HTML-based editors for those who don't live in Git every day. That split is why most companies end up with help docs in one place and API docs in another.

Why help docs and API docs ended up apart

Docs-as-code has been around for decades. It means treating documentation the way engineers treat software: docs live in a Git repository, and every change follows the same workflow as code, from branch to edit, review, merge and publish.

Help centers went the visual-editor route because Git wasn't accessible to anyone who wasn't a developer. That was the right call for support teams for a long time. It also meant the people writing help articles and the people writing API references worked in completely different worlds, even when they were describing the same feature.

What changed with Git and AI agents

Then the world changed.

We now know that LLMs are best at coding. That's why coding agents scaled faster than any other kind. Put your docs where code lives, and those agents work just as well on docs. Claude or Codex can read and change any of my docs the same way they change code. I'm not restricted by what a help center exposes through its MCP or API.

And I didn't have to learn Git to use it. Just like I didn't have to learn to code to build automations with Claude or Codex.

A few more things changed with it:

• More people can contribute. In a Git-based setup, a PM or an engineer can propose a doc change from their own Claude session in the same pull request as the feature. Nobody needs to be added as a user on the helpdesk first.

• Seats stop being a limit. Zendesk prices its Suite per agent and Intercom charges per teammate, so every extra contributor costs a seat. Mintlify's plans include editor seats, and Pageloop doesn't charge per seat either.

• Agents don't need a pretty interface. Agents literally don't care how pretty your help center looks. Docs are read by agents more and more, so the time spent on custom CSS to make a help center look nice buys less than it used to.

Version history, review and approval also come with Git, without needing an enterprise plan to get them.

What convinced me was hearing from several knowledge managers who had spent their entire careers in help center tools. They told me moving to a Git-based docs platform changed the quality of their work for the better, because for the first time they could get contributions from across the org without giving up control over what goes live.

When to combine them, and when to keep them separate

Product docs, help docs, API docs, and SDK docs can live together when they describe the same product. If your customers move between "how do I set this up in the app" and "how do I do this with the API", one docs site with one voice serves them better than two.

Keep a separate developer docs tool if your API is the product, an engineering team owns every page, and your help center serves a different set of customers. Keep your help desk for what it's great at, like ticketing, and connect your docs to it. The split costs the most when the same feature gets documented twice, in two tools, by two teams who never see each other's work.

Where Pageloop fits

We are betting that the market will push for ownership (docs in your Git repo), ease of use (a visual editor), agent-readiness (Markdown first), and docs as a team sport (one owner, multiple contributors, one voice).

That's how Pageloop works. Your docs live in your own GitHub or GitLab repository. You edit in a visual editor and review changes on a screen, with screenshots and all, instead of in Git, unless Git is your thing. API reference pages are generated from your OpenAPI spec and sit next to your help articles. Docs are Markdown first, so agents can read and write them natively. And Pageloop connects to your help desk if you keep one (now isn't that easy?)

Image courtesy Unsplash and Birmingham Museums Trust
The River Bed, By David Cox Jnr