Skip to main content
command

doc-api — Claude Code command: generate API docs from code

Scans your codebase for endpoints and writes the API documentation: spec, request and response examples, an interactive page. Useful when there are too many routes to describe by hand.

Install into Claude Code · claude-code-templates All methods and platforms ↓
npx claude-code-templates@latest --command documentation/doc-api
Open on GitHub

What doc-api does

The doc-api command walks the repository looking for routes, controllers and schemas. It then picks a tool to match the stack: OpenAPI/Swagger for REST, GraphiQL or Apollo Studio for GraphQL, Postman, Redoc, API Blueprint. What comes out is a spec with methods, parameters, response codes and data models.

Separate steps cover authentication (API keys, JWT, OAuth), error handling, versioning, rate limits and pagination. Client library generation and Swagger UI setup are described too. For Node.js/Express the command shows the swagger-jsdoc plus swagger-ui-express pairing, for FastAPI it uses docstrings, for Java the @ApiOperation and @ApiParam annotations.

An argument sets the API type: --openapi, --graphql, --rest, --grpc or --interactive. Discovery relies on filenames like *route*, *controller*, *openapi*, *.graphql and on package.json — with an unusual project layout some endpoints will be missed, so read the output before you publish it. Tool access is limited to Read, Write, Edit and Bash.

What it helps with

  • build an OpenAPI spec from existing routes
  • document error codes and response schemas per endpoint
  • spin up a Swagger UI page next to the project
  • write down auth: keys, JWT, OAuth flows
  • generate a test collection from the API description

Example prompts for the agent

  • /doc-api --openapi
  • /doc-api --graphql
  • /doc-api --rest --interactive

How to install doc-api

1claude-code-templates

npx claude-code-templates@latest --command documentation/doc-api

2Manually: put the files in place

.claude/commands/doc-api.md

Call it with /doc-api. For all projects use ~/.claude/commands/

Questions about doc-api

How do I install doc-api in Claude?

Use the templates CLI: npx claude-code-templates@latest --command documentation/doc-api. The file lands at .claude/commands/doc-api.md.

What does doc-api do?

It finds endpoints and schemas in your code, then writes documentation for them: a spec, request and response examples, sections on auth and errors. It can also set up an interactive Swagger UI page.

Which API types are supported?

REST, GraphQL and gRPC, selected with --rest, --graphql and --grpc. There are also --openapi and --interactive.

Source text

doc-api.md · MIT
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: "[api-type] | --openapi | --graphql | --rest | --grpc | --interactive"
description: Generate comprehensive API documentation from code with interactive examples and testing capabilities
---

# API Documentation Generator

Generate API documentation from code: $ARGUMENTS

## Current API Context

- API endpoints: !`find . -name "*route*" -o -name "*controller*" -o -name "*api*" | head -5`
- API specs: !`find . -name "*openapi*" -o -name "*swagger*" -o -name "*.graphql" | head -3`
- Server framework: @package.json or detect from imports
- Existing docs: @docs/api/ or @api-docs/ (if exists)
- Test files: !`find . -name "*test*" -path "*/api/*" | head -3`

## Task

Generate comprehensive API documentation with interactive features: $ARGUMENTS

1. **Code Analysis and Discovery**
   - Scan the codebase for API endpoints, routes, and handlers
   - Identify REST APIs, GraphQL schemas, and RPC services
   - Map out controller classes, route definitions, and middleware
   - Discover request/response models and data structures

2. **Documentation Tool Selection**
   - Choose appropriate documentation tools based on stack:
     - **OpenAPI/Swagger**: REST APIs with interactive documentation
     - **GraphQL**: GraphiQL, GraphQL Playground, or Apollo Studio
     - **Postman**: API collections and documentation
     - **Insomnia**: API design and documentation
     - **Redoc**: Alternative OpenAPI renderer
     - **API Blueprint**: Markdown-based API documentation

3. **API Specification Generation**
   
   **For REST APIs with OpenAPI:**
   ```yaml
   openapi: 3.0.0
   info:
     title: $ARGUMENTS API
     version: 1.0.0
     description: Comprehensive API for $ARGUMENTS
   servers:
     - url: https://api.example.com/v1
   paths:
     /users:
       get:
         summary: List users
         parameters:
           - name: page
             in: query
             schema:
               type: integer
         responses:
           '200':
             description: Successful response
             content:
               application/json:
                 schema:
                   type: array
                   items:
                     $ref: '#/components/schemas/User'
   components:
     schemas:
       User:
         type: object
         properties:
           id:
             type: integer
           name:
             type: string
           email:
             type: string
   ```

4. **Endpoint Documentation**
   - Document all HTTP methods (GET, POST, PUT, DELETE, PATCH)
   - Specify request parameters (path, query, header, body)
   - Define response schemas and status codes
   - Include error responses and error codes
   - Document authentication and authorization requirements

5. **Request/Response Examples**
   - Provide realistic request examples for each endpoint
   - Include sample response data with proper formatting
   - Show different response scenarios (success, error, edge cases)
   - Document content types and encoding

6. **Authentication Documentation**
   - Document authentication methods (API keys, JWT, OAuth)
   - Explain authorization scopes and permissions
   - Provide authentication examples and token formats
   - Document session management and refresh token flows

7. **Data Model Documentation**
   - Define all data schemas and models
   - Document field types, constraints, and validation rules
   - Include relationships between entities
   - Provide example data structures

8. **Error Handling Documentation**
   - Document all possible error responses
   - Explain error codes and their meanings
   - Provide troubleshooting guidance
   - Include rate limiting and throttling information

9. **Interactive Documentation Setup**
   
   **Swagger UI Integration:**
   ```html
   <!DOCTYPE html>
   <html>
   <head>
     <title>API Documentation</title>
     <link rel="stylesheet" type="text/css" href="./swagger-ui-bundle.css" />
   </head>
   <body>
     <div id="swagger-ui"></div>
     <script src="./swagger-ui-bundle.js"></script>
     <script>
       SwaggerUIBundle({
         url: './api-spec.yaml',
         dom_id: '#swagger-ui'
       });
     </script>
   </body>
   </html>
   ```

10. **Code Annotation and Comments**
    - Add inline documentation to API handlers
    - Use framework-specific annotation tools:
      - **Java**: @ApiOperation, @ApiParam (Swagger annotations)
      - **Python**: Docstrings with FastAPI or Flask-RESTX
      - **Node.js**: JSDoc comments with swagger-jsdoc
      - **C#**: XML documentation comments

11. **Automated Documentation Generation**
    
    **For Node.js/Express:**
    ```javascript
    const swaggerJsdoc = require('swagger-jsdoc');
    const swaggerUi = require('swagger-ui-express');
    
    const options = {
      definition: {
        openapi: '3.0.0',
        info: {
          title: 'API Documentation',
          version: '1.0.0',
        },
      },
      apis: ['./routes/*.js'],
    };
    
    const specs = swaggerJsdoc(options);
    app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(specs));
    ```

12. **Testing Integration**
    - Generate API test collections from documentation
    - Include test scripts and validation rules
    - Set up automated API testing
    - Document test scenarios and expected outcomes

13. **Version Management**
    - Document API versioning strategy
    - Maintain documentation for multiple API versions
    - Document deprecation timelines and migration guides
    - Track breaking changes between versions

14. **Performance Documentation**
    - Document rate limits and throttling policies
    - Include performance benchmarks and SLAs
    - Document caching strategies and headers
    - Explain pagination and filtering options

15. **SDK and Client Library Documentation**
    - Generate client libraries from API specifications
    - Document SDK usage and examples
    - Provide quickstart guides for different languages
    - Include integration examples and best practices

16. **Environment-Specific Documentation**
    - Document different environments (dev, staging, prod)
    - Include environment-specific endpoints and configurations
    - Document deployment and configuration requirements
    - Provide environment setup instructions

17. **Security Documentation**
    - Document security best practices
    - Include CORS and CSP policies
    - Document input validation and sanitization
    - Explain security headers and their purposes

18. **Maintenance and Updates**
    - Set up automated documentation updates
    - Create processes for keeping documentation current
    - Review and validate documentation regularly
    - Integrate documentation reviews into development workflow

**Framework-Specific Examples:**

**FastAPI (Python):**
```python
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="My API", version="1.0.0")

class User(BaseModel):
    id: int
    name: str
    email: str

@app.get("/users/{user_id}", response_model=User)
async def get_user(user_id: int):
    """Get a user by ID."""
    return {"id": user_id, "name": "John", "email": "[email protected]"}
```

**Spring Boot (Java):**
```java
@RestController
@Api(tags = "Users")
public class UserController {
    
    @GetMapping("/users/{id}")
    @ApiOperation(value = "Get user by ID")
    public ResponseEntity<User> getUser(
        @PathVariable @ApiParam("User ID") Long id) {
        // Implementation
    }
}
```

Remember to keep documentation up-to-date with code changes and make it easily accessible to both internal teams and external consumers.

© davila7 · MIT · davila7/claude-code-templates

Similar slash commands

All slash commands for Backend and APIs →

From the same set205

The whole set →

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor