An API documentation prompt solves the procrastination that follows finished endpoints: the code is live, yet callers still have to read source code to guess parameters, and integration chats keep asking about types, required fields and error codes. Copy the prompt below, paste in the endpoint code or definition, fill in the audience and output format, and the AI will return purpose, a parameter table, a request example, a response example and error-code notes in the order callers actually look them up. Check the fields and it is ready to share.
When this prompt works best
It fits endpoints that already have code and only lack documentation: a backend endpoint about to be handed to frontend developers or an external partner, an old project catching up on docs, or a new hire mapping the inputs and outputs of a batch of endpoints before taking over. It cannot confirm business rules for you. Validation logic, permission requirements and rate limits that the code does not state can only be flagged as open questions, never invented. If the fields are still changing every day, generate only the parameter table first and add examples once the fields settle, so the doc does not expire the week it is written.
The prompt, ready to copy
You are an API documentation editor. Based on the endpoint code or definition I paste, write documentation that a caller can integrate against directly.
Endpoint code or definition: {{endpoint_code}}
Intended readers: {{audience}}
Authentication: {{auth_method}}
Base URL notes: {{base_url_notes}}
Output requirements:
1. Start with two sentences on what this endpoint does and when to call it. Do not restate the code.
2. Then give a parameter table. For each parameter list its name, location (path, query, header or body), type, whether it is required, and its meaning. Mark any meaning the code does not show as to be confirmed; do not guess.
3. Give one complete request example and one successful response example. Field names and types must match the code exactly, and example values must be clearly fake, desensitised data.
4. Add a separate error-code section. List only the errors the code actually raises, with the trigger condition and what the caller should do. Do not add error codes that are not in the code.
5. Finish with an open-questions list: validation rules, permission requirements and edge cases the code leaves unclear, item by item, for me to confirm before they enter the main text.How to fill in the variables
- Endpoint code: paste the handler, the route definition and the related request and response types, not just a function name. The more complete the context, the fewer to-be-confirmed rows the table has.
- Intended readers: say whether they are internal frontend developers, an external partner, or a newly joined backend developer. The audience changes how detailed the examples should be and whether business terms need explaining.
- Authentication: state token, signature, or gateway-level auth. If there is none, write none explicitly instead of leaving it blank and letting the AI invent an auth section.
- Base URL notes: describe environments only, for example separate test and production environments. Never put real keys or credentials into the prompt.
Check these three things in the draft
First, compare every field against the code. An AI occasionally marks an optional parameter as required or adds a field to an example that the code never returns, so check the table against the types word by word. Second, watch for error codes that were completed too generously: any code or status that cannot be found in the source belongs in the open-questions list, not the error section. Third, desensitise example data properly. Replace phone numbers, emails and order numbers with obviously fictional values instead of leaving real integration data in the document.
When a whole batch of endpoints needs documentation, generate one endpoint at a time so field conventions stay consistent; pasting ten endpoints at once makes parameter tables bleed into each other. The order also works in reverse during integration: when a caller reports a parameter mismatch, first use the Debugging Prompt: Paste the Error and the Code, Get the Root Cause in One Pass to work out whether the doc or the call is wrong, then fix this page.
