Engineering

API Documentation Prompt

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

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.

Workflow

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

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

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.

Related Resources

Explore more resources that work well with this one.