Create Mock Server and Manage Routes
Beeceptor is a powerful mock server that enables you to create mock APIs without any coding. It offers a seamless no-code solution, allowing you to quickly create a dedicated sub-domain as your API/server endpoint.
When a request is sent to this Beeceptor endpoint, it is matched against rules that you configured. These rules are evaluated and the first matching rule is used to generate a mocked response. In the event that none of the defined rules match for the incoming request, a default response with a 200 OK
status code is sent. With Beeceptor, you can effortlessly create and test your API integrations with confidence, knowing that your mock server is seamlessly simulating your desired behavior.
Creating a mocking rule
To manage mock server routes, use the Mocking Rules link on the endpoint's dashboard. Creating a rule involves two steps.
1. Match a request
A request is matched against the HTTP method and a matching criteria. The matching criteria can be any of the following cases from the incoming request.
- Request path exactly matches given text
- Request path starts with given text
- Request path contains given text
- Request path matches a regular expression
- Request body contains some text
- Request body matches a regular expression
- Request header value matches a regular expression
When a request is received at the Beeceptor endpoint, it's matched against the mocking rules. The first matched rule determines the mock response sent to the caller. You can adjust the priority of these rules by rearranging them in the list.
2. Send a desired response
The second section in the create rule form defines what to send as HTTP response when the given rule is matched. You can define following things in this section.
- Response HTTP status code: Enter a valid HTTP status code between 200 and 599.
- Response Headers: Specify multiple response headers in JSON format.
- Response Body/Payload: Define the content for the response.
.
Introducing delay
In the response section, you have the option to introduce a delay for the response. The caller will receive the response after a specific number of seconds.
Beeceptor handles this delay computation on the server and attempts to match the specified seconds. However, please be aware that requests may take slightly longer than the exact time specified. This variance is influenced by factors such as network latency, server load, and other related variables.
Advance matching parameters
Here are a couple of advanced strategies to optimize request matching features within Beeceptor:
Multi-Condition Matching
Imagine a scenario where you are building a POST
request at the endpoint /login
and you want to simulate success and failure scenarios.
- If the entering request body contains the word 'alex' as a username the call should success with
200 OK
. - Else, the call should be failed with
401 Unauthorized
.
With Beeceptor, you can craft a condition that triggers a successful login response specifically for Alex. Anyone else will fail the login attempt. This flexibility empowers you to simulate diverse scenarios, enhancing your testing and development workflow.
You can introduce AND conditions to incorporate supplementary conditions during the request matching process. Here's a brief demonstration showcasing this functionality in action.
Beeceptor provides a pre-built JSON Mock Server for the above login behavior. You should give it a try.
Matching path parameters
If you are matching a request using regular expression (RegEx) on the request path, you can use named groups. All the named groups and their values are available as template variables.
The above example considers that you are building an API mock for Company entity. You can match all the requests paths for Company entity and extract the company-id as path parameter.
Regular expression examples
/companies/(?<company_id>[a-zA-Z0-9-]+)
- for matching alphanumeric company-ids. Example request path/companies/be32a3a3-c2af-493c-adbd-ae2d09d8a0b8
/companies/(?<company_id>[0-9]+)
- for matching numeric company-ids. Example request path/companies/123
Using path parameters in templates
The named groups are available to be used as path parameters in templated response. You should use the following syntax.
{{pathParam 'group-name' 'default-value'}}
Example:
{{pathParam 'company_id' '123'}}
Discover Matched Mock Rules (For Debugging)
When dealing with multiple rules that share similar or slightly varied request paths, it can be challenging to pinpoint which rule was matched. Beeceptor simplifies this process by helping you identify the exact rule that matched.
Dashboard Visibility
When a rule is successfully matched for a mocked response, a tickmark icon will appear alongside the request log on the dashboard. A single click allows you to review the specific rule that produced this match. To illustrate this feature, here's a quick demo.
Programmatic Insight
For those who programmatically utilize Beeceptor APIs to configure mock rules, you can find an HTTP header named x-beeceptor-rule-id
within the mocked response. This header contains the rule ID that was matched to generate the HTTP response, providing you with invaluable insights for debugging and troubleshooting.