QuickMocker FAQ

Find out answers to questions related to webhooks testing, creating fake APIs, dummy API, API for tests, simulated API, API stubs, API prototyping using QuickMocker - the best Online API Mocking Tool.


Questions

If you are not able to find answers to your questions, please send us a message using contact form or send us direct email to support@quickmocker.com.


Do I need to code anything to create mock API using QuickMocker?

No, you do not need to know any coding (programming) language in order to create API mock. All you need in order to create a mock endpoint is:

  • HTTP Method of the endpoint (e.g. POST, GET etc)
  • URL Path (e.g. /user/123)
  • Response HTTP Status (e.g. 200 for success, 401 for unauthorized access, 403 for access forbidden and so forth)
  • Response Body (optionally). Any kind of response body in whatever format you need (text, html, json, xml etc). There are no limitations.
  • Response Headers (optionally). Provide response headers using JSON format. For instance {"Content-Type": "application/json"}

That's it. In case you do not have this info, you can get sample of it from your back-end or 3rd party software engineers and use it inside QuickMocker until real web services development is completed.

So, simply create your project with its own subdomain and start adding your mock endpoints.

QuickMocker also supports Regular Expressions for URL Path , multiple HTTP methods and response templating using Shortcodes (Dynamic or Fake Response Values) for more advanced and sophisticated endpoints mocking.


Can I capture (intercept) and debug requests to my mock (fake) API?

Yes, that's one of the main features of QuickMocker. All the requests to your fake API are logged inside the Requests Log of every project separately. The records will appear in the Requests Log tab immediatelly after the request to your endpoint is executed. Each log record is an expandable panel. At first you can see request HTTP method, request URL, response status and date of the request. When you expand the panel you can see all the request and response details (headers and body for both request and response) in separate subtabs.

Intercept / capture and debug requests to mock /fake API


Can I set multiple requests methods per endpoint (URL Path)?

Yes, we support multiple request HTTP methods (e.g. GET/HEAD etc.) per endpoint. If endpoint has multiple methods, it will get label of the first method plus amount of other method (e.g. GET + 2) and will be marked with a dashed border like on the image below:

Multiple Methods per Endpoint


What is RegExp URL Path?

With the RegExp URL Path you can intercept requests using Regular Expressions (or so called search patterns). What does this mean? It means instead of creating multiple endpoints with a static URL path, you can define just one single endpoint that matches the required search pattern.

For instance, imagine you have an endpoint where you need to get user object, e.g. 'GET /user/‹id›'. In order to get multiple users with different IDs, you would have to define multiple endpoints with URL Path like 'user/1', 'user/2' and so on.

Using RegExp URL Path you can define one endpoint with the following path: '^user/[0-9]+$'. This URL Path will allow you to intercept any user ID.

For you information, after you create a new project (endpoints collection), QuickMocker automatically generates one RegExp endpoint (so called wildcard endpoint) with the following URL path ^(.*)$, which intercepts all the requests that do not match endpoints URLs that you have defined manually inside your API mock collection. You may preview those requests on the "Requests Log" tab. By default this endpoint has 404 (Not Found) response status code, but you can easily change it to 200 or whatever you need.

You may read more about regular expressions on Wikipedia.

Please note that RexExp URL path that does not have start (^) and end ($) symbols, will match the request URI at any position. E.g. if you set URL path for your endpoint to "mocker" and after that you send request to "/some-url/mocker/test" or to "/i-got-some-mocker-here", all of them will be intercepted by this endpoint. Same as you would send request just to "/mocker".


Why is there an endpoint already in a new fresh project?

After you create a new endpoint, we automatically generate a default endpoint which intercepts all the requests to your URL and responds with the 404 status code. It looks like on the screenshot below:

Default Project Endpoint

Because of this any request to your project (including unexisting) will be logged. Keep this endpoint at the bottom of your endpoints list so it has the least of priority. This means it will be triggered only in case there was no other matching endpoint.

Please note: in case you remove or disable this endpoint, you won't be able to debug requests that do not match any method name / URL Path among the endpoints you defined and therefore it will be more difficult to fix your incorrect requests. Thus we recommend you to always keep this endpoint enabled in the list.


Why does the requests log stopped intercepting requests?

First of all, it might be a simple network issue. Try to refresh the page.

In case it does not help, then please check if you still have a default wildcard endpoint on the Project's Endpoints page.

Default Project Endpoint

If it is missing, you'll need to recreate it. To do this, simply click Add Endpoint.

Add new Endpoint

While defining the endpoint make sure that:

  • All the HTTP methods are enabled
  • URL Path is equal to: ^(.*)$
  • The option "Allow Regular Expression inside the URL Path" is enabled

Default Wildcard Endpoint Settings

The response headers, body and status could be set to anything you need.

Finally, to be sure that this wildcard endpoint does not override another endpoints, move (drag & drop) the endpoint to the end of the endpoint's list after you have created it.


What are Dynamic Response Values (Shortcodes)?

With the help of shortcodes or dynamic response values (DRV) you can turn fake API endpoints into almost real. Shortcodes can return the data depending on the context like request URL, request body parameters or any other request data like method, date, time etc. Apart from that, shortcodes can generate random fake data, for instance user profile information or some random fake text etc. For example generate multiple fake user names inside the same response. Currently we support around 100 shortcodes that allow to make each response unique with its own data. Sample shortcode looks like (fakeName). Some of the shortcodes support parameters, e.g. (fakeName:female:en_US).

View the list of all shortcodes available at QuickMocker by going to the "Shortcodes - Dynamic or Fake Response Values" page.

To view all the shortcodes, you can also go to the corresponding link under the response body field inside the endoint create/edit section:

Link to the Shortcodes: Dynamic or Fake Response Values

We have also prepared 3 sample templates for the response body that include shortcodes. View the sample templates at the Sample Shortcode Response Body Templates page to understand better the purpose and usage of dynamic response values.


Why do I need to Cache the Response Body?

Enable Cache Response Body when you use shortcodes inside your endpoint's response body, especially when you need a static response that should not change. Without enabling this cache, the endpoint will return inside the response body new data generated by random or fake types of shortcodes on every request. For instance (fakeUser) shortcode will turn into different names on each request. When you enable the cache, the response body will remain the same (identical) with each subsequent request.

In case there are plenty of shortcodes inside the request, it might take a while to generate a response back to you. Enabling the cache will speed up the subsequent requests and it will allow you to perform your development tasks quicker.

How to enable/disable the option:
In order to enable/disabled the response body cache option, use the toggler below the Response Body field:

Cache Response Body

How to flush the cache:
1. The cache is automatically flushed when you change the Response Body field inside the endpoint setting.
2. You can flush the cache manually at any time by clicking the Clear Response Body Cache button inside the endpoint's kebab menu. See the screenshot below:

Clear Response Body Cache

Please note, the Clear Response Body Cache will be disabled in case Response Body Cache is not enabled inside the endpoint settings.


How do I test webhooks with Local Forwarder?

Local Forwarder is a really cool and unique feature from QuickMocker that allows to forward the captured endpoint request to any other URL including your local web server URL. It is especially handy when you test or debug a webhook integration with the 3-rd party service on your local environment. As you might know already, the server app on your local machine is not reachable from the Internet, which makes the debugging and testing of the webhooks a bit difficult. QuickMocker can help you receive external requests (server callbacks) from the 3-rd party and forward them to your local server app (webhook URL). And by the way, no need to install any additional software or extension, all works directly from the browser.

To setup Local Forwarder for the webhooks testing and debugging on the localhost, complete the following steps:

  • Simply create a new dummy API endpoint inside your QuickMocker Project with the same HTTP method and URL path (URI) as in your server application, e.g. "POST /zoom/webhook/training". This dummy API endpoint is able to receive requests from anywhere because it gets a public URL, for instance "https://your-project.quickmocker.com/zoom/webhook/training" depending on your project domain URL.
  • After the webhook endpoint is ready, go to the project’s Requests Log tab where the requests to the webhook URL from the 3-rd will be logged.
  • Click Set Local Forwarder or Update Local Forwarder button and in the modal window provide a base URL of the server app, e.g. https://localhost.
  • In case your local server application in using a non-secure (non-SSL) protocol (e.g. http://localhost), allow Mixed Content for QuickMocker inside the site settings of your browser. For instance, in Chrome browser click on the lock icon next to the site address, then go to the Site Settings and from there allow Insecure Content. This action needs to be done only once. For all the rest browsers please read through the following article. And if you'd like to know more about what is mixed content, read an article here.
  • The last thing you need to do is make sure that you server app and particularly the webhook(s) endpoints on your local machine has CORS (Cross-Origin Resource Sharing) and OPTIONS (preflight request) method enabled. Repeating again, the CORS and OPTIONS method has to be enabled on the level of your local server or local server application. This is required due to the nature of QuickMocker's Local Forwarder which is the "in-browser solution". At first, this might seem a bit unusual or inconvinient, but on the other hand you do not need any 3-rd party software to be installed on your local machine. All is done within the browser and particularly within QuickMocker, which is pretty cool... agree! :)
    If you do not know how to enable CORS or OPTIONS method for you application, have a look at this site. This site might miss the enabling of the OPTIONS method for some web servers / technologies, so you might need google or stackoverflow a bit :)

If everything was set up correctly, the requests from the 3-rd party will be forwarded to your application automatically. If anything is wrong, the error message will appear. Please note that QuickMocker's Local Forwarder is working on the browser level, which means it can forward the request to your app only when the project's Requests Log tab is turned on.

You have an option to forward captured requests manually whenever you need and as much as you need. Simply unfold any existing request record and click Forward Request button.

Forwarder Response tab

After the request is forwarded manually or automatically, the new Forwarder Response tab appears with the response header and body from your server app's endpoint. You may manually resend the request from there by clicking the Forward Again button.

Forward Webhook Request Again

Finally we have prepared a video guidance on how to use QuickMocker using a sample app:

You may grab the sample using GitHub repo: https://github.com/quickmocker/stripe-payment-intent-webhook-test


Can I set Proxy for my mock API?

Yes, you can define proxy for any endpoint. When requesting your QuickMocker endpoint URL, the data will be forwarded to Proxy URL. After the response received from Proxy URL, it will returned back as it was a usual request to QuickMocker's endpoint.

You can configure default proxy URL for the project. It will be applied for all new endpoints you create. See screenshot below:

Configure default proxy for project

Except for this, you can change the Proxy URL for existing endpoints or override Proxy URL for new endpoints while creating or editing endpoint. See screenshot below:

Configure proxy for endpoint


What is the difference between Local Forwarder and Proxy?

Both of them have very similar priciple of a work. Still, the proxy works on the server level, but the local forwarder works on the level of your own browser. Lets see main differentce between those two:

Local Forwarder:

  • Works on the browser level
  • Forwards requests only when you open project's requests log tab in your browser
  • Is able forward request to any URL including your localhost URL

Proxy:

  • Works on the server level
  • Forwards requests all the time (does not matter if you open project requests log or not)
  • Unable to forward requests to your localhost URL

Can I import endpoints from OpenAPI or Swagger?

Yes, QuickMocker supports a bulk import of endpoints using OpenAPI (or formerly Swagger) Specifications. Simply go to your project and hit OpenAPI Import button.

OpenAPI (Swagger) Endpoints Import Button

In the new modal paste OpenAPI specifications in a JSON format. See a sample Swagger specification of a pet store and its sample JSON format by clicking the corresponding link. After pasting the code, you can still update the specifications from here before importing. Use mouse right click to open the context menu and then prettify JSON by clicking Format Document.

OpenAPI (Swagger) Specifications

There are a few available options in order to configure the OpenAPI import approach:

OpenAPI (Swagger) Specifications import options

  1. Make a choice if you want to group your OpenAPI endpoints by URL path with a multiple HTTP methods or else you prefer to have one HTTP method per one URL path.
  2. Import the model definitions from OpenAPI schema as a Response Body with the QuickMocker's suggested shortcodes. This option allows not only importing of the models, but also it will try to guess the most appropriate shortcode for each property value. There are currently 3 methods to detect the correct shortcode and one of it is a simple JSON mapping file which is available for editing through the GitHub. You may create a pull request with your own suggestions and as soon as it is merged, your shortcode suggestions will start to work in QuickMocker app.
    FYI, rhis import option will work only if the Swagger response is referencing a corresponding model definitions. See more details here.
  3. Enable Response Body caching for the endpoints with model definitions reference.
  4. Default Response Content Type - in case for some reason OpenAPI endpoint is missing the "produces" property, the imported endpoint will use the content type defined in this field.
  5. Status Code Detection - decide if you want to use the default successful HTTP method status code (e.g. 200 for GET/PUT, 201 for POST, 204 for DELETE etc) or else the first response status code defined inside the Swagger endpoint.

Preview all of the OpenAPI endpoints you import and their info like URL path, HTTP method, response content type, status code, description and response body when hovering the status code before clicking Complete Import button. Remember, you can still update the JSON specifications above. For a better overview use mouse right click to open context menu and hit Format Document to prettify the JSON content. Additionally fold/unfold properties for a better code editing.

OpenAPI (Swagger) Endpoints Preview


Can I set restrictions for my mock API (IP Address, Authorization Header)?

Yes, you can easily restrict your API endpoints either using IP Address or using Authorization Header.

First of all when you create or edit project, you can define default restriction rules for its future endpoints. See screenshot below:

Configure default restrictions for project

After that, when you create a new endpoint inside the project, by default it will get restriction rules that you've defined in the project earlier. Still, you can easily override them if there's a need. See screenshot below:

Configure restrictions for endpoint

IP Address field can be a comma separated list of IP Addresses (e.g. 192.168.0.1,192.168.0.2) or IP Ranges (e.g. 192.168.0.1/24,167.150.0.1/32) or both. In case IP Address of the client does not match, the response status will be 403 (Forbidden).

Authorization Header field could be set to any text value you wish. If client's authorization header does not match the one you've defined, the response status will be equal to 401 (Unauthorized).

All of the requests that do no pass the restriction rules are still logged in the Requests Log tab of the project and you can easily debug them.


Are there any request / response restrictions?

We have a restriction of characters count for both request / response headers and body. This is a required measure in order to allow proper rendering of the data in the request log record. This is also a precaution from clogging the database. Please remember that you are using a fake API, dummy API or API mock. You are not suppose to send a real heavy data for development and testing purposes. Thank you for the understanding. See the limits below:

Request Headers: 50 000
Request Body: 100 000
You can still send request header/body with more characters, but in this case it will not be saved in the request log record.

Response Headers: 20 000
Response Body: 100 000
Response Body (after shortcodes converted): 200 000 (will not be saved in the request log record)

How to clone/duplicate my endpoint?

If you need to create a copy (duplicate or clone) your mock API endpoint, simply open the kebab menu from the endpoint you want to copy and hit Clone Endpoint button like on the screenshot below:

Clone fake API Endpoint

This will create another copy of the endpoint at the top of the endpoint's list.

How many fake endpoint can I have per project / endpoints collection?

We do not want to limit the number of endpoints per project. So, you may create as much as you want. But currently due to the endpoints managements approach, particularly because of the ability to re-order or prioritize dummy endpoints using simple drag & drop, we have limitted number of the endpoints that can be loaded and viewed on the endpoint's tab up to 100.

All the endpoints that are not loaded into the view are still working, but you are not able to update them or re-order anymore, unless you remove more recent endpoints.

You might ask why? Answering. QuickMocker is just a simple tool for stubbing the API and we assume that 100 of endpoints per one collection of dummy endpoints is more than enough.

You may contact us if for any reason you need to load and view more than 100 items on the project endpoint's tab and we can extend this number personally for you.

What is the correct format of the Endpoint's Request Headers?

First of all, the response headers should be defined as a JSON object inside the endpoint configuration. Secondly, the properties of the JSON object can have a value of a string type or array of strings type. See the sample below with 2 possible header value types:

{
  "Content-Type": "application/json",
  "Set-Cookie": ["foo=bar", "token=test"]
}
    

Finally, the JSON object above will result in the following response headers:

  Content-Type: application/json
  Set-Cookie: foo=bar 
  Set-Cookie: token=test