Skip to main content
This guide shows you how to record additional API endpoints into your WireMock Cloud mock APIs using the WireMock Runner deployed in a Kubernetes cluster. You’ll use the Runner’s Record Many Mode to capture real HTTP traffic and automatically create stub mappings.

​
Prerequisites

Before you begin, ensure you have:
  • Completed the Running on Kubernetes guide
  • WireMock Runner deployed and running in your Kubernetes cluster
  • WireMock CLI installed and authenticated
  • Access to the services you want to record (either real APIs or test environments)

​
Set up a development environment

Next we’ll set up a development environment in WireMock Cloud (an environment is a set of mock APIs intended to be used together).

​
Initialise environment and profile

Run the following to create a new environment in WireMock Cloud and also create a new profile, which will be defined in wiremock-development.yaml and maps the local services to the corresponding cloud IDs for the APIs we just created: 
wiremock environments create --profile development
Note the base URLs of the mock APIs from the output - you’ll need these to test your recorded endpoints in WireMock Cloud.

​
Push existing stubs

If you have existing stub mappings in your local .wiremock directory, push them to your development environment: 
wiremock push mock-api --all --profile development
This ensures your development environment starts with the same baseline as your production environment.

​
Set the profile in the Runner

When the Runner starts we need to set it to use the profile we just created, so add the following to the wiremock-runner container envrionment variables in the Kubernetes manifest in wiremock-runner.yaml: 
- name: WMC_RUN_PROFILE
  value: "development"
- name: WMC_RECORD_MANY_PROFILE
  value: "development"
Apply the changes to the Kubernetes cluster: 
./install-wiremock.sh

​
Start Recording

Switch the Runner to record-many mode using the Runner’s admin API: 
curl -X PUT \
  -d '{ "mode": "record-many" }' \
  http://admin.local.wiremock.cloud/v1/mode
The Runner is now proxying requests to the real APIs defined in your .wiremock/wiremock.yaml file and recording the responses.

​
Make requests to record

Make requests to the API endpoints you want to record. The Runner will forward these to the real API and capture both the request and response. For example, to record a GitHub organizations endpoint: 
curl -v http://github.local.wiremock.cloud/organizations
You should see the real response from GitHub, and the Runner will automatically create a stub mapping for this endpoint. Continue making requests to capture all the endpoints you need.

​
Flush recorded stubs

Flush the recorded stubs to ensure they’re saved to WireMock Cloud: 
curl -X POST http://admin.local.wiremock.cloud/v1/record-many/flush
Always flush before stopping recording or switching modes. The Runner does not automatically flush when switching modes, so any unflushed recordings will be lost.

​
Stop recording

Switch the Runner back to serve mode: 
curl -X PUT \
  -d '{ "mode": "serve" }' \
  http://admin.local.wiremock.cloud/v1/mode

​
Test your recorded stubs

​
Test in WireMock Cloud

Use the base URLs you noted earlier to test the recorded endpoints directly in WireMock Cloud: 
curl https://your-development-api.wiremock.cloud/organizations
You should see the recorded response without any request being made to the real GitHub API. You should also see the recorded stubs in the WireMock Cloud UI under the Stubs tab for the GitHub API.

​
Pull changes to your local environment

Pull the newly recorded stubs down into the local project: 
wiremock pull mock-api --all --profile development
This downloads the stub mappings and OpenAPI from the development instance of the GitHub API in Cloud to the local project. Now redeploy to the local Kubernetes cluster: 
./install-wiremock.sh

​
Test in Kubernetes

Test the recorded endpoints again to ensure they’re working correctly: 
curl -v http://github.local.wiremock.cloud/organizations
You should see the recorded response without any request being made to the real GitHub API.

​
Next steps

​
Additional resources