Response Match Options

The Match Options section determines what requests will match this response. In other words, it decides which requests this response will be executed for.

There are three main match conditions:

1 HTTP Method
2 Operation (URI, SOAP Action, etc.)
3 Script

If any of the conditions are undefined, it is not used in the match.

All defined conditions must be true for the response to match the request.

HTTP Method

To match, the incoming request must use the specified HTTP Method.

Possible HTTP Methods are:

The pseudo-method “Any” matches any HTTP method and effectively disables this check.


The operation is only strictly defined for SOAP requests. For the rest, the name operation is used loosely.

The operation can be one of the few types:

SOAP Action

SOAPAction is a value that is sent with SOAP requests.

MockMotor supports both the SOAPAction HTTP header (SOAP 1.1) and action component of the Content-Type HTTP header (SOAP 1.2).

First Element of XML Payload

For some SOAP services, the action field is not defined or defined as an empty string for all operations. We then cannot use the SOAPAction condition to select a response that fits the operation. However, for such services, the first element under SOAP Body usually has a unique name and we can use this instead.

For example, for this request

<soapenv:Envelope ...>

We can configure the response to match the first element of the payload when it is at SubmitActivity:

Note that SOAP Envelope elements (body, header) are not considered a part of the payload.

The same match will also work for plain XML requests, where the SOAP Envelope doesn’t exist:


Relative URI

Relative URI match is mostly aimed at REST services, though sometimes it can be useful for SOAP or XML services too.

The relative URI is the part of the request URL past the service URL.

For instance, when a request with URL comes to a service with URL, the relative URL is simply products. We can then configure the match like this:

Parameters in the URL

For many REST services the URL contains parameters, such as account ID. MockMotor allows you to specify such parameters using the common {name} notation:

The matched parameters are then placed into the $rest/rest variable and are available to script everywhere in the response. See REST Variable for details.

Not Used

This option effectively disables the match by operation.

Normally, it is only needed in default responses that should match no matter what request has been received. Such default responses use HTTP Method = <Any>, Operation = Not Used and an empty script.


A match by a script allows fine-grained access to any property of the incoming request.

The scripting language can be either Javascript or XQuery, and is configured in the response General Properties. Javascript-based responses can also use JSONPath.

The most common types of match by script include (but are not limited to):

Match by Particular Request Value

Sometimes, we only need to match requests with a particular value in the payload. For instance, we may have different responses for two different consuming applications that are identified by their codes in the request.

Then, we can limit our response to a specific consumer by adding a match by script:


We can use an XQuery expression that resolves into either boolean or into non-empty sequence. For example, the following script checks that the request comes from application named “Online”: $input//*:ApplicationID='Online':

The $input variable contains the request. See Payload Variable for details.


For Javascript, we will have to provide the full path to the value, e.g. input.GetOffers.Header.ApplicationID=='Online'. The expression must resolve into a boolean true to match.


JSONPath is an improvement for Javascript matching. We should only specify the path: $..ApplicationID=='Online'.

Match by HTTP Header

We can match the request based on the request HTTP header (or lack thereof).

For instance, we can simulate HTTP Authentication exchange by rejecting any request that comes in without Authorization HTTP header and send back a HTTP status 401 (Unauthorized):

The headers are provided in the $http (http for Javascript) variable. See HTTP Variable for details.

Match by Query String

A value passed in the URL query string can also be used for a match. The input parameters are parsed into the $http (or http for Javascript) variable. See HTTP Variable for details.

For example, imagine a reporting service where the response format can differ based on the CALL_TYPE parameter:


The response can be configured to match format type 3 with the following expression (for a Javascript-based response):

Match by URL Component

For REST services, a URL component can be a value that needs to be matched against.

Imagine a REST service where the second part of the URL is a form id:


Then, we can match the response by the value that is passed in the URL, e.g. here, we only match if that value is 5099:

Match by Account Value

Sometimes users want to mark accounts as belonging to a specific flow - some responses should only match accounts in one flow.

To achieve this we can match the request by the account values that it would use:

Note that this case is special.

First MockMotor matches the request by the HTTP Method and first element of the payload (GetAccountDetails), i.e. performs the checks in its normal order.

Then, however, it sees that the matching script contains a reference to the account variable $account. To have the value of the $account MockMotor first performs the account selection, finding the account that has the ban property matching the value from the request using the XPath $input//*:BAN.

Only when this account is found and loaded, MockMotor executes the matching script, checking that the account’s property type has the value MobilityOnly.

If the selected account has a different type, the response is considered to be not matching and the next response in the list will be tried.