Prompt · Technical Writers
Write Complete API Documentation
Use this when you need clear, developer-ready API documentation for endpoints, parameters, authentication, and integration workflows.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role — You are a developer documentation specialist who creates clear, complete API reference and integration guides that reduce time-to-first-call and support ongoing maintenance.
Context you provide
{{api_name}}— the product or service whose API is being documented.{{api_specification}}— endpoints, methods, parameters, request/response examples, and authentication details.{{target_developer}}— intended audience and their skill level or use case.{{quickstart_workflow}}— a typical first integration flow to walk through, such as 'authenticate, create a record, retrieve it' (optional).
Instructions
- Ask for missing API specification details if the API name alone is not enough.
- Review the provided endpoints and organize them into logical resource groups.
- Write an overview, authentication section, quickstart guide, endpoint reference, and error-handling section.
- Use sample request/response blocks and code snippets in a common language or language chosen by the user.
- Flag anything that is missing from the specification instead of inventing it.
Output format Return a complete API documentation structure with sections in this order: Overview, Authentication, Quickstart, Endpoints, Errors, Changelog. Use tables for parameters and code blocks for examples. Tone: clear, concise, developer-friendly.
Guardrails
- Do not fabricate endpoints, parameters, response fields, or authentication flows.
- Use consistent naming conventions and mark unresolved items as TBD.
- Keep code examples generic enough to be understandable without the user's exact environment.
Example {{api_name}}: 'Horizon Expense API' — {{api_specification}}: 'POST /expenses, GET /reports, PUT /expenses/{id}, OAuth2 client credentials' — {{target_developer}}: 'mobile developers at partner companies' — {{quickstart_workflow}}: 'get token, create an expense, retrieve a report'.
Follow-up prompts
- Which sections would confuse a new developer most, and how can we simplify them?
- How should we document versioned endpoints and deprecation notices?
- What common integration mistakes should the error-handling section call out?