API Documentation That AI Can Read
Bridge the gap between beautiful human-readable docs and the structured specifications AI agents need. Learn to create machine-readable API documentation that enables AI to autonomously discover and use your APIs.
๐ Overview
Your API documentation might be beautiful for humans, with elegant styling, interactive examples, and clear explanations. But when an AI agent tries to understand your API, it needs something fundamentally different: structured, machine-readable specifications.
What You'll Learn
- Why beautiful documentation often fails AI agents
- How to compare documentation formats (OpenAPI, JSON Schema, Markdown)
- The AI-ready documentation checklist
- How DreamFactory auto-generates OpenAPI specs
- Enriching specs with AI-specific hints and metadata
- Best practices for keeping documentation AI-friendly
Why This Matters
AI Autonomy
AI agents can discover, understand, and use your APIs without human intervention.
Self-Documenting
Changes to your API automatically reflect in the documentation AI uses.
Faster Integration
AI can generate correct API calls instantly, reducing development time.
๐ The Documentation Gap
There's a fundamental disconnect between how humans and AI consume API documentation. What makes documentation beautiful and intuitive for a developer can be nearly useless for an AI agent.
How Humans Read API Docs
- Scan headings and navigation to find relevant sections
- Read prose explanations to understand concepts
- Look at code examples and adapt them
- Use interactive "Try it" features
- Infer missing information from context
How AI Reads API Docs
- Parse structured data formats (JSON, YAML)
- Extract endpoint definitions, parameters, and schemas
- Map data types and constraints to code generation
- Require explicit definitions because they can't "infer" as well as humans
- Need machine-readable relationships between operations
The Problem with Prose
Documentation written as paragraphs of text requires AI to "understand" natural language, which is error-prone. A sentence like "Pass the user ID as a query parameter or in the path" is ambiguous. An OpenAPI spec explicitly defines exactly where each parameter goes.
The Translation Problem
The solution? Start with structured specifications, then generate human-friendly documentation from them, not the other way around.
๐ Documentation Format Comparison
Not all documentation formats are created equal when it comes to AI consumption. Here's how the major formats compare:
OpenAPI / Swagger
The gold standard for machine-readable API documentation.
- Fully structured YAML/JSON format
- Explicit parameter types and constraints
- Request/response schemas
- Authentication definitions
- Server and environment configs
- Industry standard, wide tool support
JSON Schema
Excellent for data validation, but incomplete for full API docs.
- Precise type definitions
- Validation constraints
- Nested object structures
- Missing: HTTP methods, paths
- Missing: Authentication
- Best used within OpenAPI
Markdown / HTML
Great for humans, difficult for machines to parse reliably.
- Unstructured prose
- Ambiguous parameter locations
- Code examples need extraction
- No formal type system
- Inconsistent formatting
- AI must "guess" structure
Format Comparison Table
| Feature | OpenAPI | JSON Schema | Markdown |
|---|---|---|---|
| Machine Parseable | Excellent | Excellent | Poor |
| Endpoint Discovery | Yes | No | Unreliable |
| Parameter Types | Explicit | Explicit | Implicit |
| Request Examples | Structured | Partial | Unstructured |
| Auth Specification | Full support | None | Prose only |
| Tool Ecosystem | Extensive | Good | Limited |
The Clear Winner: OpenAPI
OpenAPI (formerly Swagger) is the industry standard for API specifications. It combines the type precision of JSON Schema with HTTP-specific metadata, authentication schemes, and server configurations. Most AI agent frameworks natively understand OpenAPI specs.
โ AI-Ready Documentation Checklist
Use this checklist to ensure your API documentation is ready for AI consumption. Each item directly impacts how effectively AI agents can discover and use your APIs.
Expose OpenAPI Specification
Provide a machine-readable OpenAPI 3.0+ spec at a well-known URL (e.g., /api/docs or /openapi.json). This is the foundation everything else builds on.
Include Request/Response Examples
Every endpoint should have at least one complete example showing realistic data. AI uses examples to understand data shapes and generate correct payloads.
Document All Error Responses
Define error response schemas with status codes, error messages, and any error codes. AI needs to know what can go wrong to handle failures gracefully.
Describe Every Parameter
Include description fields for all parameters explaining their purpose, valid values, and any constraints. Don't assume the name is self-explanatory.
Add Semantic Descriptions
Operations should have clear summary (short) and description (detailed) fields explaining what the endpoint does, not just its technical name.
Define Data Constraints
Use JSON Schema constraints: minLength, maxLength, minimum, maximum, pattern, enum. AI generates valid data when it knows the rules.
Specify Authentication
Define security schemes clearly. AI needs to know if it's API key, Bearer token, OAuth2, and where credentials go (header, query, cookie).
Use Consistent Naming
Stick to a naming convention (camelCase, snake_case) and use it everywhere. Inconsistency confuses AI when mapping between operations.
โ๏ธ Good vs. Poor Documentation
Let's compare documentation that AI can effectively use versus documentation that leaves AI guessing.
Endpoint Definition
Poor: Prose Description
## Get User To get a user, make a GET request to the users endpoint with the user's ID. You can pass the ID in the URL or as a query parameter. The response includes the user's profile data. Example: GET /users/123
Good: OpenAPI Specification
/users/{userId}: get: summary: "Retrieve a user by ID" operationId: "getUserById" parameters: - name: "userId" in: "path" required: true schema: type: "integer" minimum: 1
Parameter Documentation
Poor: Missing Details
parameters: - name: "status" in: "query" # What values are valid? # Is it required? # What does it filter?
Good: Complete Definition
parameters: - name: "status" in: "query" required: false description: "Filter orders by status" schema: type: "string" enum: ["pending", "shipped", "delivered"] default: "pending"
Error Responses
Poor: No Error Documentation
responses: "200": description: "Success" # What about 400, 401, 404, 500? # What's the error format? # How should AI handle errors?
Good: Complete Error Coverage
responses: "200": description: "Order retrieved" "400": description: "Invalid order ID format" "401": description: "Authentication required" "404": description: "Order not found" content: application/json: schema: $ref: "#/components/schemas/Error"
Request Body Examples
Poor: Schema Only
requestBody: content: application/json: schema: $ref: "#/components/schemas/Order" # AI can infer structure but not # realistic values or context
Good: Schema + Example
requestBody: content: application/json: schema: $ref: "#/components/schemas/Order" example: customer_id: 42 items: - product_id: "SKU-001" quantity: 2 shipping: "express"
๐ฌ Anatomy of an AI-Friendly OpenAPI Spec
Let's examine a complete OpenAPI specification that's optimized for AI consumption, understanding each section's purpose.
# Info Section: Helps AI understand context openapi: "3.0.3" info: title: "E-Commerce Orders API" description: | API for managing customer orders. Supports creating, retrieving, updating, and canceling orders. All monetary values are in USD cents (integer). version: "2.1.0" # Servers: AI knows where to send requests servers: - url: "https://api.example.com/v2" description: "Production server" - url: "https://sandbox.example.com/v2" description: "Sandbox for testing" # Security: AI knows how to authenticate security: - BearerAuth: [] # Tags: AI can group related operations tags: - name: "orders" description: "Order management operations" - name: "customers" description: "Customer profile operations" # Paths: The actual API operations paths: /orders: get: tags: ["orders"] operationId: "listOrders" summary: "List all orders" description: | Retrieve a paginated list of orders. Results can be filtered by status, date range, and customer ID. Returns max 100 orders per page. parameters: - name: "status" in: "query" description: "Filter by order status" required: false schema: type: "string" enum: ["pending", "processing", "shipped", "delivered", "cancelled"] - name: "limit" in: "query" description: "Maximum number of results (1-100)" schema: type: "integer" minimum: 1 maximum: 100 default: 20 responses: "200": description: "Successful response with order list" content: application/json: schema: $ref: "#/components/schemas/OrderList" example: orders: - id: 12345 status: "shipped" total_cents: 4999 total_count: 150 page: 1 # Components: Reusable schemas components: schemas: Order: type: "object" required: ["customer_id", "items"] properties: id: type: "integer" readOnly: true description: "Unique order identifier" customer_id: type: "integer" description: "ID of the customer placing the order" status: type: "string" enum: ["pending", "processing", "shipped", "delivered", "cancelled"] default: "pending" total_cents: type: "integer" minimum: 0 description: "Order total in USD cents" securitySchemes: BearerAuth: type: "http" scheme: "bearer" bearerFormat: "JWT" description: "JWT token from authentication endpoint"
๐ญ DreamFactory Auto-Generated Documentation
DreamFactory automatically generates OpenAPI specifications for every connected database and service. This means AI agents can immediately understand your APIs without manual documentation effort.
Accessing the API Documentation
DreamFactory exposes OpenAPI specs through several endpoints:
Returns a list of all available service documentation endpoints.
Returns the complete OpenAPI spec for a specific service (e.g., your database connection).
Returns the database schema information for a database service.
Example: Fetching Your API Spec
# List all available API documentation curl -X GET "https://your-df.example.com/api/v2/api_docs" \ -H "X-DreamFactory-Api-Key: your-api-key" # Get OpenAPI spec for your 'mysql' database service curl -X GET "https://your-df.example.com/api/v2/api_docs/mysql" \ -H "X-DreamFactory-Api-Key: your-api-key" \ -H "Accept: application/json" # Save spec to file for AI agent consumption curl -X GET "https://your-df.example.com/api/v2/api_docs/mysql" \ -H "X-DreamFactory-Api-Key: your-api-key" \ -o openapi-mysql.json
What DreamFactory Generates Automatically
| Feature | Auto-Generated | Notes |
|---|---|---|
| Endpoint paths | Yes | All CRUD operations for each table |
| HTTP methods | Yes | GET, POST, PUT, PATCH, DELETE |
| Parameter schemas | Yes | Based on database column types |
| Response schemas | Yes | Reflects actual data structure |
| Required fields | Yes | From NOT NULL constraints |
| Filter parameters | Yes | Full query parameter support |
| Relationships | Yes | Foreign key relationships exposed |
| Stored procedures | Yes | Input/output parameters documented |
Zero-Effort Documentation
Because DreamFactory introspects your database schema, documentation stays in sync automatically. Add a new table or column? The OpenAPI spec updates immediately. No manual documentation maintenance required.
๐ก Enriching Specs with x-ai-hints
OpenAPI allows custom extensions (properties starting with x-). You can use these to add AI-specific metadata that helps AI agents make better decisions about how to use your API.
Common x-ai Extensions
| Extension | Purpose | Example Value |
|---|---|---|
x-ai-description | AI-optimized description (more explicit than human docs) | "Returns ONLY orders for the authenticated user, not all orders" |
x-ai-examples | Multiple examples for different use cases | Array of example request/response pairs |
x-ai-rate-limit | Rate limit information for AI planning | {"requests": 100, "period": "minute"} |
x-ai-cost | Relative cost for resource-intensive operations | "high" | "medium" | "low" |
x-ai-idempotent | Whether operation is safe to retry | true | false |
x-ai-side-effects | What changes this operation makes | ["sends_email", "updates_inventory"] |
Example: AI-Enriched Endpoint
/orders/{orderId}/cancel: post: operationId: "cancelOrder" summary: "Cancel an order" description: "Cancels a pending or processing order." # AI-specific extensions x-ai-description: | Cancels an order ONLY if status is 'pending' or 'processing'. Orders that are 'shipped' or 'delivered' cannot be cancelled. This operation CANNOT be undone. Use with caution. Triggers email notification to customer. x-ai-idempotent: false x-ai-cost: "medium" x-ai-side-effects: - "sends_cancellation_email" - "releases_inventory_hold" - "initiates_refund_if_paid" x-ai-preconditions: - "Order must exist" - "Order status must be 'pending' or 'processing'" - "User must own the order or be admin" x-ai-common-errors: - code: "ORDER_ALREADY_SHIPPED" meaning: "Cannot cancel - order has shipped" suggestion: "Inform user to initiate return instead" parameters: - name: "orderId" in: "path" required: true schema: type: "integer" x-ai-hint: "Get this from listOrders or order confirmation" requestBody: content: application/json: schema: type: "object" properties: reason: type: "string" maxLength: 500 x-ai-hint: "Ask user for cancellation reason"
MCP Tool Descriptions
When exposing APIs through MCP (Model Context Protocol), the x-ai-description and x-ai-hint extensions map directly to tool descriptions that Claude and other AI agents use to understand when and how to call your APIs.
๐ ๏ธ Spec Enrichment Strategies
Here are practical strategies for enriching your OpenAPI specs beyond the auto-generated baseline.
Add Business Context
Technical documentation often misses business meaning. Add descriptions that explain why data exists and how it relates to business processes.
Order: description: | Represents a customer purchase. Orders progress through statuses: pending -> processing -> shipped -> delivered. Once shipped, orders cannot be modified. Refunds require a separate return request after delivery.
Document Relationships
Help AI understand how entities relate to each other for multi-step operations.
x-ai-relationships: customer: type: "belongs_to" target: "Customer" via: "customer_id" items: type: "has_many" target: "OrderItem" via: "order_id"
Include Workflow Hints
Tell AI what operations typically follow each other.
x-ai-workflow: typical_next_operations: - "addOrderItem" - "applyDiscount" - "submitOrder" related_operations: - "getCustomer" - "getProduct"
๐ Best Practices
Keep Specs Updated
- Automate spec generation: Use tools that generate specs from code or database schemas
- Version your specs: Include version numbers and maintain changelog
- CI/CD integration: Validate specs in your deployment pipeline
- Single source of truth: Don't maintain specs separately from implementation
Include Comprehensive Constraints
email: type: "string" format: "email" maxLength: 255 pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$" age: type: "integer" minimum: 0 maximum: 150 status: type: "string" enum: ["active", "inactive", "pending"] default: "pending" tags: type: "array" items: type: "string" minItems: 1 maxItems: 10 uniqueItems: true
Write for AI Comprehension
- Be explicit: Don't assume AI will infer meaning from context
- Avoid ambiguity: "Pass the ID" should be "Pass the user ID as a path parameter"
- State the obvious: AI benefits from redundancy humans find tedious
- Use consistent terminology: Pick terms and use them everywhere
Common Mistakes
Don't: "Use standard pagination." AI doesn't know YOUR standard.
Do: "Use limit (max 100) and offset query parameters. Response includes total_count for calculating pages."
๐งช Testing Documentation with AI
The best way to know if your documentation is AI-ready is to test it with actual AI agents.
Testing Methodology
- Feed the spec to an AI: Give Claude or another LLM your OpenAPI spec
- Ask it to explain endpoints: Can it accurately describe what each operation does?
- Request sample code: Does it generate correct API calls?
- Test edge cases: Ask about error handling, optional parameters, authentication
- Identify gaps: Where does the AI make incorrect assumptions?
Sample Test Prompts
# Basic comprehension "Based on this OpenAPI spec, how do I create a new order?" # Parameter understanding "What filters are available when listing orders?" # Authentication "How do I authenticate to this API?" # Error handling "What errors might I get when canceling an order?" # Code generation "Write a Python function to fetch orders from the last 7 days" # Edge cases "What happens if I try to update a shipped order?" # Relationships "How do I get all items for a specific order?"
Iterative Improvement
When AI misunderstands something, that's a documentation gap. Add clarifying descriptions, examples, or x-ai-hints. Then test again. Repeat until AI consistently understands your API correctly.
๐ Course Complete!
Congratulations!
You've completed the DreamFactory AI Academy. You now have the knowledge to build secure, powerful AI integrations with your enterprise data.
What You've Learned
- Chat with your data: Connect any AI agent to securely query your databases
- MCP integration: Connect AI agents to DreamFactory APIs seamlessly
- Security fundamentals: RBAC, roles, and API keys for AI access control
- Stored procedures: Encapsulate complex business logic for safe AI execution
- Identity passthrough: Maintain user context so AI respects permissions
- REST best practices: Design APIs that AI can understand and use effectively
- Documentation that works: OpenAPI specs enable AI autonomy
- Local AI integration: Connect local LLMs to enterprise databases through DreamFactory
Next Steps
- Set up your DreamFactory instance: Connect your first database
- Generate API keys: Create role-based access for your AI agent
- Configure MCP: Connect Claude or your AI of choice
- Test with real queries: Let AI interact with your data
- Iterate and improve: Refine based on real-world usage
You're Ready!
You have everything you need to build AI applications that safely and effectively interact with your enterprise data through DreamFactory. Start building!