Proxy HTTP Requests To Another Server

Beeceptor is a powerful MITM proxy (man-in-the-middle, or kind of a forward-proxy) that can take your API integration and testing to the next level. Assume that you are using a 3rd party API. By wrapping this API domain with Beeceptor's sub-domain (endpoint), you gain full control over the traffic passing through it. This enables you to inspect and mock requests in real-time, giving you unprecedented flexibility in testing and debugging these API integrations. Check out the following illustration.

Beeceptor serves as a powerful MITM (Man-in-the-Middle) proxy, allowing you to intercept and analyze API traffic between your application and the server. In the provided illustration, a user interacts with a mobile app by clicking a button, which triggers an API call to the server. By accessing the Beeceptor dashboard, you gain the ability to intercept and inspect the request payload in this scenario.

You can inspect payloads for all the API calls (Rest/SOAP/HTTP) originating from your application, mock a few requests, change response data, simulate high latency, and even test API failure scenarios. This flexibility allows you to thoroughly test your application under a wide range of conditions.

Configuring proxy

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

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

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).

SSL Validation Issues

In case you are facing SSL validations issues, you can use HTTP proxy with 'Ignore SSL Errors' setup to unblock an integration. Here, Beeceptor acts as a bridge between your application and external APIs, making it easy to intercept and examine HTTP traffic in real time, and ignoring SSL validations. Checkout our detailed post: Ignore SSL Errors.

Note: For more precise control over proxy behavior or to route requests to multiple endpoints, consider using Proxy or Callout Rule.

Service Virtualization

Service virtualization is the act of creating a replica of a service or deploying a mock service to reduce dependencies. Beeceptor makes this process simple by providing an intuitive interface for editing recorded responses to meet your specific requirements. Check out the video below for an example of how to set up a service virtualization scenario with Beeceptor.