I Ran 40 ChatGPT Prompts to Write API Documentation — Here’s What Actually Passed Our Dev Review

I spent a weekend testing ChatGPT prompts for API documentation because our team needed to document a payments API before a partner integration deadline, and our technical writer was out for two weeks. What started as a quick experiment turned into a full weekend of testing, rewriting, and arguing with two senior backend engineers about what counts as “good enough” for a developer to read once and never open a support ticket.

I ran 40 different prompts against the same API. I fed the results to our internal dev review process, the same one we use for any documentation before it ships. Only 6 prompts produced output that passed without heavy editing. This article breaks down exactly which ones worked, which ones failed, and the pattern behind why.

If you are a software engineer, a technical writer, or a solo founder trying to ship API docs without hiring a full documentation team, this is the real data, not a theory.

Why I Tested 40 ChatGPT Prompts for API Documentation

Most articles about AI prompts for developers show you one polished example and call it a day. That is not how real engineering work goes. A single prompt rarely produces documentation that survives contact with an actual reviewer, because API documentation is not one task. It is at least five separate tasks wearing the same trench coat: endpoint description, request and response schema explanation, authentication flow, error handling reference, and working code samples.

I was interested in knowing which of the prompt types performed sufficiently well for bypassing full rewriting, as well as the ones that looked okay initially, but fell apart as soon as a developer attempted to call the endpoint.

How I Set Up the Test

To keep this fair and repeatable, I used the same source material for every prompt.

The API We Documented

For this example, I have used a mid level internal REST API having 14 endpoints which take care of user accounts, subscriptions, and webhook activities. It uses standard bearer token authentication and returns JSON. It also has several endpoints with pagination and rate limiting capabilities, which is the exact complexity that creates problems for generic AI output.

sample REST API endpoint used to test ChatGPT prompts for API documentation

I provided the identical input to ChatGPT in every experiment: the URL, the HTTP verb, the request parameters, an example response payload, and any error codes associated with that endpoint. All the prompts received similar background information.

The Dev Review Criteria

Our internal review checklist has five requirements, and documentation has to pass all five to ship without edits.

dev review checklist for grading AI generated API documentation
  • The endpoint description explains what the endpoint does and why a developer would call it, not just what parameters it accepts
  • Every parameter includes its type, whether it is required, and a realistic example value
  • The response section shows a full example payload that matches our actual schema
  • Error handling lists the specific status codes this endpoint can return, not a generic list copied from every other endpoint
  • The code sample actually runs when copied and pasted, with no placeholder syntax errors

Two backend engineers and I reviewed every output blind, meaning we did not know which prompt generated which result until after scoring.

The Prompt Categories I Tested

I grouped the 40 prompts into five categories based on the actual documentation tasks engineers care about, then tested eight variations per category.

Category One: Plain Endpoint Descriptions

These prompts asked ChatGPT to explain what an endpoint does in plain language for a developer audience. Most versions of this prompt produced text that was accurate but generic, the kind of description you could paste into any API’s docs and it would still technically be true. Only the prompts that explicitly asked for a real world use case scenario produced descriptions specific enough to be useful.

Category Two: Request and Response Schema Explanations

This is where volume of failure was highest. Fifteen of the 40 prompts fell into this category, and only one passed cleanly. The core problem was hallucinated fields. When I asked ChatGPT to explain a JSON schema without pasting the actual schema first, it invented plausible sounding fields that did not exist in our real API. The moment I changed the prompt to require pasting the exact schema and instructing the model not to add fields that were not present, accuracy jumped dramatically.

ChatGPT hallucinating a field that does not exist in the real API schema

Category Three: Authentication and Error Handling

Authentication documentation is deceptively hard because it requires sequencing. A developer needs to know the order of operations, get a token, attach it correctly, handle expiration, before anything else makes sense. Prompts that asked for authentication docs “in general” produced boilerplate about OAuth concepts nobody asked about. Prompts that asked for the exact header format, the exact expiration behavior, and the exact refresh flow for our specific implementation performed far better.

Category Four: Code Sample Generation

Code samples are where I expected the biggest wins, and they mostly delivered, with one catch. ChatGPT is good at generating syntactically correct code in Python, JavaScript, and cURL. It is not naturally good at matching your actual base URL, your actual authentication header name, or your actual variable naming conventions unless you specify them directly in the prompt. Left to its own devices, it defaults to generic placeholder patterns like YOUR_API_KEY_HERE that a developer then has to manually fix throughout every sample.

Category Five: Full Section Generation From a Style Guide

The final category tested whether ChatGPT could take our existing documentation style and apply it consistently to a new endpoint, matching tone, heading structure, and formatting. This produced the most dramatic split. Prompts without a pasted style reference produced documentation that looked nothing like the rest of our site. Prompts that included two full paragraphs of existing documentation as a style anchor came back nearly indistinguishable from our own writing.

The 6 Prompts That Actually Passed Dev Review

Here is the exact breakdown of what worked, in the order our reviewers scored them.

1. The Schema Lock Prompt

Prompt — Schema Lock
You are a senior technical writer documenting a REST API for other developers. Below is the exact JSON response schema for one endpoint. Do not add, rename, or assume any field that is not explicitly present in this schema. Do not mark a field as optional unless the schema itself indicates it is optional. Write a response documentation section with these exact subsections in this order: Description, Fields Table, Full Example Response. The Fields Table must list every field name, its data type, whether it is required, and a short description based only on what a developer could reasonably infer from the field name and type. Do not invent example values that contradict the schema. Use plain, direct language a developer would read in under thirty seconds. Endpoint: Schema:
Tip: Paste your endpoint’s method, route, and the exact JSON schema into the blank fields above before running this. The more exact the schema you paste in, the fewer hallucinated fields you will get back.

This prompt pasted the actual JSON response schema and explicitly instructed the model to describe only fields present in that schema, flagging nothing as optional unless the schema marked it that way. This was the single highest scoring prompt of all 40. It eliminated the hallucination problem almost entirely because there was nothing left to guess.

ChatGPT prompt and output for API schema documentation, schema lock method

2. The Real World Use Case Prompt

Prompt — Real World Use Case
You are writing the introductory description for one API endpoint. Instead of describing the endpoint mechanically, imagine a specific developer persona building a specific feature who needs to call this endpoint as one step in that feature. Write a two to three sentence description that opens with why a developer would call this endpoint as part of that real feature, then states what it technically does. Avoid generic phrasing like this endpoint allows you to. Write it the way a developer would explain it to a teammate over Slack, direct and specific, with no filler. Endpoint: What it technically does: Feature a developer is likely building when they need this:
Tip: Naming a real feature, like a subscription upgrade flow or a webhook retry system, is what stops the output from sounding like a dictionary definition. The more specific the feature, the sharper the description.

Instead of asking “describe this endpoint,” this prompt asked ChatGPT to imagine a specific developer persona building a specific feature, then explain why they would call this endpoint as part of that feature. The output stopped sounding like a dictionary definition and started sounding like something a developer would actually read before their coffee got cold.

3. The Sequenced Authentication Prompt

Prompt — Sequenced Authentication
You are documenting the authentication flow for an API so a developer can make their first successful call without any back and forth. Use the exact details below, do not substitute generic OAuth explanations. Write this as a numbered sequence of steps, starting from how to get your first token through to what happens when your token expires and what to do about it. Each step should be one to two sentences, direct, and free of generic security theory that does not apply to this specific implementation. Token type: Header name and format: How a developer obtains the token: Token expiration time: Refresh process:
Tip: If your API has no refresh flow, say so directly in the blank rather than leaving it empty. The model will otherwise invent a refresh endpoint that does not exist.

This prompt broke authentication into numbered steps and asked the model to fill in each step using our exact token format, header name, and expiration window, rather than asking for “authentication documentation” as one open ended block. Sequencing the request forced sequencing in the output, which is exactly what a developer needs when they are trying to make their first successful call.

4. The Copy Paste Ready Code Prompt

Prompt — Copy Paste Ready Code
You are writing a code sample for API documentation that a developer can copy, paste, and run with only one change, swapping in their real credential. Use the exact values below, never a placeholder pattern like YOUR_API_KEY_HERE unless I provide one. Write three code samples: one in cURL, one in JavaScript using fetch, one in Python using the requests library. Include a one line comment above the credential in each sample explaining that it should be replaced with a real key. Do not include any explanation text outside the code blocks. Base URL: Endpoint: Header name for authentication: Sample fake but realistic test key: Required request body fields, if any:
Tip: Always paste your real base URL and header name here. Left blank, the model defaults to generic placeholders a developer then has to manually fix in every single sample.

This prompt specified our exact base URL, our exact header key, and asked for a working example using a live sounding but clearly fake test key, with a comment explaining where to swap in a real credential. Because every variable was defined up front, the generated code required almost no cleanup.

5. The Error Code Table Prompt

Prompt — Error Code Table
You are documenting the error responses for one API endpoint. Use only the status codes listed below, do not add a generic list of every HTTP status code that exists. Format the output as a markdown table with three columns: Status Code, What Triggers It, What The Developer Should Do About It. Keep each cell to one short sentence. Do not add commentary before or after the table. Endpoint: Status codes this endpoint can actually return: What triggers each one in this specific implementation:
Tip: List only the status codes your endpoint actually returns. A generic 400 to 500 dump is the fastest way to make an error section useless to a developer under deadline.

Instead of asking for “error handling” generally, this prompt supplied the specific list of status codes that endpoint could realistically return and asked for a table format explaining what triggers each one and what the developer should do about it. Tables consistently outperformed prose for this section, both for accuracy and for how quickly our reviewers could scan it.

6. The Style Match Prompt

Prompt — Error Code Table
You are documenting the error responses for one API endpoint. Use only the status codes listed below, do not add a generic list of every HTTP status code that exists. Format the output as a markdown table with three columns: Status Code, What Triggers It, What The Developer Should Do About It. Keep each cell to one short sentence. Do not add commentary before or after the table. Endpoint: Status codes this endpoint can actually return: What triggers each one in this specific implementation:
Tip: List only the status codes your endpoint actually returns. A generic 400 to 500 dump is the fastest way to make an error section useless to a developer under deadline.

Prompt provided two sections of the content of our currently published documentation and requested ChatGPT to write another section matching the tone, length, and heading pattern. It was the sole prompt that produced content that needed no further iterations to achieve consistency.

What Failed, and the Pattern Behind It

Looking across all 40 results, the failures clustered around three habits.

Vague scope requests failed almost every time

Any prompt that asked ChatGPT to “write documentation for this API” without specifying which section, which endpoint, or which format produced generic, unusable output. The wider the ask, the weaker the result.

Missing source material caused hallucination

Every prompt that asked the model to explain something without first pasting the real schema, real error codes, or real response payload produced at least one invented detail. This is not a ChatGPT flaw specifically, it is a predictable outcome of asking a language model to describe data it has never seen.

Generic tone requests produced generic tone

Asking for documentation to be “clear and professional” did nothing. Asking for documentation to match a specific pasted example did everything. The model needs an anchor, not an adjective.

The Prompt Formula That Worked Best Across Categories

After scoring all 40, a clear formula emerged for the prompts that consistently passed review.

  1. State the exact audience, meaning a developer integrating this specific endpoint, not a general reader
  2. Paste the real data, the actual schema, actual error codes, actual authentication details, never a description of them
  3. Specify the exact output format, table, numbered steps, or code block, rather than leaving structure open ended
  4. Include a real world scenario for why this endpoint matters, not just what it does
  5. Anchor tone with a pasted style example whenever consistency with existing docs matters

Thanks to this method, the original fifteen percent pass rate has changed into as much as what could be called a potentially higher pass rate had the steps been applied accordingly.

How to Use This on Your Own API

If you want to replicate this process on your own project, here is the sequence that worked for us.

Step One: Gather Your Raw Material First

Before writing a single prompt, pull the actual schema, actual status codes, and a real sample request and response for the endpoint you are documenting. Do this before opening ChatGPT at all.

Step Two: Write One Prompt Per Section

Do not ask for the whole documentation page in one shot. Ask for the description, then the parameters, then the response, then the errors, then the code sample, each as its own prompt using the real data you gathered.

Step Three: Paste a Style Anchor Every Time

Keep two or three paragraphs of your best existing documentation saved somewhere you can quickly copy from. Paste it into every prompt where tone consistency matters.

Step Four: Run It Through a Real Review

Even the six prompts that passed our review still got a final human read before publishing. Treat ChatGPT as a strong first draft generator, not a replacement for the review step itself.

Final Thoughts

Forty prompts taught me that API documentation is not a single writing task you can hand to ChatGPT with one clever instruction. It is five smaller tasks, each with its own failure pattern, and the prompts that survived dev review were the ones that respected that structure. If you paste real data, split the work by section, and anchor the tone with your own existing writing, ChatGPT stops being a novelty and starts being a genuinely useful first pass on documentation you would otherwise be writing alone at midnight before a deadline.

FAQ’s

Can ChatGPT write full API documentation on its own?

Not reliably in one shot. Broken into focused prompts with real schema data pasted in, it produced sections that needed only light editing, but a full unsupervised documentation page still needs a human pass for accuracy and voice.

Why did ChatGPT invent fields that did not exist in our API?

This happens when the model is asked to describe a schema it never actually saw. Without the real data pasted directly into the prompt, it fills gaps with statistically plausible but incorrect guesses.

What is the biggest mistake developers make when prompting for documentation?

Asking for too much at once. A single prompt asking for an entire documentation page produces shallow, generic output. Splitting the task into description, parameters, response, errors, and code samples produces far more usable results.

Does this process work for OpenAPI or Swagger specs specifically?

Yes, with one adjustment. Paste the actual YAML or JSON block from your OpenAPI definition directly into the prompt rather than summarizing it in your own words, and ask ChatGPT to generate the human readable explanation from that exact source.

How long did it take to test all 40 prompts?

The full test, including scoring by two engineers, took about two days spread across a weekend. Most of that time went into gathering consistent source material for every prompt, not into running the prompts themselves.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top