Disclosure: I work on Mockzilla, which competes with WireMock. Everything below was run on my laptop today and every claim links to its source. There is a link to the longer comparison at the end, and you can stop reading before it. You have an OpenAPI document. You want a mock server. WireMock is what most people find first, so you start the container and give it your spec. It will not read it. Two ways it fails Drop the spec where WireMock keeps its stubs and start it: docker run -d -p 8080:8080 -v "$PWD/wiremock:/home/wiremock" wiremock/wiremock:3.13.2 The container comes up. It also loaded nothing: $ curl -s localhost:8080/__admin/mappings | jq .meta { "total": 0 } WireMock reads .json from that directory and ignores everything else, so a .yml spec sits there in silence. Convert it to JSON, which is the obvious next move, and the container stops starting at all: MappingFileException: Error loading file /home/wiremock/./mappings/openapi.json: Unrecognized field "openapi" (class ...StubMappingCollection), not marked as ignorable openapi is an unrecognized field. Why This is not an oversight. OpenAPI import is a WireMock Cloud feature and the open source version has never had it. Somebody asked for it in August 2018, and the answer came the next morning from WireMock's creator: I don't have any plans to open source MockLab's implementation at the moment. I'd suggest if you want to work on this that you make it an extension. MockLab was the earlier name of WireMock Cloud. Eight years on, the feature is still on that side of the line. What you write instead One JSON file per stub, each holding a request matcher and a response. A minimal one for a single endpoint runs about 25 lines, and it covers exactly that endpoint. Ask for the next path along and you get Request was not matched. Twilio Verify is a small API: 29 paths, 53 operations. That is 53 stub files, and every field in them is a response shape you looked up by hand and typed. GitHub's public API description is 551 paths and 845 operations. Then there is the part that shows up later. Your spec and your stubs are now two descriptions of the same API, maintained at different times, and only one of them is what the service implements. Somebody has published a GitHub Action called WireMock OpenAPI Validator whose entire job is checking stub mappings against a spec in CI, and it describes itself as "perfect for ensuring your mocks stay in sync with your API contracts". This is not a bug report WireMock's unit of work is a stub: one matcher, one canned response. A spec is not a stub, so the tool is consistent with what it is. The project is also in good health, with 3.13.2 shipped in November 2025 and v4 in beta. Three things it does that a spec-driven mock does not. WireMock runs inside your test process, in Java and through wrappers in .NET, Python, Go and Rust. You can assert on the requests your code sent, so verify(getRequestedFor(...)) fails the test when the call never happened. And its scenarios move a stub between states, so the same call answers differently the second time. If you need any of those, none of this matters and WireMock is your answer. If you do have a spec The alternative is a server that takes the document as its input, so the mock and the contract are one file. I wrote up the full comparison with both tools running the same API side by side, including the measurements, the per-endpoint cost, and where WireMock still wins: WireMock alternative: mock an OpenAPI spec without writing stubs