Read me first

A plain-language introduction to the API Documentation Generator. If you are meeting this project for the first time, start here — then follow the pointers at the end to whichever document matches what you want to do next.

No technical background is assumed.

---

1. Who this is for

Two groups of people, and the product is built for both equally.

People who publish an API. Platform engineers, technical writers, and developer advocates — often looking after several APIs at once. They want documentation that looks professional and, more importantly, stays truthful without somebody hand-editing it every release.

People who use an API. Developers and integrators who have arrived, usually mid-task, needing to understand a service well enough to make one call work. Increasingly this also means AI assistants reading documentation on a developer's behalf.

If you are evaluating the product rather than using it, you are most likely in the first group.

---

2. What it does

It turns a machine-readable description of an API into documentation people can read, search, and try — automatically.

You give it a specification file. It reads that file, extracts every endpoint, every data shape, and every security requirement, and publishes a reference site from them. Where the specification is thin, it can add explanatory text using AI — always labelled as such, and always subject to a human's approval before it counts.

It also keeps a record of each published version, so documentation for an older release does not vanish the moment a new one ships.

---

3. The domain

A quick orientation for anyone who does not work with APIs daily.

An API is the doorway one piece of software offers to another. When a shop's website charges your card, it is not doing the charging itself — it is asking a payments company's API to do it. For that request to work, the shop's developers need to know exactly what to ask for and what they will get back.

That knowledge lives in documentation, and documentation has a chronic problem: the software changes and the documentation does not. A developer reads that a field is called customer_id, writes code accordingly, and discovers it was renamed two releases ago. They lose an afternoon, then open a support ticket. Multiply that across every integrator and stale documentation becomes a real, recurring cost.

Most tools in this space render a specification into a nice-looking site and stop there. They make documentation pretty. The harder problem — and the one this project is aimed at — is keeping it honest.

---

4. Where it fits

This is a system that sits alongside your existing engineering setup rather than replacing anything.

The people around it. The publishing side is used by whoever owns an API's documentation. The reading side is public-facing, aimed at the developers integrating with you — customers, partners, or other teams inside your own company.

What it connects to. It reads standard OpenAPI specification files, which almost every modern API already produces. It can inspect source code to draft a specification where none exists. It can compare documented behaviour against a live API to detect divergence. It can publish a self-contained static site that you host wherever you already host things.

How people sign in. Access is handled by the platform's shared sign-on rather than a password system of its own, so this product never stores anyone's password.

Deliberately not included: it is not an API gateway, it does not proxy or manage live traffic, and it does not test your API's correctness. It documents.

---

5. First run

The fastest way to see it is the preview edition — a single self-contained package that carries the application and its database together, already filled with example data for a fictional payments company. Nothing to configure.

Once it is running, open it in a browser and sign in. You will land on the dashboard, showing four example projects. Open one, then open its published documentation, and you are looking at the same three-panel reference your own developers would see: the list of calls on the left, the detail in the middle, ready-to-copy code on the right.

Spend the first ten minutes reading rather than configuring. The example data exists so the product is judged on how it feels when it is full, not empty.

Setup commands are in installation-guide.md; the preview edition is described in the project's preview folder.

---

6. Setting up

When you move from looking to using, the sequence is:

1. Create a project. A project groups the APIs that belong together — usually one product or one team's services.
2. Add an API to that project, and import its specification. You can paste the document in directly, point at a URL, or upload a file.
3. Review what was imported. Every endpoint is read straight from your specification, so this is a check rather than a correction.
4. Consider AI enrichment, if your specification is light on descriptions. The system drafts explanatory text, marks it clearly as AI-written, and shows how confident it is. Nothing is published until a person accepts it.
5. Publish a version when it reads well. Earlier versions remain available.

Connecting it to your wider environment — continuous integration, source control, scheduled checks — is covered in integration-guide.md.

---

7. Day to day

Once it is running, routine use is light:

• When an API changes, import the updated specification. The system creates a new version rather than overwriting the old one.
• Review any AI suggestions waiting for a decision. Accept or reject each one. This is the only step that genuinely needs a person, and it is the step that keeps the documentation trustworthy.
• Check for divergence between what you have published and how the live API actually behaves. This comparison runs through the system's interface for other software rather than an on-screen report — worth knowing, because it is a capability you reach through automation rather than a page you visit.
• Answer questions from your own developers, which mostly means sending links to specific endpoints.

For an API in steady development, expect this to be minutes a week, concentrated around releases.

---

8. Ongoing care

Longer-horizon habits, none of them frequent:

• Retire old versions. Documentation for a release nobody uses is clutter. Deprecate deliberately rather than deleting.
• Back up the database. Everything — projects, specifications, versions, approvals — lives there. Your platform operator normally handles this; confirm it is happening rather than assuming.
• Re-review AI text after big changes. A description accepted against last year's behaviour may quietly have stopped being true.
• Keep an eye on divergence reports. A rising count usually means the specification has stopped being maintained alongside the code, which is a process problem the tool can reveal but not fix.
• Apply updates to the application itself as they are released.

Operator-facing routines — preparing a fresh production environment, first-admin setup — are in production-initialization.md.

---

Glossary

Term	What it means here
API	The interface one program offers to another.
OpenAPI specification	A standard file format describing an API in full: its calls, inputs, and outputs. The main input to this product.
Endpoint	One individual call an API offers, such as "create a payment".
Schema	The shape of a piece of data — which fields exist and what type each one is.
Version	A published snapshot of an API's documentation, kept when a newer one arrives.
Drift	Divergence between what the documentation says and how the live API actually behaves.
Enrichment	AI-written explanatory text added where a specification is sparse. Always labelled, always reviewed.
Project	A container grouping related APIs.
Static export	A self-contained copy of the documentation you can host anywhere.

---

The other documents

Document	Read it when
getting-started.md	You want the guided first walkthrough.
user-guide.md	You want everyday instructions in plain language.
user-guide-detailed.md	You want the thorough version.
installation-guide.md	You are installing or running it yourself.
integration-guide.md	You are connecting it to other systems.
api-reference.md	You are driving it from your own software.
production-initialization.md	You are preparing a real environment for first use.
useful-commands.md	You want the command reference.
testing.md	You want to know what has been tested and why.
technical-documentation.md	You want the architecture.

---

Who can do what

Everyone belongs to an organisation, and everything they see belongs to it.

The person who first signs in becomes the owner of that organisation. Additional members can be given narrower roles, so that reading documentation and changing it are separate permissions.

Published documentation can be read without an account. The dashboard cannot.

---

About the example data

The preview edition ships already populated with a fictional payments company called Meridian — four projects, several APIs, dozens of endpoints, plus example AI suggestions and divergence records. It exists so you can judge a full system instead of an empty one.

None of it is real, and none of it is yours. To start clean, run the preview without keeping its stored data and it resets to the same starting point each time. For a real deployment you begin with an empty system and import your own specifications — the example data is never installed there.

---

Common questions

Do I have to write my documentation in this tool? No. It reads the specification your API already produces. If you do not have one, it can draft it from source code for you to check.

Does the AI write my documentation? Only where a specification is thin, and only as a suggestion. AI text is labelled, carries a confidence indicator, and does not appear in published documentation until someone accepts it. Facts read from your specification are never changed by AI.

What happens to old documentation when the API changes? It is kept as a version. Publishing something new does not erase what came before.

Can I host the documentation myself? Yes. It can produce a self-contained static site with no dependency on this application still running.

Is anything I type into the "try it" console stored? No. Credentials entered there are used for that single request and never saved.

It looks quite plain — is that a limitation? It is a starting point. The product is intentionally unbranded so it can be styled to an organisation's identity, which is a small change to make.

---

Where to get help

This project is part of the worlds-biggest-software-project initiative, an open community building AI-native applications.

Visit wbsp.ai to ask questions, suggest what this should do next, or find people who can adapt it to your organisation. It is also worth browsing what else is there: community members have built many variants of this application and many others besides, and one may be closer to your needs than starting from scratch.