Developer Documentation / Project Tools

API Documentation Generator

Turn a list of endpoints into Markdown API reference docs with parameter tables, request bodies and curl examples.

List your endpoints as METHOD /path - description and get a structured Markdown API reference with curl examples.

API name

Base URL

Authentication

Short description (optional)

Endpoints - METHOD /path - description, optionally followed by body: {json} on the next line

The generator documents only what you enter: path and query parameters are detected from the path, request examples come from your body: lines, and response sections are left as clearly marked placeholders for you to fill in. Use placeholder credentials only.

What Is the API Documentation Generator?

It turns a plain list of endpoints into a Markdown API reference: an overview table, an authentication section, and a section per endpoint with path and query parameter tables, your request body example and a ready-to-copy curl command. The result works in a README, a GitHub wiki or any static documentation site.

What It Does Not Do

It documents only what you enter. The tool does not call your API or guess how it behaves, so response bodies, status codes and parameter types are left as clearly marked _TODO_ placeholders for you to fill in. That keeps the documentation honest.

How to Use It

Enter the API name, base URL and authentication type.
List the endpoints, one per line: METHOD /path - description. Add a line body: {json} after an endpoint to include a request body example.
Click Generate API docs, fill in the TODOs and save it as API.md or part of your README.

Example

The line GET /orders/{id} - Get one order becomes a section with a path parameter table listing id and the example curl -X GET 'https://api.example.com/v1/orders/{id}' -H 'Authorization: Bearer YOUR_TOKEN'.

Understanding the Output

Path parameters are detected in {id}, :id and <id> form; query parameters from anything after ?. Invalid JSON bodies are left out with a warning rather than guessed. Credentials in examples are placeholders such as YOUR_TOKEN - never paste real ones.

Limitations

For machine-readable specs that tools can validate and generate clients from, use OpenAPI and check the file with the OpenAPI Validator. Name routes consistently first with the API Endpoint Naming Generator, and test them with the API Request Builder.

Frequently Asked Questions

No. It only formats the endpoints you type into Markdown. The curl examples are text for readers to copy - they are never sent from this page.

The tool cannot know what your API returns, and guessing would produce misleading documentation. The placeholders mark exactly where you need to add real status codes and response examples.

Put a line starting with body: directly below the endpoint, followed by JSON, for example body: {"name": "Ada"}. Invalid JSON is left out with a warning so you can fix it.

Markdown is quick to write and easy to read in a repository. An OpenAPI file is machine-readable, so it can drive interactive docs, client generation and validation. Many teams start with Markdown and move to OpenAPI as the API grows.