API Documentation Writer
Feed this prompt your API endpoints and get documentation developers actually enjoy: clear descriptions, request/response examples, auth details, and error codes — structured like Stripe's docs, generated in minutes.
Turns your endpoints into Stripe-quality docs — examples, error tables, and auth flows included.
You are a developer-experience writer in the style of Stripe's docs team. I will describe my API endpoints. For each endpoint produce: method + path, a one-line purpose, auth requirements, request parameters table (name, type, required, description), a realistic request example, a realistic success response, and an error table (code, meaning, how to fix). Then add a 5-line quickstart showing auth + first call in [LANGUAGE]. Flag any endpoint design smells you notice. Here are my endpoints:
See what this prompt creates
What this prompt does
Great API docs are a growth channel; bad ones are a support ticket generator. This prompt converts your endpoints — routes, parameters, payloads — into complete, consistent documentation: plain-language descriptions, copy-pasteable request/response examples, authentication flows, and an error-code reference. The output follows the conventions of the world's best-loved API docs.
How to get the best result
Feed it structure: OpenAPI specs, route definitions, or even well-named controller code. The more structured the input, the more accurate the docs. Specify your audience (“external developers integrating payments” vs “internal team”) — it changes tone, depth, and which gotchas get called out. Review every example payload for correctness; plausible-but-wrong examples are worse than none.
Common mistakes to avoid
Don't document aspirational APIs — docs generated from planned-but-unbuilt endpoints rot instantly and destroy trust. Generate from the actual implementation. And keep auth front and center: “how do I authenticate” is the #1 question on every API doc page, so it belongs at the top, not page 12.
The second pass: auditing docs you already have
Most teams meet this prompt with an API that's already documented — badly. Use it as an auditor before you use it as a writer. Paste your existing endpoint docs and ask: "List everything a new developer would still have to guess: missing error codes, unnamed rate limits, fields described as 'the data', examples that wouldn't actually run." The model is genuinely good at this gap-hunt because it reads your docs the way a stranger does, without the mercy of knowing what you meant. Teams routinely find their authentication section assumes a step nobody ever wrote down.
Then establish a style anchor. Take the one endpoint page your team is proudest of and paste it with the instruction "this page is the standard; rewrite the others to match its structure and voice". Without an anchor, AI-generated docs drift page by page — one endpoint gets a friendly paragraph, the next gets a terse table — and drift is what makes a docs site feel unmaintained even when every page is technically accurate.
Finally, close the loop with your changelog. Each release, paste the diff summary or the pull-request descriptions and ask for the docs changes in the same format: new parameters added to the tables, deprecated fields marked, the quickstart updated if auth moved. Docs rot because updating them is a separate, postponable chore. Feeding the release notes through this prompt makes it a ten-minute habit attached to something that already ships — which is the only kind of documentation process that survives contact with a busy team.
Try these variations
Generate a “quickstart in 5 minutes” guide from the same input — the single highest-converting docs page. For SDKs, ask for code samples in your users' top 3 languages. Shipping the API itself? The conventional commit prompt keeps the changelog clean. More in the coding prompts collection.
How to use this prompt
- Copy it — hit the copy button above to grab the raw prompt text.
- Fill the brackets — replace anything in [BRACKETS] with your own details.
- Paste into your AI tool — works with ChatGPT, Claude, Gemini for text prompts; Midjourney, DALL-E or Stable Diffusion for image prompts; Runway, Pika or Sora for video.
- Iterate — tweak one bracket at a time until the output is exactly right.
Frequently asked questions
Can it work from my OpenAPI/Swagger spec?
That's the ideal input — paste the spec (or the relevant paths) and it generates human-friendly docs with descriptions, examples, and guides around the machine-readable skeleton. It turns reference material into learning material.
How do I keep docs in sync with code changes?
Regenerate per release: feed the updated spec or diff through the prompt and it updates affected sections. Best practice is docs-as-code — store the generated markdown in your repo and regenerate on every API version bump.
What makes API docs “good” anyway?
Three things: a 5-minute quickstart that works first try, copy-pasteable examples for every endpoint, and honest error documentation. This prompt structures output around exactly those, because that's what developers actually read.
Should docs include code samples? In which languages?
Yes — cURL plus your users' top 2–3 languages (usually JavaScript, Python, and maybe Go or Ruby). The prompt generates idiomatic samples per language, not transliterated ones.
