---
description: Debug API failures using OpenAPI specs and HTTP logs
---

# Debug API Failures

Systematically debug REST API failures by analyzing OpenAPI specifications and HTTP request/response logs.

## Workflow

When the user requests API debugging, follow this comprehensive approach:

### Step 1: Load API Documentation

```
Use load_openapi to parse the OpenAPI spec:
- Accepts JSON or YAML format
- Extracts all endpoints, parameters, and expected responses
- Identifies authentication requirements
- Captures base URLs and server information

Example:
load_openapi({
  filePath: "/path/to/openapi.yaml",
  name: "my-api"
})
```

### Step 2: Ingest HTTP Logs

```
Use ingest_logs to import request/response data:
- Supports HAR (HTTP Archive) format from browser DevTools
- Accepts direct log arrays
- Automatically categorizes successful vs failed requests
- Calculates status code and method distributions

Example (HAR file):
ingest_logs({
  filePath: "/path/to/requests.har",
  format: "har"
})

Example (direct logs):
ingest_logs({
  logs: [
    {
      timestamp: "2025-10-10T12:00:00Z",
      method: "POST",
      url: "https://api.example.com/users",
      statusCode: 400,
      requestBody: { "name": "John" },
      responseBody: { "error": "Missing required field: email" }
    }
  ]
})
```

### Step 3: Analyze Failures

```
Use explain_failure to understand why requests failed:
- Identifies root causes based on HTTP status codes
- Compares actual behavior with OpenAPI spec expectations
- Suggests specific fixes
- Assesses severity (critical, high, medium, low)

Example:
explain_failure({
  logIndex: 0,  // Index from ingest_logs
  specName: "my-api"  // Compare against loaded spec
})
```

### Step 4: Generate Reproducible Tests

```
Use make_repro to create cURL commands:
- Generates executable cURL command
- Includes alternative formats (HTTPie, JavaScript fetch)
- Useful for documentation, bug reports, and testing

Example:
make_repro({
  logIndex: 0,
  includeHeaders: true,
  pretty: true  // Format for readability
})
```

## Common Debugging Scenarios

### Scenario 1: 400 Bad Request

1. **Load spec** to see expected request format
2. **Ingest logs** containing the failure
3. **Explain failure** to identify validation errors
4. **Make repro** to generate test command
5. **Fix request** based on schema requirements
6. **Test** using generated cURL command

### Scenario 2: 401 Unauthorized

1. **Load spec** to check authentication requirements
2. **Explain failure** on 401 response
3. **Verify** authentication headers in request
4. **Check** token expiration or permissions
5. **Make repro** with corrected auth headers

### Scenario 3: 500 Internal Server Error

1. **Ingest logs** to find pattern of 500 errors
2. **Explain failure** to assess criticality
3. **Make repro** for server team to reproduce
4. **Check** request payload for edge cases
5. **Monitor** server logs (not in scope of this tool)

### Scenario 4: Performance Issues

1. **Ingest logs** with duration data
2. **Analyze** distribution of response times
3. **Identify** slow endpoints
4. **Make repro** for performance testing

## Analysis Output

The debugging workflow produces:

### From explain_failure:
- **Severity**: critical | high | medium | low
- **Possible Causes**: List of likely root causes
- **Suggested Fixes**: Actionable remediation steps
- **Matching Endpoint**: Comparison with OpenAPI spec
- **Details**: Request/response bodies for inspection

### From make_repro:
- **cURL Command**: Copy-paste ready command
- **HTTPie Alternative**: Shorter syntax for quick tests
- **JavaScript fetch**: For integration into automated tests
- **Metadata**: Method, URL, headers, body presence

## Best Practices

1. **Always load the OpenAPI spec first** - Provides context for failure analysis
2. **Use HAR files** when possible - Most complete log format
3. **Include request/response bodies** - Critical for validation errors
4. **Compare with spec** - Catches mismatches between docs and implementation
5. **Generate repro commands** - Makes bug reports actionable
6. **Test fixes immediately** - Use generated cURL to verify

## Tips

- Export HAR from browser DevTools (Network tab → Right-click → Save as HAR)
- Use `pretty: true` for readable cURL commands (good for docs)
- Use `pretty: false` for one-liner cURL (good for scripts)
- Check response headers for hints (X-RateLimit-*, Retry-After, etc.)
- Look for patterns in multiple failures (same endpoint, same error)

## Example Usage

```
User: "My API is returning 400 errors, help me debug"

You:
1. First, do you have an OpenAPI spec? If yes, I'll load it.
2. How are you capturing HTTP logs? (HAR file, JSON logs, manual entry?)
3. Let me analyze the failures and suggest fixes.

[After receiving spec and logs]

I've loaded your API spec and found 5 failed requests:
- 3x POST /users → 400 (Missing required field: email)
- 2x GET /users/{id} → 404 (Invalid user ID format)

Let me explain the first failure...
[Uses explain_failure]

Here's a working cURL command to test the fix:
[Uses make_repro]
```

## Notes

- This tool focuses on client-side debugging (requests/responses)
- Server-side logs and profiling are out of scope
- For complex API issues, combine with other debugging tools
- Keep OpenAPI specs up-to-date for accurate analysis