Hide HTTP Request Maker on OpenAPI powered page?

We’re using Stoplight Next at my company, and I have a problem. Some of our pages are created with the “Embedded” page type and are directly editable, while others are auto-generated from .oas2 Modeling files using the “OpenAPI” page type.

For the “OpenAPI” pages, I’ve noticed there is an HTTP Request Maker block at the bottom of these pages. There doesn’t seem to be anywhere in the .oas2 file to control the configuration of these widgets, compared to when I add them directly as blocks to embedded pages. I’m not even sure I want them to appear here, since we have separate pages for each method that already include this widget.

So my questions are:

  1. Is there a place in the Stoplight Next UI where I can edit how these widgets are configured on “OpenAPI” type pages?
  2. Is there a way to prevent them from appearing on “OpenAPI” type pages?
  3. If there is no way to prevent them from appearing on these type pages, do I just have to convert all my “OpenAPI” type pages to “Embedded” type pages in order to get these widgets removed?

Example of OpenAPI page type:

Example of Embedded page type:

Hey @adoherty, regarding your questions:

Not quite. These are configured automatically by the settings defined in the API specification for the given operation. Are you finding that they don’t accurately reflect the requirements for the operation?

Yes, you can include the following custom CSS in your Hub, which will prevent them from displaying:

.ApiOperation--tryItOutTitle {
  display: none;

.ApiOperation--tryItOut {
  display: none;

This shouldn’t be necessary.

Thanks Ross. Regarding this question:

Yes, in our other HTTP Request Makers we add an “Auth” tab, where users can practice putting in their credentials for Basic Auth or other authentication method. Here is an example:

We are also able to control which body params appear, for example limiting it to required params and optional params that are especially important, and prepopulating those params with values that are optimal for the user to make their test query.

Beyond this, we aren’t even sure we want to continue having these blocks on both guide pages and reference pages (could just be one or the other). But for now we are, and want any blocks that are shown to be optimally configured. If we can’t find a way to configure them, we’ll just use a CSS solution as you suggested and hide the ones on the reference pages.

Thanks @adoherty, I see now. Regarding auth, I believe your API specification is lacking a “Basic” security scheme, which is why the operation-level request makers are not requiring it. Once that is set, users should be prompted for username/password similar to how they are done in the generic request maker.

I see why you prefer the generic request maker, though, as they are a lot more flexible in many ways.