Proxing HTTP Requests

Beeceptor is an MITM (man-in-the-middle) proxy as well. It wraps your API endpoint with Beeceptor's sud-domain. This facilitates intercepting traffic and giving you an opportunity to inspect and mock in between. You can change response or simulate high latencies.

Configuring proxy

Here is how you can update an endpoint to be a proxy for your target API domain.

When proxy is configured, all the requests sent to Beeceptor endpoint are routed to target endpoint. In addition, you can view these requests and response payloads on the Dashboard.

When to use proxying

Proxying is an interesting feature that help you discover hidden bugs during systems integration testing. Here are a few such cases explained.

Simulate slow external API response

E.g. If you are calling an external API and want to test scenarios around how does the your product/code behaves when the external API is slow to respond? You can wrap external API endpoint under a Beeceptor endpoint and create a mocking rule to delay all responses, say by 5 seconds.

Test failure code paths

As a QA engineer, you have no control to simulate failure scenarios of an external API and test your product/code to see how it will behave. In short, the code paths dealing with error scenarios are never tested. You can wrap external API endpoint under a Beeceptor endpoint and create a mocking rule to return 500 server error or 502 gateway error.

Performance testing

You can save cost by not calling external APIs during performance testing. E.g. do you really need to send emails notifications via an external service (and incur usage cost) when performance testing your application? You can mock the API responses as 200 using Beeceptor without triggering any external API (in this example email APIs).