api-console: a RAML and OAS documentation console built as a web component

Two shapes for the same documentation surface

api-console is the open source version of the documentation console that appears inside the Anypoint Platform, and the difference between its two delivery modes explains most of the decisions you will make about it. As a standalone application, exposed through the api-console-app element in api-console-app.js, it brings a title bar, a drawer holding the navigation, and a main element that holds the scrolling region. The body itself is not the scrolling region in that layout. It also supports routing and layout elements, which the element version does not, and it switches to a mobile view when the viewport width threshold of 740px is reached. A wide view kicks in at 1500px or more, and that layout adds the request panel on the right hand side of the currently rendered method. The web component form is the lighter option. It renders the documentation view by default, shows the request panel when the try it button is pressed, and hides the navigation entirely, with no way to open it from the element's own UI. The hosting application has to supply that control.

The console never parses your RAML or OAS file

This is the point that trips up most first attempts. The console does not offer parsing of API files into a data model. That work is done by the AMF parser, a separate MuleSoft project, and the console consumes the result. For both the standalone application and the web component you must set the AMF generated model on the amf property of the console. The source can be the direct result of parsing your specification with the AMF parser, or a JSON+ld model stored in a file, and the documentation states that for performance reasons the stored file is preferred. The wiring looks like this, with the model assigned and the selection reset to the summary view so the console opens on the overview rather than a stale state:

<api-console></api-console>
<script>
{
  const model = await generateApiModel();
  const apic = document.querySelector('api-console');
  apic.amf = model;
  // reset selection
  apic.selectedShape = 'summary';
  apic.selectedShapeType = 'summary';
}
</script>

The two selectedShape properties are what keep the console from opening on whatever resource was last inspected, and setting them after the model is assigned avoids a render against an undefined model.

The request panel needs CodeMirror loaded first

A second constraint shows up the moment someone presses try it. The request panel will not run without its dependencies being present, and the console does not hide that requirement for you. The reason is historical and technical: the code mirror is not ES6 ready, its build contains AMD exports which are incompatible with native modules, so those dependencies cannot be imported with the element and have to sit outside it. The scripts must be ready before the element is initialised, and the project singles out the body and headers editors as the parts that break without them. Read the following into the page ahead of the console element, and the editors will find the language modes they need:

<script src="node_modules/jsonlint/lib/jsonlint.js"></script>
<script src="node_modules/codemirror/lib/codemirror.js"></script>
<script src="node_modules/codemirror/addon/mode/loadmode.js"></script>
<script src="node_modules/codemirror/mode/meta.js"></script>
<!-- Some basic syntax highlighting -->
<script src="node_modules/codemirror/mode/javascript/javascript.js"></script>
<script src="node_modules/codemirror/mode/xml/xml.js"></script>
<script src="node_modules/codemirror/mode/htmlmixed/htmlmixed.js"></script>
<script src="node_modules/codemirror/addon/lint/lint.js"></script>
<script src="node_modules/codemirror/addon/lint/json-lint.js"></script>

The bundler and the CLI tool bundle all of these into a vendor.js file and add it to the final application, so if you use the packaging path this is already handled. If you assemble the page yourself, you may want to add the same dependencies to your build configuration so they end up in the bundle rather than being resolved at runtime.

The language modes are located through a template string, so a request for the xml mode resolves to the xml directory and the xml.js file without every mode being bundled:

<script>
/* global CodeMirror */
CodeMirror.modeURL = 'node_modules/codemirror/mode/%N/%N.js';
</script>

The project notes that this step may be skipped if all possible modes are already included in the application, which is the option to pick when you want to keep the page free of runtime lookups.

Three commands stand up a local console

Previewing the console in your own project starts with the development loop, which the project lays out as three steps. Clone the element, install the dependencies, then start the local server:

git clone https://github.com/mulesoft/api-console.git
cd api-console

npm i

npm start

The server gives you the console running against the demo specifications in the repository. For a shipped application the project steers you away from this path depending on the use case: a standalone application can be built with a CLI tool, with a Docker image, or with a manual rollup build, while the web component form is served by the manual build route alone. The repository root contains index.html and a build-demo.html alongside the demo directory, and the rollup configuration is in rollup.config.js.

Version 6 dropped everything except AMF model version 2

Compatibility is a one-way door in this project. As of version 6.0.0, api-console only works with AMF model version 2, which means an AMF parser of 4.0.0 or newer. Support for previous versions has been dropped, and the documentation states plainly that this is the only version with active development. If you are still on an older parser, the console offers you a downgrade to an earlier release rather than a compatibility shim, and the current line will not pick up new work. The release history also shows a tight cadence around the current point: v6.6.67, v6.6.68 and v6.6.69 were all published on the same day, 2026-08-26, and the last push was on 2026-08-26 as well. Frequent small releases mean you will be picking up patches often, and also that pinning a version is a decision you have to make deliberately rather than by default.

Standalone app brings the auth components, element does not

The two modes differ in more than layout, and the difference matters if you plan to let people send real requests. The standalone application includes the xhr-simple-request, oauth1-authorization and oauth2-authorization components. The API Console element does not include any of those three. They have to be added to the DOM separately, and the project is explicit that you can skip that step when authorization and request events are handled by the hosting application. So the decision is about where your request logic lives. If the console owns the request, you are assembling the auth and request components yourself and wiring events, and the documentation for handling API Console events is referenced from the repository. If the host owns the request, the element stays purely a documentation viewer, which is the lighter integration and the one that avoids a pile of extra scripts. For layout reasons the element form also wants an explicit height, either a specific value or flex: 1 when a flex layout is in use, so that the navigation drawer can be positioned correctly.

Theming runs through CSS variables and Chrome DevTools

Styling is deliberately not a documented configuration surface. The approach is to create a style sheet with CSS variable definitions, and each component that builds the console exposes its own styling API. The gap is that the components ecosystem does not provide detailed documentation for styling, so the recommended method is to open Chrome DevTools, read the name of a variable with its default value, and set that variable in your own style sheet. Example style sheets live in the repository at demo/themed/anypoint-theme.css and demo/themed/dark-theme.css. There is also a compatibility property that switches some components to the Anypoint theme, covering form controls in the request panel, buttons, icon buttons and lists, but the note is important: not all components support the property, so some styling adjustment may still be needed. Expect to budget time for this work rather than assuming a theme file drops in.

Licensing is CPAL-1.0 and the docs live off the repository

The licence field in package.json says CPAL-1.0, while the licence field on the repository is listed as a custom licence that GitHub cannot classify, with the terms in the LICENSE file. That combination is worth reading carefully if you intend to redistribute the console inside a product, because CPAL-1.0 carries distribution obligations that a permissive licence would not. Full usage documentation is not in the repository. The README points to docs.api-console.io for the full documentation, and for building a standalone application it points to three separate routes depending on use case: a CLI tool, a Docker image, or a manual build with rollup. As a web component only the manual build is offered. The repository itself contains a demo directory with standalone, element and themed examples, a docs directory that includes handling-events-in-component.md, and top-level entry files api-console.js and api-console-app.js that are the shipped bundles. A local development loop is three commands, and the last push was on 2026-08-26, so the project is still moving.

Editorial conclusion

api-console is a good fit for a team that already publishes RAML or OAS specifications, generates an AMF model, and wants the same documentation surface the Anypoint Platform uses. It is the wrong tool if you need a tool that reads your specification file directly, because parsing belongs to the separate AMF parser. Before adopting it, confirm you can produce a JSON+ld AMF model, load the CodeMirror and jsonlint scripts before the element initialises, and check that CPAL-1.0 in the package metadata suits your distribution model.

Frequently asked questions

Official sources

1. Issues
2. mulesoft/api-console on GitHub
3. README
4. Releases