Engineering

API Documentation Prompt

Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.

Open in Markdown Output Builder

Overview

API docs are the strictest documentation discipline: callers script against them, so structure drift is breakage. This setup documents API areas in five pinned sections under Strict consistency, with Required Tables (parameters and error codes as real tables, never prose) and Require Code Examples (every usage section carries a fenced, language-tagged, usable-as-written request example). Authentication gets its own section with an example — the part every integrator hunts for first.

How to use this resource

One prompt per API area

Feed each endpoint group below the prompt; every area returns the same skeleton.
Check the tables

Method, path, parameters, error codes — Required Tables keeps them scannable and diffable.
Keep examples runnable

"Usable as written" means an integrator can paste the example and get a response — the doc's real test.

Why This Works

Identical area docs let integrators navigate by habit
Parameter tables resist the prose-collapse that kills scanability
Strict mode treats structure as API surface — which, for docs, it is

Best for

APIs documented by many hands
Reference docs that integrators script against
Teams generating docs from endpoint descriptions

Not for

Machine-readable API specs (OpenAPI) — this writes human docs, not schemas
Defining the API's response format itself — that's the JSON Output Prompt Builder

Use cases

Documenting every API area in the same five sections
Forcing parameter lists into real tables
Giving authentication its own example-bearing section

FAQ

Which sections does the API documentation prompt lock in, and can I reorder or drop them?

The prompt pins exactly five '## ' sections in fixed order: Overview, Authentication, Endpoints, Error Handling, and Rate Limits, under a single '# ' title. Its consistency rules forbid reordering, merging, omitting a heading (even a short one), or rewording the exact heading text. If you need a different skeleton, edit the prompt in the Markdown Output Builder before you run it in ChatGPT, Claude, or Gemini.

How does the prompt stop endpoint parameters and error codes from turning into prose paragraphs?

The table rules force any comparison of items, options, or features into a real markdown table with a header row, separator row, and one row per item, so parameters and error codes stay diffable rather than collapsing into prose. Same columns apply to every row, with '—' filling cells that have no value. You still eyeball the generated tables for accuracy after running the prompt.

Why does the code rule reject '...' placeholders in the request examples it generates?

The code rules demand every behavior or usage section carry a fenced, language-tagged example that is 'usable as written' — no pseudo-code and no '...' placeholders — so an integrator can paste the Authentication or Endpoints example and get a real response. That is the doc's actual test. The prompt structures the request; you confirm the example truly runs against your live API.

Customize This Resource

Opens this setup in Markdown Output Builder. Generate to get the full markdown prompt — then adjust the sections, table rules, and consistency level.

Open in Markdown Output Builder

Prompt Template

Copy it as-is, or use Open in Markdown Output Builder to load it pre-filled and customize it with your own context.

TASK
Document API endpoints in an identical structure across the whole API.
Produce a new markdown document — there is no source text to summarize.

DOCUMENT
The document is technical documentation for developers.
- Define every term at first use — assume a competent reader new to THIS system.
- Document what the system does, not what it might do someday.

DOCUMENT STRUCTURE
Start with one "# " title line, then use exactly these sections, in this order:
## Overview
What this API area covers.
## Authentication
How to authenticate, with an example.
## Endpoints
Each endpoint: method, path, parameters, response.
## Error Handling
Error codes and what the caller should do.
## Rate Limits
Limits, headers, and backoff behavior.

MARKDOWN RULES
- One "# " title at the top; every section below it is a "## " heading.
- Use markdown lists for enumerations — no walls of prose.
- No HTML tags — pure markdown.

TABLE RULES
- Where content compares items, options, or features, you MUST use a markdown table.
- Every table needs a header row, a separator row, and one row per item — never collapse a table into prose.
- Keep the same columns for every row; use "—" for cells with no value.

CODE RULES
- Every section that describes behavior or usage must include a fenced code example with a language tag.
- Code examples must be usable as written — no pseudo-code, no "..." placeholders.

CONSISTENCY RULES
- Use every section defined above.
- Keep the section order exactly as given.
- Do not omit headings, even when a section is short.
- Do not merge sections.
- Use the exact heading text as defined — no rewording.

OUTPUT RULES
- Return only the markdown document — no preamble, no closing commentary.
- Start directly with the "# " title line.
- Do not wrap the document in code fences.

More resources from Markdown Output Builder

Resource

Markdown Output Prompt — Lock the Document Structure

The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.

Prompt Engineering

Resource

README Prompt Template

Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.

Engineering

Resource

Changelog Prompt — User-Readable Change Logs

Added, Changed, Fixed, Removed, Security — changelog entries written as user-visible changes, not commit messages.

Engineering

Resources that pair well

Resource

Executive Summary Prompt

Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.

Operations

Resource

Force JSON Output from AI

Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Projects that use this resource

Project

Build a Documentation Website with AI

The full path to docs people can actually navigate — plan the doc set, structure the site, write the guides and the API reference, then ship it as a coherent documentation site.

5 stages Websites

Guides for this resource

Guide

How to Write API Documentation With AI From Your Code

An endpoint exists but its docs don't, so "document this API" from code alone invents parameters, status codes, and an auth flow that were never real. Here's how to write API documentation with AI from the facts you provide, with unknowns flagged and checked against the real API.

Software Development with AI

Guide

How to Generate a Changelog With AI From Your Merged Changes

The changelog gets written last, from a list of PR titles someone else wrote for a reviewer who has moved on. Here is how to generate a changelog with AI that records what shipped for the people upgrading — and parks what nobody can stand behind yet.

Software Development with AI

Tip: Save time by exploring related resources and tools that integrate with this resource.