Claude Skills Guide

Best Way to Configure Claude Code to Understand Your Internal APIs

Getting Claude Code to effectively understand and work with your internal APIs requires strategic configuration across multiple dimensions: providing API documentation, setting up proper context, and leveraging Claude’s built-in capabilities for API interaction. This guide covers the most effective approaches for making Claude Code your go-to tool for internal API development.

Why Configure Claude Code for Internal APIs?

Claude Code, like other AI coding assistants, performs significantly better when it has proper context about your APIs. Without configuration, Claude must:

Proper configuration transforms Claude from a generic coding assistant into an API-aware partner that understands your specific endpoints, data models, and business logic.

Method 1: Using CLAUDE.md Files for API Context

The most foundational approach is creating a CLAUDE.md file that documents your key APIs:

# Project API Documentation

## Authentication
All internal APIs require Bearer token authentication via the Authorization header.

## Core Endpoints

### User Service
- `GET /api/v1/users/{id}` - Returns user by ID
- `POST /api/v1/users` - Creates new user
- `PUT /api/v1/users/{id}` - Updates user

### Order Service  
- `GET /api/v1/orders` - List orders with pagination
- `POST /api/v1/orders` - Create order
- `GET /api/v1/orders/{id}/status` - Check order status

## Error Response Format
All errors return:
```json
{
  "error": {
    "code": "ERROR_CODE",
    "message": "Human readable message"
  }
}

Rate Limits

This approach works well for small to medium APIs but becomes unwieldy for large API surfaces.

Method 2: Leveraging OpenAPI Specifications

For larger APIs, point Claude Code directly to your OpenAPI specification:

# In your CLAUDE.md or project config
api_spec: ./api/openapi.yaml

Claude can analyze OpenAPI specs to understand:

Generating OpenAPI Specs from Code

If you don’t have OpenAPI specs, generate them:

# For Python/FastAPI
pip install fastapi-openapi
# Your API will have /openapi.json endpoint

# For Node.js/Express
npm install @apidevtools/swagger-parser

Creating a CLAUDE.md that References OpenAPI

# API Reference

Our API is documented in OpenAPI format. See:
- Full spec: `api/openapi.json`
- Interactive docs: `http://localhost:8000/docs`

Key endpoints for this project:
- User management: /api/v1/users/*
- Order processing: /api/v1/orders/*
- Billing: /api/v1/billing/*

Always check the OpenAPI spec for complete parameter definitions.

Method 3: Using Model Context Protocol (MCP) for Live API Access

MCP servers can provide Claude with real-time API information:

// Example MCP server for internal API
const server = {
  name: "internal-api",
  tools: {
    list_endpoints: {
      description: "List all available API endpoints",
      parameters: {
        service: { type: "string", description: "Service name" }
      }
    },
    get_endpoint_docs: {
      description: "Get documentation for a specific endpoint",
      parameters: {
        path: { type: "string" },
        method: { type: "string" }
      }
    }
  }
};

Setting Up MCP for Your APIs

  1. Create an MCP server that wraps your API documentation
  2. Configure Claude Code to use the MCP server
  3. Define tools for common API operations
// tools/api-mcp-server.js
export const apiServer = {
  async listServices() {
    return ["users", "orders", "billing", "analytics"];
  },
  
  async getEndpoint(service, path) {
    return {
      method: "GET",
      path: `/api/v1/${service}/${path}`,
      params: { limit: "number", offset: "number" },
      response: { data: "array", total: "number" }
    };
  }
};

Method 4: Creating API-Specific Claude Skills

Claude Skills allow you to package API knowledge into reusable units:

# api-helper.claude
---
name: API Helper
description: Expert in our internal API patterns
tools: [read_file, write_file, bash]
---

# API Helper Skill

You specialize in our company's internal APIs.

## Base URL
Production: https://api.company.com/v1
Staging: https://api-staging.company.com/v1

## Standard Headers

Authorization: Bearer {token} X-Request-ID: {uuid} X-Correlation-ID: {uuid}


## Common Patterns

### Pagination
All list endpoints use limit/offset:
```javascript
const params = { limit: 50, offset: 0 };

Error Handling

Always check for error field in responses:

if (response.error) {
  throw new APIError(response.error.code, response.error.message);
}

Testing

Use the staging environment for all testing:

Installing API Skills

claude config add-skill ./skills/api-helper.claude

Method 5: Environment-Specific Configuration

Create separate configurations for different environments:

# .claude/env-local.sh
export API_BASE_URL="http://localhost:8080/api/v1"
export API_TOKEN="dev-token"

# .claude/env-staging.sh  
export API_BASE_URL="https://api-staging.company.com/v1"
export API_TOKEN="staging-token"

# .claude/env-prod.sh
export API_BASE_URL="https://api.company.com/v1"
# Prod tokens should be injected via CI/CD

Reference these in your CLAUDE.md:

## Environment Configuration
- Local development: Use `.claude/env-local.sh`
- Staging: Use `.claude/env-staging.sh`  
- Production: Tokens provided by CI/CD environment

Best Practices for API-Aware Claude Configuration

1. Keep Documentation Live

Stale API documentation is worse than no documentation. Use:

2. Include Real Examples

## Example: Creating a User

Request:
POST /api/v1/users
Content-Type: application/json
Authorization: Bearer {token}

{
  "email": "user@example.com",
  "name": "John Doe",
  "role": "developer"
}

Response (201):
{
  "data": {
    "id": "usr_123",
    "email": "user@example.com",
    "name": "John Doe",
    "created_at": "2026-03-18T10:30:00Z"
  }
}

3. Document Non-Obvious Patterns

## Gotchas

- User IDs are prefixed with "usr_" in database but use bare ID in API
- Timestamps are UTC only - no timezone support
- Rate limits return 429 with Retry-After header
- Some endpoints require both auth and API key in header

4. Version Your API Configurations

# In project structure
.claude/
├── api-v1.md      # Legacy API version
├── api-v2.md      # Current version
└── api-v3.md      # Beta/new endpoints

Putting It All Together

A comprehensive setup combines all methods:

# Project CLAUDE.md

## API Overview
Our platform exposes multiple internal services. See `docs/api/` for full specifications.

## Quick Reference

### Services
| Service | Base Path | Auth |
|---------|-----------|------|
| Users | /api/v1/users | Bearer |
| Orders | /api/v1/orders | Bearer + API Key |
| Billing | /api/v1/billing | Bearer |

### Key Endpoints
- Create user: POST /api/v1/users
- Get order: GET /api/v1/orders/{id}
- Process payment: POST /api/v1/billing/charge

## Detailed Docs
- OpenAPI spec: `docs/api/openapi.yaml`
- MCP server: `./mcp/api-server.js`
- API Helper skill: `./skills/api-helper.claude`

## Testing
Always test against staging first. See `.claude/env-staging.sh` for credentials.

## Common Patterns
See `docs/api/patterns.md` for retry logic, error handling, and pagination conventions.

Conclusion

Configuring Claude Code for internal APIs is an investment that pays dividends in developer productivity, code quality, and reduced debugging time. Start with CLAUDE.md documentation, graduate to OpenAPI integration for larger APIs, and consider MCP servers for the most dynamic API surfaces. The key is keeping your configuration as current as your actual API.

Remember: Claude Code is only as effective as the context you provide. Invest in your API configuration, and Claude will become an expert in your API ecosystem.

Built by theluckystrike — More at zovo.one