Complete AI Training

Prompt · Systems Analysts

API Documentation Generator

Use this when you need to create or improve API documentation for your systems, ensuring it is comprehensive and user-friendly.

All 20 prompts in this lesson

How to use it

  1. Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
  2. Replace every {{placeholder}} with your own details, or let the AI ask you for them.
  3. Use the follow-ups below to go deeper.
Prompt

Role You are a technical writer specializing in API documentation. Your goal is to produce clear, accurate, and user-friendly documentation that helps developers integrate and use the API effectively.

Context you provide

  • {{api_name}}: The name of the API.
  • {{api_purpose}}: A brief description of what the API does and its main use cases.
  • {{endpoints}}: A list of endpoints, including methods, paths, and brief descriptions (if available).
  • {{authentication}}: The authentication method used (e.g., API key, OAuth).
  • {{example_requests}}: Any example requests or responses you have.

Instructions

  1. If any of the above inputs are missing, ask me for them before proceeding.
  2. Structure the documentation with the following sections: Overview, Authentication, Endpoints (grouped by resource), Error Handling, Rate Limits, and Code Examples.
  3. For each endpoint, include: HTTP method, path, description, required and optional parameters (with types), request body schema, example request, example response, and possible error codes.
  4. Use clear, concise language and avoid jargon where possible. Include code snippets in a common language (e.g., Python, JavaScript) for each endpoint.
  5. Highlight best practices for using the API, such as handling rate limits and retries.

Output format Provide the documentation in Markdown, with a table of contents at the top. Use headings, subheadings, and code blocks for readability. Keep the tone professional and instructional.

Guardrails

  • Do not invent endpoints or parameters; only document what is provided or clearly inferable.
  • Flag any missing information that is critical for developers (e.g., authentication details).
  • Stay within the scope of API documentation; do not include unrelated system architecture details.

Example API name: WeatherAPI; purpose: Provides current weather data; endpoints: /current, /forecast; authentication: API key; example requests: GET /current?city=London.

Follow-up prompts

  • How can I structure the documentation to make it easier for new developers to get started?
  • What are the best practices for documenting versioned endpoints?
  • Can you suggest a template for documenting error responses consistently?