Ask Claude to Create API Mocks from Your Actual Integration Code

Developing against external APIs is painful — rate limits, authentication requirements, and services going down all block your workflow. Claude reads your actual API integration code and generates mock responses that match the real data shape.

Read how we call the Stripe API in src/billing/. Generate mock responses 
for each endpoint we use — payment intents, customers, subscriptions — 
with realistic data that covers the happy path and common error states.

Claude reads your API client code, checks what fields you actually access in the response, and generates mocks that match:

{
  "id": "pi_mock_1234567890",
  "object": "payment_intent",
  "amount": 2999,
  "currency": "usd",
  "status": "succeeded",
  "customer": "cus_mock_abc123"
}

Target different mocking needs:

# Generate a complete mock server
Read all external API calls in src/services/. Create a mock server 
that returns realistic responses for each endpoint. Include error 
responses for testing error handling.

# Create test fixtures
Generate JSON fixtures for every external API response our tests need. 
Base the shape on the actual response types we've defined in types/api.ts.

# Mock with edge cases
Create mock responses that test edge cases — pagination with empty pages, 
webhooks with duplicate event IDs, API responses with optional fields 
missing, and rate limit responses.

# Environment-based mocking
Set up a mock mode that activates when an env variable is set, so the 
app uses mock responses in development but real APIs in staging and production.

Ask Claude to keep the mocks maintainable:

Generate a mock factory for each external service. Each factory should 
accept overrides so tests can customise specific fields without rebuilding 
the entire response. Follow the factory pattern used in our existing test helpers.

External APIs are someone else's uptime — mock them locally so your development never blocks on a third-party service.

via Claude Code