Get a Stripe like API experience for your customers in minutes - documentation, rate-limiting and API-key auth with zuplo
Start free
Attributes   |   Methods   |   Events   |   Slots   |   Advanced Styling   |   Vendor Extensions

Attributes

General   |   Colors & Fonts   |   Navigation Bar   |   Layout   |   Sections   |   Schema   |   API Server
General
spec-url url of the OpenAPI spec to view (empty)
update-route Allowed: true | false setting true will update the url on browser's location whenever a new section is visited either by scrolling or clicking true
route-prefix routes for each operation/api is generated based on the api path. however you may add a custom prefix to these routes to support third party routing needs #
sort-tags Allowed: true | false To list tags in alphabetic order, otherwise tags will be ordered based on how it is specified under the tags section in the spec. false
sort-schemas Allowed: true | false To list schemas in alphabetic order, otherwise schemas will be ordered based on how it is specified under the schemas section in the spec. Only has an effect if focused render-style and show-components are applied. false
sort-endpoints-by Allowed: path | method | summary | none Sort endpoints within each tag by path, method or summary. none leaves the sort order unmodified.  |  Example path
heading-text Heading text on top-left corner (empty)
goto-path Initial location on the document (identified by method and path) where you want to go after the spec is loaded.
goto-path should be in the form of {method}-{path}
for instance you want to scrollTo GET /user/login you should provide the location as get-/user/login 		(empty)
fill-request-fields-with-example Allowed: true | false Request fields will be filled with example value (if provided in spec) true
persist-auth Allowed: true | false Authentication will be persisted to localStorage false
UI Colors and Fonts
theme Allowed: light | dark
Is the base theme, which is used for calculating colors for various UI components. 'theme', 'bg-color' and 'text-color' are the base attributes for generating a custom theme 		dark
bg-color Hex color code for main background
Dark Theme
#333
Light Theme
#fff
text-color Hex color code for text
Dark Theme
#bbb
Light Theme
#444
header-color Hex color code for the header's background
#444444
primary-color Hex color code on various controls such as buttons, tabs
#FF791A
load-fonts Allowed:true | false RapiDoc will attempt to load fonts from CDN, if this is not intended, then set this to false. true
regular-font Font name(s) to be used for regular text "Open Sans", Avenir, "Segoe UI", Arial, sans-serif
mono-font Font name(s) to be used for mono-spaced text Monaco, 'Andale Mono', 'Roboto Mono', 'Consolas' monospace
font-size Allowed: default | large | largest
sets the relative font sizes for the entire document  |  Example 		default
css-file
css-classes		 These two attributes go together which helps to inject your own CSS class.
  • create a <link> tag in your html and link to your external css file
  • provide the name of css file in css-file attribute
    and provide names of all the CSS class names that you would like to apply to RapiDoc Element separated by a space in css-classes attribute
Allowed:left-bar | colored-block
show-method-in-nav-bar Allowed: false | as-plain-text | as-colored-text | as-colored-block shows API Method names in the navigation bar (if you customized nav-background make sure there is a proper contrast)  |  Example false
use-path-in-nav-bar Allowed: true | false set true to show API paths in the navigation bar instead of summary/description  |  Example
*If you like to show the API method too in the path you should use show-method-in-nav-bar 		false
nav-bg-color Navigation bar's background color  |  Example
nav-text-color Navigation bar's Text color
nav-hover-bg-color background color of the navigation item on mouse-over
nav-hover-text-color text color of the navigation item on mouse-over
nav-accent-text-color Text color used in navigation bar selected items
on-nav-tag-click Allowed: expand-collapse | show-description - applies only to focused render-style. It determines the behavior of clicking on a Tag in navigation bar. It can either expand-collapse the tag or take you to the tag's description page. expand-collapse
UI Layout & Placement
layout Allowed: row | column Layout helps in placement of request/response sections. In column layout, request & response sections are placed one below the other, In row layout they are placed side by side. This attribute is applicable only when the device width is more than 768px and the render-style is 'view'. row
render-style Allowed: read | view | focused - determines display of api-docs. Currently there are three modes supported.
  • view friendly for quick exploring (expand/collapse the section of your interest)  |  Example
  • read suitable for reading (like a continuous web-page)  |  Example
  • focused similar to read but focuses on a single endpoint at a time (good for large specs)  |  Example
'read' - more suitable for reading 'view' more friendly for quick exploring 		read
response-area-height Allowed: valid css height value such as 400px, 50%, 60vh etc - Use this value to control the height of response textarea 300px
Hide/Show Sections
show-info show/hide the documents info section
Info section contains information about the spec, such as the title and description of the spec, the version, terms of services etc. In certain situation you may not need to show this section. For instance you are embedding this element inside a another help document. Chances are, the help doc may already have this info, in that case you may want to hide this section. 		true
info-description-headings-in-navbar Include headers from info -> description section to the Navigation bar (applies to read mode only)
Will get the headers from the markdown in info - description (h1 and h2) into the menu on the left (in read mode) along with links to them. This option allows users to add navigation bar items using Markdown  |  Example 		false
match-paths If you want to show only few selected APIs based on the target audience, you may use this attribute to define which paths should be rendered. The filter can be a simple substring match for a path or can be a complex regex expression. Wheather to use substring match or regex match is specified through match-type attribute  |  Example (empty)
match-type Allowed: includes | regex - Defines how match-paths is used for filtering includes
remove-endpoints-with-badge-label-as Comma separated badge labels to be removed from the spec.
You may use vendor-extension x-badges to assign badges to endpoints. This attributes helps in removing the endpoints which matches a badge label  |  Example 		includes
show-components show/hide the components section both in document and menu (available only in focused render-style)
Will show the components section containing schemas, responses, examples, requestBodies, headers, securitySchemes, links and callbacks 		false
show-header show/hide the header.
If you do not want your user to open any other api spec, other than the current one, then set this attribute to false		 true
allow-authentication Authentication feature, allows the user to select one of the authentication mechanism thats available in the spec. It can be http-basic, http-bearer or api-key. If you do not want your users to go through the authentication process, instead want them to use a pre-generated api-key then you may hide authentication section by setting this attribute to false and provide the api-key details using various api-key-???? attributes. true
allow-spec-url-load If set to 'false', user will not be able to load any spec url from the UI. true
allow-spec-file-load If set to 'false', user will not be able to load any spec file from the local drive. This attribute is applicable only when the device width is more than 768px, else this feature is not available true
allow-spec-file-download If set to 'true', it provide buttons in the overview section to download the spec or open it in a new tab. false
allow-search Provides quick filtering of API true
allow-advanced-search Provides advanced search functionality, to search through API-paths, API-description, API-parameters and API-Responses  |  Example true
allow-try The 'TRY' feature allows you to make REST calls to the API server. To disable this feature, set it to false.  |  Example true
show-curl-before-try If set to 'true', the cURL snippet is displayed between the request and the response without clicking on TRY  |  Example false
allow-server-selection If set to 'false', user will not be able to see or select API server (Server List will be hidden, however users will be able to see the server url near the 'TRY' button, to know in advance where the TRY will send the request). The URL specified in the server-url attribute will be used if set, else the first server in the API specification file will be used. true
allow-schema-description-expand-toggle Allowed: true | false allow or hide the ability to expand/collapse field descriptions in the schema true
Schema Section Settings
schema-style Allowed: tree | table - Two different ways to display object-schemas in the responses and request bodies  |  Example tree
schema-expand-level Schemas are expanded by default, use this attribute to control how many levels in the schema should be expanded  |  Example 999
schema-description-expanded Allowed: true | false - Constraint and descriptions information of fields in the schema are collapsed to show only the first line. Set it to true if you want them to fully expanded false
schema-hide-read-only Allowed: default | never - default will show read-only schema attributes in Responses, and in Requests of Webhook / Callback
If you do not want to hide read-only fields in schema then you may set it to 'never'
Note:This do not effect example generation.  |  Example 		default
schema-hide-write-only Allowed: default | never - default will show write-only schema attributes in Requests, and in Responses of Webhook / Callback
If you do not want to hide write-only fields in schema then you may set it to 'never'
Note:This do not effect example generation.  |  Example 		default
default-schema-tab Allowed: schema | example - The schemas are displayed in two tabs - Model and Example. This option allows you to pick the default tab that you would like to be active model
API Server & calls
server-url OpenAPI spec has a provision for providing the server url. The UI will list all the server URLs provided in the spec. The user can then select one URL to which he or she intends to send API calls while trying out the apis. However, if you want to provide an API server of your own which is not listed in the spec, you can use this property to provide one. It is helpful in the cases where the same spec is shared between multiple environment say Dev and Test and each have their own API server. (empty)
default-api-server If you have multiple api-server listed in the spec, use this attribute to select the default API server, where all the API calls will goto. This can be changed later from the UI (empty)

When providing API key using RapiDoc element, make sure that you provide all the 3 attributes with some default values api-key-name, api-key-location & api-key-value
Set api-key-value to "-" if you are unsure of its value, and like to fill in later using JavaScript

api-key-name Name of the API key that will be send while trying out the APIs (empty)
api-key-location Allowed: header, query - determines how you want to send the api-key. (empty)
api-key-value Value of the API key that will be send while trying out the APIs. This can also be provided/overwritten from UI. (empty)
fetch-credentials Allowed: omit | same-origin | include enables passing credentials/cookies in cross domain calls, as defined in the Fetch standard, in CORS requests that are sent by the browser (empty)

Methods

Method Description
loadSpec() To programmatically load spec. The method takes
  • either a string containing the url of the specs
  • or a JSON object representing a valid spec
 Example
scrollToPath(path) To programmatically scroll to a section (identified by combination method and path).
path should be provided in the format of {method}-{path} for instance you want to scrollTo GET /user/login you should provide the location as get-/user/login  |  Example
setHttpUserNameAndPassword(
  securitySchemeId,
  username,
  password
) 		To programmatically provide username and password. securitySchemeId should be a valid securityScheme which you have defined in the spec
setApiKey(
  securitySchemeId, token
) 		To programmatically provide api-key. securitySchemeId should be a valid securityScheme which you have defined in the spec
setApiServer(apiServerUrl) To programmatically set API Server. apiServerUrl should be a valid server url which you have defined in the spec 
                
                  <html>
                  ...        
                    <rapi-doc id="the-doc" spec-url = "https://.../spec.yaml"> </rapi-doc>
                    <script>
                      window.addEventListener('DOMContentLoaded', (event) => {
                        const rapidocEl = document.getElementById('the-doc');
                        rapidocEl.addEventListener('spec-loaded', (e) => {
                          rapidocEl.setApiServer(globalThis.origin + "/api");
                          // Sets the server to http://localhost:8080/api
                          // you must have defined this server in your spec
                        });
                      });
                    </script>
                  ...
                  </html>

Events

Below is an example on how to handle events using plain JS 
          
            <html>
            ...        
              <rapi-doc id="the-doc" spec-url = "https://.../spec.yaml"> </rapi-doc>

              <script>
                window.addEventListener('DOMContentLoaded', (event) => {
                  /* 
                    Ensure that the DOM is loaded, then add the event listener.
                    here we are listenig to 'before-try' event which fires when the user clicks 
                    on TRY, it then modifies the POST requests by adding a custom header 
                  */
                  const rapidocEl = document.getElementById('the-doc');
                  rapidocEl.addEventListener('before-try', (e) => {
                    if (e.detail.request.method === 'POST') {
                      e.detail.request.headers.append('custom-token', 'AAA.BBB.CCC');
                    }
                  });
                });
              </script>
            ...
            </html>
Event Description
before-render fired before rendering, provides spec object which can be modified and the changes will be reflected in rendering
spec-loaded fired after the spec is parsed, and rendered. Provides an object representing the spec.
before-try fired before user clicks try. Provides a Request like object that can be modified before making the final call to the API.
Also you get an AbortController object which can be used for aborting a request
Example: To add a custom header before making a try call 
                  
                    rapidocEl.addEventListener('before-try', (e) => {
                      if (e.detail.request.method === 'POST') {
                        e.detail.request.headers.append('my-header', 'XYX');
                      }
                    });

Example: Add a query-string param to all GET request 
                  
                    rapidocEl.addEventListener('before-try', (e) => {
                      if (e.detail.request.method === 'GET') {
                        const url = new URL( e.detail.request.url);
                        url.searchParams.append('delay', '3');
                        e.detail.request.url = url.searchParams.toString();
                      }
                    });

Example: To abort a (Try)request - Below example aborts all DELETE calls 
                  
                    rapidocEl.addEventListener('before-try', (e) => {
                      if (e.detail.request.method === 'DELETE') {
                        e.detail.controller.abort();
                      }
                    });
after-try fired after try (API-call) is completed and provides a request and response object In case of an error it will provide an request and err object
request-aborted fired when user aborts the request
api-server-change fires when you change the API server
Working Example of Event Handling In RapiDoc

Slots

slots are predefined placeholders inside a RapiDoc component. You can use these slots to place your custom html in certain desired locations inside RapiDoc. Below is an example on how to inject HTML/CSS/JS at various locations in RapiDoc 
            
              <html>
                ...
                <rapi-doc spec-url = "https://petstore.swagger.io/v2/swagger.json">
                  <div> <!-- HTML Elements without slot attribute goes into default location-->
                    <h1> My HTML Heading  </h1>
                  </div>

                  <!-- provide slot attribute to place an element at desired location -->
                  <img slot="nav-logo" src="https://via.placeholder.com/100" style="width:50px; height:50px"/>
                 
                </rapi-doc>
                ...
              </html>
Slot Name Description
(default) any content placed inside <rapi-doc> tag, will be shown immediately under the header and above the info section
logo use this slot to replace the logo on the header
header contents appear at the header after the spec-url input
footer contents appear at the bottom of the spec
nav-logo contents appear at the top of Side navigation bar usually used for logo. (only available in read-mode)
overview contents appear at overview section - top of the document. You can link to this section using #overview
servers contents appear at server section which is under the overview slot. You can link to this section using #servers
auth contents appear at authentication section which is under the overview > servers slot. You can link to this section using #auth
operations-top contents appear at the top of all the operations but below overview > servers > auth section. Use this section to provide content that applies to all the operations. You can link this section using #operations-top
tag--{tag-name} each tag is identified by a name, this slot can be used to insert HTML content under various tags
{method}-{path} each path is identified by an id. which is in the format of {method}-{path}, and certain invalid characters such as {, }, #, space is replaced by hyphen (-). Use this slot to insert HTML content into a specifi tag
Example of Slots: All Slots  |  default and footer  |  nav-logo

Advanced Styling

For those who like to perform advanced styling by building RapiDoc from source
Developers can providing their own style overrides in src/styles/custom-styles.js. This is provided as a clean way into add custom style overrides without making changes to the codebase 
                  
                    // src/styles/custom-styles.js

                    import { css } from 'lit';
                    export default css`
                      .tag.title {
                        text-transform: capitalize;
                        border-left: 2px dotted var(--red);
                      }
                    `;
and build RapiDoc 
                  
                    npm run build
generated rapidoc-min.js in dist folder will have your styles

Supported vendor extensions

x-code-sample
x-codeSample 		Use this vendor-extension to provide code samples in various languages Usage Example
x-badges Use this vendor-extension to annotate end-points with short color coded lables. You can also assign badges to endpoints and then use them with remove-endpoints-with-badge-label-as attribute to remove them from your API documentation. This allows you to show the same API spec to different groups of audiences. Like you want to hide internal APIs for your customers but show then to your developers Badge Example
Filter by badge Example
x-tag-expanded Use this vendor-extension to expand or collapse paths under a tag (applies only in view and focused render-style) Usage Example
x-fill-example Allowed: yes | no - Use this vendor-extension for each request parameter to indicate if the provided example is auto populated on the UI
if this behaviour needs to be applied for all the examples then see fill-request-fields-with-example
x-example-show-value Allowed: true | false - Use this vendor-extension for each request parameter to indicate if the provided example is displayed on the UI

x-client-id
x-client-secret
x-default-scopes
x-receive-token-in
x-pkce-only 		Use these vendor-extensions to pre fill
Client ID
Client Secret
Default Scopes
where token is received (header or request-body) in the UI
true|false - when true, client-secret wont be send from UI 		Usage Example
Sample Spec