API reference documentation from your source code

You are a technical writer who documents APIs for developers. Write reference documentation for the code below.

API type: [e.g. "REST API in Express", "Python library", "GraphQL resolvers", "CLI commands"]
Audience: [e.g. "external developers integrating with us", "internal frontend team"]
Output format: [e.g. "Markdown", "OpenAPI 3.1 YAML", "docstrings in Google style"]
Conventions we already use: [AUTH METHOD, BASE URL, ERROR FORMAT, NAMING STYLE]

Code:
"""
[PASTE HANDLERS, FUNCTIONS, TYPES OR SCHEMAS]
"""

For each endpoint or public function, document:
1. Name and one-sentence purpose.
2. Method and path (or signature).
3. Parameters: name, type, required/optional, default, allowed values, description.
4. A realistic request example and a response example.
5. Errors: status codes or exceptions the code can actually raise, and when.
6. Side effects (writes, emails, external calls) and idempotency.

Rules:
- Document only what the code shows. If behavior is unclear (for example, validation happens elsewhere), write "UNVERIFIED:" and say what to check.
- Do not invent endpoints, fields or limits.
- End with a "Gaps" list: missing validation, undocumented errors, inconsistent naming.

Example (excerpt):
### POST /v1/invoices
Creates a draft invoice for a customer.
| Parameter | Type | Required | Description |
| customer_id | string | yes | ID of an existing customer |
| due_days | integer | no (default 30) | Days until the invoice is due |
Errors: 400 if customer_id is missing; 404 if the customer does not exist.
UNVERIFIED: the maximum value for due_days is not checked in this handler.
Gaps: the 409 raised by createDraft() is not handled consistently.

When to use it

Use this prompt when an API works but its documentation is missing, out of date or scattered across chat threads. It suits a new public endpoint, an internal service another team depends on, or a library you are about to open-source. It is also a quick way to understand your own code: the “Gaps” list often reveals inconsistencies you had not noticed.

How to customize it

• [API TYPE] tells the model which idioms to look for, such as Express middleware, FastAPI decorators or GraphQL schemas.
• [AUDIENCE] changes the level of detail. External developers need authentication steps and complete examples; an internal team may only need parameters and errors.
• [OUTPUT FORMAT] can be plain Markdown for a docs site or OpenAPI YAML you can load into tools that render interactive docs.
• [CONVENTIONS] keep the result consistent with the pages you already have.
• [CODE] should include the types or schemas the handlers use; without them, field types are guesses.

Why it works

Documentation generated from code tends to fail in two ways: it describes what the code should do rather than what it does, and it fills holes with plausible details. The “document only what the code shows” rule and the “UNVERIFIED” label address both, turning potential hallucinations into a checklist for the developer.

The fixed field list for every endpoint produces uniform pages, which matter more to readers than polished prose. Asking for side effects and idempotency covers the questions integrators ask most often after launch, such as whether retrying a request can create a duplicate.

Tips and variations

• Work one module at a time. Large pastes lead to skipped endpoints.
• Ask for a “Quick start” section with the three most common calls once the reference is done.
• If your assistant can run code, ask it to check the examples against a local test server.
• Pair it with our structured outputs guide if the same schemas will be exposed as tools to an LLM.
• Review every example before publishing; a wrong example is worse than none.