Fiddler AutoResponder: Mock API Responses Like a Pro

Why Mocking API Responses with Fiddler AutoResponder Matters

Modern web and mobile applications rely heavily on external APIs — weather services, payment gateways, third-party auth providers, or internal microservices. When those APIs are unstable, rate-limited, slow, or simply unavailable during development or testing, your velocity stalls. That’s where Fiddler AutoResponder shines: it lets you intercept HTTP(S) requests and serve locally defined mock responses — no code changes, no backend redeployments, no waiting for DevOps.

Unlike stubbing at the application layer (e.g., Axios interceptors or Jest mocks), AutoResponder operates at the Fiddler proxy level — meaning it works across browsers, desktop apps, mobile emulators, and even native iOS/Android apps (with proper https decryption configured). It’s an indispensable tool for frontend developers, QA engineers, and security researchers performing fiddler debugging in complex integration scenarios.

This tutorial walks you through configuring AutoResponder to reliably mock RESTful endpoints — including dynamic rules, status codes, headers, delays, and conditional logic — all without touching your application source.

Prerequisites: Get Fiddler Ready

Before using AutoResponder, ensure your Fiddler instance is properly configured:

✅ Install Fiddler Classic (v5.0.20234+ recommended) or Fiddler Everywhere (AutoResponder behavior differs slightly — this guide focuses on Classic).
✅ Enable HTTPS decryption: Go to Tools > Options > HTTPS and check Decrypt HTTPS traffic. Click Actions > Trust Root Certificate and restart Fiddler if prompted. This step is essential for mocking secure endpoints — without it, AutoResponder won’t see or intercept encrypted traffic. See our full https decryption guide for platform-specific fixes.
✅ Confirm Fiddler is set as your system proxy (Tools > Options > Connections > Act as system proxy on startup).
✅ Disable Filters temporarily (Rules > Customize Rules) unless you’re intentionally limiting scope.

💡 Tip: If AutoResponder rules don’t fire, first verify that Rules > Automatic Breakpoints > Before Requests is off — breakpoints override AutoResponder unless explicitly handled.

Enabling and Navigating AutoResponder

AutoResponder is disabled by default. To activate it:

Open the AutoResponder tab (Ctrl+R or Rules > Automatically Respond to Requests).
Check the box Enable rules at the top-left.
Observe the status bar indicator: “AutoResponder: Enabled” appears when active.

The interface has three core areas:

Rule List: A table of matching patterns and response actions.
Add Rule Button (+): Lets you define new match conditions and responses.
Response Editor: Appears when editing a rule — used to craft headers, body, status, and delay settings.

AutoResponder supports two primary matching modes:

Exact URL Match: https://api.example.com/v1/users — matches only that exact path.
Wildcard Pattern: https://api.example.com/v1/* — matches any subpath under /v1/.
Regular Expression (regex): Enable Enable regex (replaces URL) and use PCRE-style syntax like ^https://api\.example\.com/v1/users/\d+$.

⚠️ Note: Wildcards and regex are case-insensitive by default but require escaping special characters (e.g., \. for literal dots).

Step-by-Step: Mock a GET Endpoint with JSON Response

Let’s simulate a user profile fetch from https://api.example.com/v1/users/123. You want to return a consistent, valid 200 OK response — even if the real API is down.

Step 1: Capture the Original Request

Start Fiddler, browse to your app, and trigger the request (e.g., load a profile page).
Locate the request in the Web Sessions list — right-click → Copy > Copy as cURL (optional) or just note its URL and method.

Step 2: Create the AutoResponder Rule

In the AutoResponder tab, click +.
In the Match condition, enter: https://api.example.com/v1/users/123
From the Action dropdown, select Find a file.

Click Browse and select a local .json file (e.g., mock-user-123.json) containing:

{
  "id": 123,
  "name": "Alex Rivera",
  "email": "alex@example.com",
  "role": "admin"
}

Ensure Unmatched requests passthrough is checked (so other traffic flows normally).

Step 3: Refine the Response (Optional but Recommended)

Click the Edit Response button (pencil icon) next to the rule to open the Response Builder:

Set Status Code: 200 OK
Add Headers: Click Add Header, then enter Content-Type: application/json; charset=utf-8
Add Delay: Enter 500 ms to simulate realistic network latency — useful for UI loading state testing.

Now reload your app. The browser receives your mock JSON instantly — no round-trip to the real API. This is pure http debugging power: isolate frontend logic from backend volatility.

Advanced Use Cases: Headers, Status Codes & Dynamic Rules

Simulate Error States

Testing how your app handles 404s, 500s, or rate-limiting? Create a rule targeting https://api.example.com/v1/payments/* and set:

Status Code: 429 Too Many Requests
Headers: Retry-After: 60, X-RateLimit-Remaining: 0
Body: {"error":"rate_limit_exceeded","message":"Try again in 60 seconds."}

No backend required — just configure and test client-side retry logic or toast notifications.

Conditional Matching with Regex

Suppose you need different mocks for different user IDs:

Rule 1 (match): ^https://api\.example\.com/v1/users/(10[0-9]|20[0-9])$ → serve premium-user.json
Rule 2 (match): ^https://api\.example\.com/v1/users/\d+$ → serve basic-user.json

Place more specific regex rules above generic ones — AutoResponder evaluates top-down and stops at the first match.

Mock POST/PUT Requests with Request Body Inspection

AutoResponder can match on method + URL and inspect request body content (e.g., mock a login endpoint only when credentials match):

Enable Enable rules and click +.
Choose Match request headers/body.
In Match condition, select Request Body contains and enter "username":"testuser".
Set response to return 200 OK with a JWT token mock.

🔍 Pro tip: Use Inspectors > TextView on a captured POST to copy exact payload formatting — whitespace and quotes matter in body-matching rules.

Troubleshooting Common AutoResponder Issues

Symptom	Likely Cause	Fix
Rule never triggers	HTTPS decryption disabled or certificate not trusted	Re-run Tools > Options > HTTPS > Actions > Trust Root Certificate and restart Fiddler. Verify decrypted sessions appear in main grid (lock icon should be open).
Mock returns 404 or blank response	File path invalid or missing `Content-Type` header	Double-check file location and permissions. Always add `Content-Type` manually — Fiddler won’t infer it from `.json` extension.
Delay doesn’t apply	Delay field left empty or set to `0`	Enter numeric value (e.g., `2000`) — no units or commas.
Rule works in Chrome but not in Electron/native app	App bypasses system proxy	Configure app to use `127.0.0.1:8888` explicitly, or use Fiddler’s WinConfig tool to force proxy inheritance.
Multiple rules conflict	Generic rule placed above specific one	Reorder using drag-and-drop in the rule list — most specific first.

If issues persist, enable Log > Show Log and filter for AutoResponder. Fiddler logs every match attempt — invaluable for debugging pattern logic.

Best Practices & Pro Tips

Version your mocks: Store .json files in source control alongside your frontend repo. Name them descriptively (auth-success-200.json, payment-fail-500.json).
Use relative paths: AutoResponder resolves files relative to Fiddler’s install directory unless you use absolute paths (e.g., C:\mocks\users.json). Prefer absolute for team consistency.
Leverage Unmatched requests passthrough: Keep this enabled unless you’re doing full offline simulation — otherwise, your app breaks on non-mocked endpoints.
Combine with Composer: Need to test edge cases not covered by static files? Right-click any session → Replay > Replay with Composer to tweak headers/body and resend — great for ad-hoc validation before baking into AutoResponder.
Document rules: Add comments in the Comment column (right-click rule → Edit Comment) — e.g., “Used for CI smoke tests”, “Simulates legacy auth flow”.

For deeper inspection workflows, pair AutoResponder with Fiddler’s request modification features like Breakpoints, QuickExec, and Custom Rules. You’ll gain surgical control over every layer of your HTTP stack.

Conclusion: Master Your API Dependencies

Fiddler AutoResponder transforms how teams approach integration testing, frontend development, and performance validation. By decoupling your client from backend availability, you eliminate flaky tests, accelerate feedback loops, and gain confidence in edge-case handling — all within a mature, battle-tested fiddler proxy environment.

You now know how to:

✅ Enable and configure AutoResponder with proper https decryption
✅ Create precise URL, wildcard, and regex-based rules
✅ Serve custom JSON, status codes, headers, and simulated latency
✅ Debug mismatches using Fiddler’s log and inspectors
✅ Scale mocks across teams using versioned local files

AutoResponder isn’t just about convenience — it’s about control. Whether you're validating a new React hook, verifying error UX in a Flutter app, or stress-testing timeout logic in a .NET service, this feature sits at the heart of professional fiddler debugging and http debugging workflows.

Ready to go further? more tutorials cover advanced topics like automated script injection, TLS fingerprint analysis, and cross-platform mobile capture. For focused learning, browse Request Modification tutorials. And if your team needs tailored guidance on scaling Fiddler in CI/CD or enterprise environments, contact us.