Microsoft Dev Proxy is a free, open-source command-line tool for testing how an app handles API behavior beyond successful responses. It intercepts requests to URLs you specify, then either lets them reach the API or simulates conditions such as errors, throttling, and slow responses. Because it works at the network level, you can test an application without adding failure-simulation code to it.
How Dev Proxy works
Dev Proxy sits between an application and the APIs it calls. After you configure which URLs to watch, the tool can pass matching requests through to the real service or return simulated responses. Microsoft describes it as an API simulator for testing apps beyond the happy path (Microsoft Learn: What is Dev Proxy?).
That network-level approach makes it useful across application stacks, but it also means the proxy must be able to observe the traffic. For HTTPS interception, you need to trust the local Dev Proxy CA certificate. Use URL and process filters to keep unrelated traffic out of the test.
What you can test
Errors, latency, and throttling
Use simulated failures to check whether an app displays a useful error, retries appropriately, or recovers when an API becomes available again. Slow responses help expose loading-state and timeout problems; throttling lets you exercise rate-limit handling. The setup tutorial’s example configuration watches JSON Placeholder endpoints and uses a 50% failure rate. That is a documented example, not a universal setting for every Dev Proxy configuration (Microsoft Learn: Get started with Dev Proxy).
#1 Best Overall
Mock APIs before a backend is ready
Dev Proxy can return mock responses, including responses for CRUD-style API workflows, so a team can prototype or exercise a client before the real backend is available. It is not necessary to build failure handling into the application merely to test those scenarios.
Discover API usage and improve governance
Dev Proxy can record requests and help discover API URLs and usage, including shadow APIs that teams may not otherwise have visibility into. Its OpenAPI support can turn observed traffic into JSON or YAML artifacts: Microsoft says version 0.24, announced in 2025, added JSON and YAML OpenAPI output, URL discovery, request timestamps, and script support (Microsoft Developer Blog: Dev Proxy v0.24).
For Microsoft Graph, Dev Proxy can help inspect how an app uses the API and assess minimal-permission guidance. In 2025, Microsoft announced v1.0 capabilities for language-model API testing as well, including 15 failure types, token-based rate limiting, token usage and cost reporting, OpenAPI improvements, and an MCP server (Microsoft Developer Blog: Dev Proxy v1.0).
Install and run a basic test
- Install Dev Proxy. Microsoft documents installation with winget on Windows and manual installation steps for other platforms. Follow the current platform-specific instructions in the getting-started guide.
- Set up HTTPS interception. Follow the guide to trust the local Dev Proxy CA certificate. Without trusting it, HTTPS traffic cannot be decrypted for interception.
- Start the proxy for the API you want to test. For example, run
devproxy --urls-to-watch "https://your-api.com/*". The wildcard matches URLs under that host; adjust the pattern to your API. See the technical reference for supported options. - Send application requests through Dev Proxy. Exercise the app manually or run tests that generate calls to the watched URLs. Observe how the app responds to the simulated behavior, then change the configuration and repeat as needed.
The technical reference documents a default proxy port of 8000 and API port of 8897, along with a configurable failure rate from 0 to 100. Defaults can change between releases, so check the reference for your installed version before relying on a port or option in a script.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsRank #3
Run Dev Proxy in CI/CD
Microsoft’s CI/CD guidance is to configure the runner’s http_proxy and https_proxy variables for the Dev Proxy endpoint, start the proxy, wait until it is ready, and then run tests that issue API requests. This makes the same kind of simulated behavior available in an automated pipeline rather than only on a developer’s machine (Microsoft Learn: Use Dev Proxy in CI/CD pipelines).
The local control API can start recording with /record and stop the proxy with /stop. These controls can support automated recording and checks for API usage or permissions. If your pipeline controls Dev Proxy programmatically, treat its generated API bearer token as a secret; do not expose it in logs or commit it to source control.
Quick Recap
How Dev Proxy differs from other API testing approaches
| Approach | Where it acts | Useful when | Trade-off |
|---|---|---|---|
| Dev Proxy | Intercepts network requests to watched URLs | You want to exercise an app against real API traffic patterns, inject failures or throttling, discover usage, or run checks in CI/CD. | Requires proxy setup and, for HTTPS interception, trusting its local CA certificate. Filters help limit the traffic it affects. |
| Frontend-only mocks | Inside or alongside the frontend test environment | You need a simple way to control responses for UI development or focused frontend tests. | They do not provide the same network-level interception or broad failure simulation. Microsoft notes this narrower approach may be simpler for narrower needs. |
| Contract testing | Checks agreements between API consumers and providers | You need to verify that services meet an agreed interface contract. | It addresses a different, more focused question than injecting network failures into an app. Microsoft notes contract testing may be simpler when that is the specific need. |
| Dedicated API gateway | Routes and governs API traffic as infrastructure | You need a managed traffic entry point or gateway behavior as part of a deployed architecture. | Dev Proxy is a developer testing tool, not a replacement for production gateway infrastructure. |
Operational cautions
- Use the URL and process-name or process-ID filters to avoid intercepting unrelated applications’ traffic.
- Keep Dev Proxy out of production traffic. Simulated responses intentionally change what the app observes.
- Make the active failure rate clear to anyone running or interpreting a test; otherwise, injected failures can be mistaken for service incidents.
- Protect the bearer token if you use the local control API.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
