This message was deleted.

Hi Brian, to answer your questions in turn: • We generate 400 and 422 because there’s an option (currently available via the API only but will be in the UI soon) to require that the main 2xx response requires that the request match the JSON Schema constraints for all declared parameters. Otherwise we fall through to either 400 or 422 depending. I agree that some other status codes can be unreachable or not useful as generated, but with some hand-editing (e.g. to require/avoid a specific auth header value) can be useful to have. • 2xx responses should be higher priority when there’s no JSON schema in • Agree we need a bit more flexibility here, although there is an API-only parameter that’ll flip the relative priorities of 400 and 422 so you can choose which style to go for (some APIs will use 400s for all bad requests, some only when it’s not the request entity that doesn’t match). • You can edit stubs to achieve this behaviour - adding an additional one of a high priority with the header in question would do it. There isn’t a way to make this happen via an OpenAPI import though. • Currently if the context path is present we’ll use it I’m afraid, so if you don’t want it to be included you’d need to remove it from the doc. Check this out for how to enable JSON schema matching for 2xx responses and flipping the 422/400 priority. The first of these might help avoid the situation where your 4xx is getting matched when you want a 2xx: https://github.com/wiremock/wiremock-cloud-postman-collections/blob/main/open-api-import/ImportingFromOpenAPI.postman_collection.json This is an area we’re actively developing at the moment and we know we haven’t got it completely right yet, so we appreciate your detailed feedback. I hope I’ve managed to clarify things a bit here, but I’m happy to discuss this in more detail on Zoom if that would help.