How to Capture API Requests With Charles Proxy

Charles Proxy is one of the most widely used HTTP debugging tools among developers and QA engineers. It sits between your device and the internet, recording every request and response that passes through — making it invaluable for inspecting API calls, diagnosing network issues, and understanding how apps communicate with backend services.

What Charles Proxy Actually Does

Charles operates as a man-in-the-middle (MITM) proxy. When you configure your browser or device to route traffic through Charles, it intercepts outgoing requests before they reach the server and captures the responses on the way back. You see the full conversation: headers, request bodies, status codes, response payloads, and timing data.

This is especially useful for API debugging because most modern APIs communicate over HTTP or HTTPS — the same protocols Charles is built to intercept.

Setting Up Charles to Capture HTTP Traffic

For unencrypted HTTP traffic, setup is straightforward:

1. Install Charles on your machine (available for macOS, Windows, and Linux).
2. Launch Charles — it immediately begins listening on port 8888 by default.
3. Charles auto-configures as a system proxy on macOS. On Windows, you may need to enable it manually under Proxy > Windows Proxy.
4. Open a browser or trigger an API call from your application.
5. Requests appear in the Structure or Sequence view in real time.

The Structure view organizes traffic by domain, which makes it easy to isolate calls to a specific API host. The Sequence view shows all requests in chronological order — useful when you're tracking the exact order of API calls during a session.

Capturing HTTPS and Encrypted API Traffic 🔐

Most APIs today use HTTPS, which means traffic is encrypted by default. To inspect it, you need to enable SSL Proxying in Charles.

Install the Charles Root Certificate

Charles decrypts HTTPS traffic by issuing its own certificates. For this to work without errors, your machine (and any device you're proxying) must trust the Charles root certificate.

• On your computer: Go to Help > SSL Proxying > Install Charles Root Certificate, then trust it in your system keychain or certificate store.
• On iOS: Navigate to chls.pro/ssl in Safari on your device, install the profile, then go to Settings > General > About > Certificate Trust Settings and enable full trust for the Charles certificate.
• On Android (Android 7+): Install the certificate via chls.pro/ssl, but note that apps targeting API level 24+ no longer trust user-installed certificates by default. You may need a debug build of the app or a network security config override to capture traffic from those apps.

Enable SSL Proxying for Specific Hosts

Installing the certificate alone isn't enough. You also need to tell Charles which domains to decrypt:

1. Go to Proxy > SSL Proxying Settings.
2. Click Add and enter the host (e.g., api.example.com) and port (443).
3. To capture all HTTPS traffic, enter * as the host wildcard — though this is noisy and better suited for exploratory debugging than targeted work.

Once enabled, HTTPS requests will show their full contents instead of a <ssl proxying not enabled for this host> message.

Capturing Mobile API Traffic

To intercept API calls from a mobile device, you route the device's traffic through Charles running on your computer.

Both devices must be on the same Wi-Fi network as the machine running Charles.

Filtering and Focusing on Specific API Calls

Capturing everything generates a lot of noise. Charles offers several ways to narrow your focus:

• Focus on a host: Right-click a domain in Structure view and select Focus to push everything else into a collapsed "Other Hosts" group.
• Recording settings: Under Proxy > Recording Settings, use the Include/Exclude tabs to define which hosts or URL patterns Charles should capture.
• Search and filter: The search bar in Sequence view filters by URL, making it easy to find specific endpoints.
• Breakpoints: Charles can pause a request mid-flight (Proxy > Breakpoints), letting you inspect or even modify the request or response before it continues. This is powerful for testing how your app handles different API responses.

What Affects Your Results

Several variables determine how smoothly this process goes:

• Operating system: macOS integrates more seamlessly with Charles than Windows or Linux for system-level proxy configuration.
• App type: Browser-based API calls are the easiest to capture. Native mobile apps require device proxy configuration. Apps with certificate pinning actively resist MITM proxies and require additional workarounds to bypass.
• Android version: Devices running Android 7 and above have stricter certificate trust policies, making HTTPS interception more complex for production apps.
• API authentication: Some APIs use mutual TLS (mTLS), where the client must also present a certificate — adding another layer of configuration.
• Traffic volume: Capturing all traffic from a busy app can slow Charles and make it harder to isolate relevant calls. Targeted recording settings help considerably.

Certificate Pinning: The Common Roadblock 🚧

If you configure everything correctly and still see SSL errors or empty responses, the app likely implements certificate pinning — a security measure that hard-codes a specific certificate or public key into the app itself. Pinned apps reject Charles's certificate regardless of system trust settings.

Bypassing certificate pinning typically involves modifying the app binary, using tools like Frida or objection, or working with a debug build where pinning is disabled. This moves into reverse engineering territory and carries its own technical and legal considerations depending on context.

The Variables That Determine Your Experience

Capturing API requests with Charles works reliably across many common setups, but the specific combination of your platform, app type, Android/iOS version, and whether the app uses certificate pinning shapes what's actually visible to you. A developer working with their own debug builds has a very different experience than someone attempting to inspect a third-party production app. The tool is consistent — but how much of the traffic you can actually read depends entirely on the stack you're working with.