Skip to main content

The Importance of Setting Up An API Mock Server

As an app developer, web developer or a project manager have you ever felt or heard the followings?

  • I'm dependent on an API and that's not yet available.
  • The API server is down, I cannot integrate my code.
  • I'm waiting for the API contract update from the backend developer.
  • I spent a full day struggling with these APIs and they are not giving reliable production quality data.
  • I wasn’t able to accomplish much. The VPN was down, and I couldn’t connect to the API.
  • I'm blocked. I need the required APIs to continue development and integration.
  • I'm blocked. The sandbox APIs are broken, and failing with 500 errors.
  • It is a 3rd party, I don't have comprehensive test data created in the sandbox to validate all the application paths.

It's frustrating when you can't work because the API is down or unavailable. Fortunately, API mocking is the solution to these problems.

The term "mock" refers to the act of replicating or imitating a real-world object or person. Similarly, "Mock APIs" refer to the provision of pre-defined API responses for client applications. The Mock APIs are sometimes referred as Fake APIs, Test Doubles, Dummy APIs or stubs. The purpose of all of these is same: run fake business logic instead of real one.


Beeceptor is a hosted mock server that simplifies the process of obtaining the desired API response.

Benefits of using an API mock server

When adopted during software development, the Mock APIs (or mock servers) address several pain points that developers face. It ensures that teams and services work independently and parallel for application development and integration. This results in faster integration, confident testing, and on-time shipment of software components.

Below are some of the direct benefits of using Mock APIs and how they can enhance the development process. Note that these benefits are independent to the platform, type of API (Rest, SOAP, Websockets, etc.), or the size of the project team.


  1. Developing independently: With a mock API server, developers can work independently of the backend team, even before the actual API is implemented. For instance, a frontend developer can use a mock API server to build a UI prototype and test the functionality without waiting for the backend team to complete the development of the actual API.

  2. Reducing dependencies on external APIs: Quite often the sandbox environments of the external APIs are unstable. Mock API servers reduce the dependencies on external APIs and services. For example, a developer can use a mock API server to test a feature that depends on a third-party API, without relying on the availability or stability of that API. All he/she need is the response/data contract.

  3. Testing early and often: Developers can use mock API servers to test their code early in the development cycle and also test edge cases and error scenarios without affecting the actual API. For example, a developer can create a mock API server that returns errors for certain requests, which helps them ensure that their code handles errors correctly.

  4. Simulating different scenarios: Mock API servers can simulate different scenarios to test how the system reacts to different responses. For example, a mock API server can simulate a slow or unresponsive API (timeouts), which allows developers to test how the system responds to these situations.

  5. Faster feedback on API design and contracts: Mock API servers provide faster feedback to developers because they eliminate the need for building and deploying the actual API. For example, a developer can make changes to the mock API server and see the results immediately, without waiting for the actual API to be updated with full business logic.

  6. Cost-effective: Mock API servers are cost-effective because they eliminate the need for setting up and maintaining the infrastructure for the actual API. For example, a startup that is testing a new feature can use a mock API server to test the feature without incurring the costs of setting up a full-fledged API infrastructure.

  7. Collaborate on API contract: Adopting mock API can facilitate effective collaboration between teams by providing a common understanding of the API contract. For example, a backend API developer can share a mock API server with a mobile app developer, which ensures that both parties are working on the same API contract and it fulfills the needs app/UX screens and all are align with the expected behavior.

  8. Avoiding throttling and rate-limiting: Mock API servers can be used to simulate scenarios where the API is rate-limited or throttled. This allows developers to test how their code responds to these scenarios without actually hitting the rate limits of the actual API.

  9. Simplifying onboarding: Mock API servers can simplify the onboarding of new developers by providing a simplified and well-documented API that developers can use to get up to speed quickly. For example, a new developer can use a mock API server to understand how the API works and start working on their feature without dealing with the complexities of the actual API.

How to set up a mock server with Beeceptor?

Beeceptor is an easy and user-friendly mock API tool, requiring no-coding. It provides a hosted option, eliminating the need for any additional instrumentation, dependencies in your code or server setup. The API endpoint given by Beeceptor acts as a mock server for building routes/APIs responding to specific HTTP requests.

To set up a mock server with Beeceptor, follow these simple steps:

  1. Open Beeceptor. Create a new endpoint by giving your project name.

  2. Beeceptor will generate a subdomain for you to send requests to. Copy this URL and use it as the base URL in your API calls to ensure that requests are routed to Beeceptor's subdomain. This subdomain will look like

  3. Any requests made from your application to this subdomain will be automatically responded to with a 200 OK status code by Beeceptor.

  4. Next, you define API routes or paths as mocking rules. By default, Beeceptor creates two mocking rules that align with the requirements of a To Do task listing application. These are GET and POST to /todos request path.

  5. You can define multiple rules, which can match based on request path and method, or any custom logic. The mocking rules are matched from top to bottom. If none of the rules match, your application will receive a 200 OK response from Beeceptor. creating a mocking rule

  6. Copy this subdomain to your code, and start sending requests from your application. You can view these requests on the Beeceptor dashboard.

JavaScript Example Code

Let's take an example where you are building a To Do Task List application and the backend APIs are not yet available. You open Beeceptor and create an endpoint as try-beeceptor. This will give you a dashboard and mock-server as below.

  • Dashboard Link: - This is your control panel. Here you can intercept and review all the API calls. You can see two mock APIs pre-created here as below:
    • GET on path /todos
    • POST on path /todos
  • Mock Server or API Endpoint: - This is the endpoint/domain/base-url, you should use in the code to invoke the API call.

JavaScript Example Code

The following JavaScript code makes an POST request to our API /todos.

fetch("", {
method: "POST",
body: JSON.stringify({
id: 1,
title: "Fix my bugs",
completed: false
headers: {
"Content-type": "application/json; charset=UTF-8"

When you run the above code in an HTML page, the request is triggered to Beeceptor's endpoint and it returns a mocked JSON response. With Beeceptor, you can intercept XHR and fetch requests and receive mock data as per the mocking rule. In addition you can review and inspect request and response payloads live as they happen.


You may have observed that a supplementary OPTIONS request is also made. This request is initiated by the web-browser to verify cross-domain permissions. It's known as Cross-Origin Resource Sharing (CORS) and a security measure. Beeceptor takes it granted by facilitating all OPTIONS requests, making it simpler for UI developers to adopt mock APIs.