Skip to main content
The WireMock CLI accepts a configuration file to control how stubs are recorded: 
wiremock record http://private-endpoint --import-config-file=<path>
Or for multi-domain recording: 
wiremock record-many --import-config-file=<path>
By default recording produces a stub that matches on the specific method and full path and query of each request. The config file can specify any number of rules for generating more or less specific matching criteria: 
import:
  stubTemplateTransformationRules:
  - filter: {}
    template: {}
Each rule has two elements:
  1. a filter which controls whether the rule is applied to the generated stub. This is optional - if omitted the template will always be applied.
  2. a template which generates request matchers to apply to the stub
The rules are additive - all the rules which have a filter which matches the recorded request will be used to generate matchers, which will be added in turn to the generated stub. When more than one rule could both match and specify different matchers for the same element (for instance the first specifies that the Content-Type header is equalTo "application/json", and the second that the Content-Type header contains "json"), the last defined rule will win. Finally a check is made that the generated stub would still match the recorded request from which it was generated. If it would not the entire stub is discarded and no stub is generated at all for that request.

​
Templating

Where matchers have a right hand side the {{ recordedValue }} macro may be used to capture what that value had on the recorded request. For instance, the following rule: 
"$schema": import-config-file-schema.json
import:
  stubTemplateTransformationRules:
  - filter:
      request:
        headers:
          Security-Context:
            matchesJsonPath: "$.userId"
    template:
      request:
        headers:
          Security-Context:
            matchesJsonPath:
              expression: "$.userId"
              equalTo: "{{ recordedValue }}"
when matched against this request:
request
GET /
Security-Context: { "userId": "usr_123" }
would produce a stub mapping with the following request matcher: 
{
  "request": {
    "method": "GET",
    "url": "/",
    "headers": {
      "Security-Context": {
        "matchesJsonPath": {
          "expression": "$.userId",
          "equalTo": "usr_123"
        }
      }
    }
  }
}
This would allow recording different stubs for requests made by different users.

​
Limitations

  1. At present no logic other than replacement of the {{ recordedValue }} macro can be applied in the template, though request matchers can be hard coded.
  2. The {{ recordedValue }} macro cannot currently be used in an equalToJson, equalToXml or matching request matcher.
  3. The filter only contains a request matcher - it is not yet possible to apply rules conditionally based on the response.
  4. The template only contains a request matcher - it is not yet possible to define changes to the response definition in these rules.

​
Reference

The format of the import config file is defined by the import-config-file-schema JSON schema.
⌘I