# APIMatic Docs — Full Content
> Full markdown source for every page on https://docs.apimatic.io, concatenated in sidebar order. Sectioned by '---' separators with each page's source URL above its title.
Curated index: https://docs.apimatic.io/llms.txt
---
# Introduction
Source: https://docs.apimatic.io/
import { Rocket, CodeXml, BookOpenText, SquareDashedMousePointer, Terminal, SquareTerminal, ArrowRightLeft, Puzzle } from 'lucide-react';
APIMatic helps you **create the best Developer Experience for your API**. With APIMatic, you can generate beautifully documented SDKs, spin up API Documentation Portals, lint your API Definitions and convert them into other formats.
### Context Plugins
AI coding agents fail at API integrations because they lack accurate, up-to-date API context. APIMatic context plugins fix this by giving agents version-aware access to your SDK, code samples, and integration workflows, directly in the developer's IDE.
### API Governance and Transformation
The quality of auto-generated SDKs and Documentation heavily relies on good quality API Definitions. Use APIMatic's API Governance tools to ensure that your API definitions are optimized for SDKs and Docs generation.
### Quick Links
** - [Customizing SDKs](generate-sdks/overview-sdks.md#customize-your-sdk)**
** - [Merging multiple API Definitions](manage-apis/api-merging.md)**
** - [API Recipes ↗](pathname:///platform-api/#/http/guides/generating-on-prem-api-portal/guided-walkthroughs)**
** - [API Copilot](changelog/introducing-api-copilot)**
---
# Quickstart
Source: https://docs.apimatic.io/cli-getting-started/portal-quickstart-dac/
This quickstart guide will help you swiftly set up a customizable API Documentation Portal for your APIs using the APIMatic Command Line Interface (CLI).
By the end of this guide, you'll have created a fully functional API Documentation Portal with:
* Interactive API reference documentation
* Live API playground for testing API Endpoints
* Multi-language SDKs with ready-to-use code samples
* Language-specific getting started guides
**Time required:** ~5 minutes
Lets get started!
## Setup
### 1. Install the APIMatic CLI
Before you begin, ensure you have Node.js ( **>= v20**) and npm installed.
You can quickly check by running `node -v` and `npm -v` in your terminal.
To install the [APIMatic CLI](https://www.npmjs.com/package/@apimatic/cli), open your terminal or command prompt and run the following command:
```bash
npm install -g @apimatic/cli
```
If you encounter any issues during installation, ensure Node.js is properly installed and up-to-date.
**Verify installation:**
```bash
apimatic --version
# Expected output:
@apimatic/cli/1.1.0 [platform] [node version]
# Note: The installed CLI version number may be different in your case.
```
✅ **Success**: CLI is installed and ready to use!
### 2. Login
Authenticate with your APIMatic account:
```bash
apimatic auth login
```
Follow the browser redirection to:
1. Enter your APIMatic email address
2. Enter your password
3. Click sign in
#### Verify Login:
```bash
apimatic auth status
#Expected output:
┌ Status
│
◇ Retrieved subscription info
│
● Account Information:
│ Email: 'user@apimatic.io'
│ Allowed Languages: 'csharp', 'go', 'java', 'php', 'python', 'ruby', 'typescript'
│
└ Succeeded
```
✅ **Success**: You're authenticated and ready to use APIMatic CLI!
### 3. Run Quickstart
It's recommended to start your project in a new, empty directory. Create a new directory and navigate into it.
```bash
mkdir hello-apimatic
cd hello-apimatic
```
Then, create your first API portal or SDK using the interactive quickstart:
```bash
apimatic quickstart
```
To get started with an API portal, select the `API Documentation Portal` option:
```bash
● Welcome to the APIMatic quickstart wizard.
│
│ This wizard will guide you through creating your first SDK or API Documentation Portal in just four easy steps.
│ Let's get started!
│
◆ What would you like to create?
│ ● API Documentation Portal (Generate API docs + SDKs)
│ ○ SDK
```
The interactive wizard will walk you through:
* Importing your API definition.
* Selecting the SDK languages you want to generate.
* Setting up the basic project scaffolding for your portal.
* Generating the API Portal files.
* Finally, starting a local development server to preview your portal.
**Expected Final Output:**
```bash
◇ Portal generated successfully.
│
● Portal artifacts can be found at 'C:\portal'.
│
│ The portal is running at http://localhost:3000
│
│ Press CTRL+C to stop the server.
│
◇ Next steps ─────────────────────────────────────────────────────────╮
│ │
│ Use the API Playground or an SDK to call your API. │
│ Customize the Portal theme, add API recipes and enable AI features │
│ https://docs.apimatic.io/cli-getting-started/advanced-portal-setup │
│ │
├──────────────────────────────────────────────────────────────────────╯
```
✅ **Success**: Your API portal is running locally!
Your browser should open automatically and display the created Portal.
:::info
If you encounter any issues during this process, reach out to our [support team](https://www.apimatic.io/contact) for assistance.
:::
### What's Next?
Time to see what your API portal can do!
1. **Explore the API reference** - Browse the auto-generated endpoints and models to see how your OpenAPI definition translates into documentation.
2. **Test the API playground** - Provide your authentication details and input parameters to make live API calls directly from the browser.
3. **Try out an SDK** - Download an SDK, follow the setup instructions in the Getting Started guide, and use the provided code samples to make your first API call.
Your API portal is running on a local server. If you terminate this live server, you can restart it by navigating to your project directory and running the following command:
```bash
apimatic portal serve
```
### Continue your API Portal journey
Now that you have a basic API Portal set up, you can continue to enhance it in the next guide on [Customizing your API Portal](advanced-portal-setup.md).
---
# Customize your API Portal
Source: https://docs.apimatic.io/cli-getting-started/advanced-portal-setup/
Great job completing the quickstart! You now have a functional API Portal with auto-generated documentation. But the real magic happens when you customize it to match your brand, add helpful content, and unlock advanced features that will make developers (and AI Agents) love your API.
This guide will walk you through some essential customizations that will elevate your API Portal from functional to exceptional.
:::note
If you haven't created an API Portal yet, please refer to the [Quickstart](portal-quickstart-dac.md) guide.
:::
### What You'll Accomplish
In the next **15 minutes**, you'll learn how to:
- [**Enrich your content**](#1-add-a-documentation-page-to-the-api-portal) by adding custom documentation pages that provide context beyond your API reference
- [**Guide developers through complex workflows**](#2-add-a-recipe-to-the-api-portal) using interactive API recipes
- [**Match your brand**](#3-customize-the-api-portal-theme-and-layout) with custom themes and colors that reflect your company's identity
- [**Make you Documentation AI-accessible**](#4-generate-an-llmstxt-file) by generating LLMs.txt files
- [**Enable an AI assistant**](#5-enable-api-copilot) to answer Developer questions about your API
- [**Drive more traffic to your Portal by optimizing it for search engines**](#6-enable-seo-optimization) that help Developers find your APIs
### Before you begin
- All commands in this guide should be run from your **project root directory** (the directory containing your `APIMATIC-BUILD.json` file).
Make sure you're in the correct location before starting:
```bash
cd your-project-name/src
ls # You should see the directory structure, including the APIMATIC-BUILD.json file
```
- Each section builds upon the previous one, but you can also jump to specific customizations based on your immediate needs.
Let's get started!
## 1. Add a Documentation page to the API Portal
Enhance your API Portal with a custom documentation page. Custom documentation pages allow you to add product guides, FAQs or any other relevant documentation to your API Portal.
1. **Navigate to the content/guides directory in your project source directory:**
```bash
cd content/guides
```
2. **Create a new markdown file:**
Create a new markdown file and open it in your favourite text editor
```bash
touch my-first-guide.md
code my-first-guide.md
```
3. **Add content to your markdown page:**
```
# Ode to an API
In realms where data flows like streams, APIs fulfill developers’ dreams. A JSON handshake, crisp and clean, Connects the apps behind the screen.
With endpoints nested deep and wide, They summon structs with practiced pride. Auth tokens guard the sacred gate, While headers speak of client state.
A GET for facts, a POST to send, A PATCH to fix, a DELETE to end. With Swagger scrolls and OpenAPI, They whisper truth to SDKs nigh.
So raise a curl to RESTful peers, To webhooks pinging through the years— For every call that we compose, An interface of prose arose.
```
4. **Update your API Portal navigation:**
The new page you created needs to be added to the API Portal’s side-nav. This can be done by running the `portal toc new` command. This command overwrites your existing `toc.yml` file; any changes made to your project directory are reflected in the updated file.
**Tip:** Keep your live preview running (`portal serve`) in one terminal and run this command in a new terminal window. Your changes will appear automatically in your live preview!
```bash
apimatic portal toc new
```
**Expected output**
```bash
┌ New TOC
│
◇ The destination file 'C:\src\content\toc.yml' already exists, do you
want to overwrite it?
│ Yes
│
● The TOC file successfully created at: 'C:\src\content\toc.yml'
│
└ Succeeded
```
5. **View your new page:**
Start your local development server by running the following command, and then look for the page you just added in the Portal’s Side Navigation:
```bash
apimatic portal serve
```
✅ **Success**: Your custom page is now part of your API Portal!
## 2. Add a Recipe to the API Portal
API Recipes are interactive tutorials that help developers learn about and try complex API workflows.
[See how Verizon deploys](https://www.verizon.com/business/5g-edge-portal/api-documentation.html#/http/guided-walkthroughs/iot-how-to-s/guided-walkthroughs/how-to-activate-a-device) API Recipes to help Developers learn about 5G APIs
Create and add your first API recipe to the API Portal using the API Recipe creation wizard. The API Recipe wizard will guide you through:
1. **Recipe Setup:** Create a recipe and add it to the API Portal
2. **Step Configuration:** Add steps to demonstrate an API workflow.
```bash
apimatic portal recipe new
```
**Expected output**
```bash
┌ New Recipe
│
◇ Welcome to the API Recipe Generation Wizard.
│
● This wizard will guide you through the process of creating an API Recipe.
│
│ An API Recipe is a collection of steps that allows you to define a single use case for your API Documentation portal.
│ Learn more: https://docs.apimatic.io/platform-api/#/http/guides/generating-on-prem-api-portal/api-recipes
│
│ Let's get started!
│
◇ Enter a name for your API Recipe:
│ User Authentication Flow
│
◇ Add Steps to your API Recipe:
│
│ You can add:
│ 1. Content Step: Display custom content, such as instructions or information related to your API.
│ 2. Endpoint Step: Display an API endpoint, its playground and other relevant details.
│ Steps appear in the order you add them.
│ Let's proceed to adding steps to your API Recipe.
│
◇ Select the type of step you want to add:
│ Endpoint Step
│
◇ Enter a name for the step:
│ Step 1
│
◇ Endpoints extracted
│
◇ Select the endpoint group name:
│ user
│
◇ Select the name of the endpoint:
│ loginUser
│
◇ Enter a description for the endpoint:
│ Log into the system.
│
◇ Step has been added successfully.
│
◇ Do you want to add another step?
│ No
│
● A new API Recipe has been created successfully.
│
● You can edit the following files to customize your API Recipe:
│ └─ src
│ ├─ content
│ | └─ toc.yml # Contains the API Recipes group with a new page for your API recipe
│ └─ static
│ └─ scripts
│ └─ recipes
│ └─ UserAuthenticationFlow.js # Generated recipe script file containing all of the steps
│
│
◇ Next Steps ───────────────────────────────────────────────────────────────────╮
│ │
│ Run the command 'apimatic portal serve' to preview your documentation portal │
│ │
├────────────────────────────────────────────────────────────────────────────────╯
│
└ Succeeded
```
**View your new recipe:**
Start your local development server by running the following command, and then look for the recipe you just added in the Portal’s Side Navigation:
```bash
apimatic portal serve
```
Your API Portal now includes a foundational API Recipe. However, API recipes offer more extensive capabilities, such as the ability to transfer data between steps and to set default values for individual steps. Taking advantage of these advanced features will require you to write some basic JavaScript code; consult the [API Recipes documentation](https://docs.apimatic.io/platform-api/#/http/guides/generating-on-prem-api-portal/api-recipes) to learn more.
✅ **Success**: Your API recipe is now available to guide developers!
## 3. Customize the API Portal Theme and Layout
Make your API Portal match your company’s brand identity:
1. **Open the `APIMATIC-BUILD.json` file in a code editor.**
2. **Add the following `colors` configuration to the end of the `portalSettings.theme` object**
```json
"colors": {
"primaryColor": { "light": "#400072", "dark": "#D8A3FF" },
"secondaryColor": { "light": "#CAF55C", "dark": "#CAF55C" },
"linkColor": { "light": "#8C21DF", "dark": "#CAF55C" }
}
```
3. **Preview your API Portal**
To preview your updated API Portal, ensure your development server is running. If it's not, start it by executing the following command:
```bash
apimatic portal serve
```
**Theme Updates Explained**
The theme object you added has customized your API Portal with the following changes:
* The primary color is set to "#400072" in light mode and "#D8A3FF" in dark mode.
* The secondary color is "#CAF55C" in both light and dark modes.
* The link color is "#8C21DF" in light mode and "#CAF55C" in dark mode.
APIMatic offers extensive theme and page layout customization options for your Portal, beyond these basic customizations. For more details, refer to APIMatic's documentation on [Theme](https://docs.apimatic.io/platform-api/#/http/guides/generating-on-prem-api-portal/build-file-reference/generateportal-portalsettings-theme) and [Layout](https://docs.apimatic.io/platform-api/#/http/guides/generating-on-prem-api-portal/build-file-reference/generateportal-portalsettings-theme-layout) configurations.
✅ **Success**: Your API Portal looks sleek!
## 4. Generate an LLMs.txt file
LLMs.txt is a new web standard that makes your documentation AI-accessible. It enables tools like Cursor, GitHub Copilot, ChatGPT, and Claude to quickly understand your documentation.
1. **Open the `APIMATIC-BUILD.json` file in a code editor.**
2. **Update your build configuration:**
Add the following configuration to the end of the `generatePortal` object in your `APIMATIC-BUILD.json` file.
**Note:** The `baseUrl` should match where your portal is running locally. If you're using the default `portal serve` command, this will be `http://localhost:3000`.
```json
"baseUrl": "http://localhost:3000",
"llmsContextGeneration": {
"enable": true
}
```
**Understanding LLMs.txt Files**
After adding the above configurations, your API Portal will generate two files:
* **llms.txt**: This is a small, summary-focused index file that provides a structured overview of the content of your API Portal.
* **llms-full.txt**: This is a much larger, comprehensive file that includes the full content of your API Portal in one consolidated markdown file.
You can learn more about LLMs.txt files [here](https://llmstxt.org/).
**View your LLMs.txt Files**
To preview the newly generated files, ensure your development server is running. If it's not, start it by executing the following command:
```bash
apimatic portal serve
```
Next, navigate to the `/llms.txt` path of your API Portal to view the llms.txt file and the `/llms-full.txt` path to view the llms-full.txt file, for instance ,`http://localhost:3000/llms-full.txt.`
✅ **Success**: Your API Portal is now AI-accessible!
## 5. Enable API Copilot
Add an AI-powered assistant to help developers learn and integrate with your API. API Copilot provides instant answers to questions about your API directly within your documentation portal.
**Configure API Copilot**
Run the copilot configuration command to select and set up your AI assistant:
```bash
apimatic portal copilot
```
**Expected output**
```bash
┌ Configure API Copilot
│
◇ Subscription info retrieved
│
◇ API Copilot can only be active on one Portal at a time. Configuring it on this Portal will disable it on any previously
configured Portal.
Do you want to use this key: '967a9070--aaaa-cccc-bbbb-9e3b140c6307'?
│ Yes
│
◇ Opening markdown editor for you to enter welcome message in...
│
● API Copilot configured successfully!
│
│ Copilot ID: '967a9070--aaaa-cccc-bbbb-9e3b140c6307'
│ Status: 'Enabled'
│
│ Configuration saved to: 'APIMATIC-BUILD.json'
│
◇ Next Steps ────────────────────────────────────────────────────────────────╮
│ │
│ API Copilot will index your content the next time you run │
│ 'apimatic portal generate' or 'apimatic portal serve'. │
│ This process can take up to 10 minutes, depending on your API’s size. │
│ │
│ To see your copilot: If your portal is already running, refresh the page. │
│ Otherwise, run 'apimatic portal serve', │
│ select any programming language in the Portal and │
│ look for the chat icon in the bottom-right corner. │
│ │
├─────────────────────────────────────────────────────────────────────────────╯
│
└ Succeeded
```
**Understanding API Copilot**
After running the configuration command, your `APIMATIC-BUILD.json` file will be updated with copilot settings that enable:
- **Contextual AI assistance:** API Copilot learns from your API specification and documentation to provide accurate answers
- **Interactive developer support:** API Copilot appears as a chat interface within your API Portal, allowing developers to ask questions directly without leaving the documentation.
**View your API Copilot**
Start your local development server to see the copilot in action:
```bash
apimatic portal serve
```
Look for the chat interface in the bottom-right corner of your API Portal. Click it to interact with your new AI assistant!
You can learn more about the API Copilot in our [documentation](/changelog/introducing-api-copilot/).
✅ **Success**: Your API Portal now includes an AI-powered assistant to answer Developer questions!
## 6. Enable SEO optimization
The default API Portal is a Single-Page Application (SPA). SPAs aren't SEO-friendly but more straightforward to deploy and less prone to deployment mistakes.
APIMatic supports generating an SEO-friendly API Documentation Portal with a few changes to the Build file and support from the server-side.
To optimize your Portal for search engines, add the following configuration to the end of the `generatePortal` object in your `APIMATIC-BUILD.json` file:
```json
"indexable": {}
```
If you followed along with the steps in the previous section to generate an llms.txt file, your `generatePortal` object should already contain a `baseUrl` property. If it doesn't already exist, you will need to add it as well.
**Note:** The `baseUrl` should match where your portal is running locally. If you're using the default `portal serve` command, this will be `http://localhost:3000`.
```json
"baseUrl": "http://localhost:3000"
```
This is what your `generatePortal` configuration should look like now:
```json
{
"generatePortal": {
.
.
.
"baseUrl": "http://localhost:3000",
"indexable": {}
}
}
```
**View your SEO-enabled API Portal**
Start your local development server to see your SEO-enabled Portal:
```bash
apimatic portal serve
```
**SEO optimizations explained**
Enabling SEO for an APIMatic API Portal:
* Generates HTML files for all pages with correct `` and canonical tags.
* Ensures that the API Portal uses HTML History API for crawler-friendly routing.
* Generates a Meta redirect HTML file for redirects.
* Generates a `_redirect` file for all necessary redirects.
* Generates a sitemap.xml for page discovery.
* Generates a 404.html to prevent SPA misidentification.
* Generates a customizable robots.txt to guide crawlers.
Learn more about APIMatic’s support for SEO optimization [here](pathname:///platform-api#/http/guides/generating-on-prem-api-portal/build-file-reference/search-engine-optimization).
✅ **Success**: Your API Portal is optimized for search engines!
## What's Next?
::::info See Your API's Full Potential–Request a Free Custom Demo!
Here's what we're offering you, completely free:
- A **personalized demo** showcasing the full platform capabilities
- A custom **proof of concept** built with your actual API specification
- **Expert consultation** on optimizing your developer experience strategy
- **Zero commitment** required–seriously, no strings attached!
Our team has helped companies like PayPal, Verizon, and hundreds of others transform their API programs. We'd love to show you what's possible for your APIs too.
🎯 [Get Your Free Custom Demo & POC →](https://www.apimatic.io/contact)
::::
### Learn more about the API Portal
Ready to go deeper? Explore these advanced topics:
- [Add a Custom header and footer to your API Portal](pathname:///platform-api/#/http/guides/generating-on-prem-api-portal/header-and-footer-customization/)
- [Inject Authentication information](pathname:///platform-api/#/http/guides/generating-on-prem-api-portal/dynamic-configurations/)
- [Implement RBAC](pathname:///platform-api/#/http/guides/generating-on-prem-api-portal/filtering-api-by-roles/)
- [Automate deployments via CI/CD Pipelines](/docs-as-code/automate-api-portal-generation-via-apimatic-docs-as-code.md)
---
# Specifying API Metadata
Source: https://docs.apimatic.io/manage-apis/apimatic-metadata/
You can import or transform your API definition along with a metadata file that will allow you to configure certain processes in APIMatic as well as help override or filter out certain parts of the API definition without requiring any change in the input API specification itself.
## What Can You Achieve With a Metadata File?
A metadata file provides the following capabilities:
- Settings to help [configure various processes](#configuring-apimatic-processes-with-metadata) an API definition goes through, in order to get desired results. For example, the metadata file provides settings that helps you configure transformation, import, export, merging, code generation etc.
- Options to [filter out parts of the API definition](#filtering-out-parts-of-api-definition-with-metadata) without needing to change the original API specification document. For example, you can remove internal endpoints of your API definition and related data.
- Ability to [override parts of the API definition](#overriding-parts-of-api-definition-with-metadata) with information provided in the APIMatic metadata file. For example, you can override the default authentication settings of your API.
## How to Provide a Metadata File?
- You can provide this file along with your API definition during [import](/web-dashboard-retired) through [APIMatic Dashboard](https://app.apimatic.io/dashboard) or when [converting APIs](/api-transformer/overview-transformer) through the Transformer.
- The metadata file must be a valid **JSON** file and the file name MUST start with **"APIMATIC-META"**.
- The API definition must be provided in the form of a **ZIP** file that contains both the API specification document (for example, OpenAPI) and the metadata file. Within the ZIP file, the metadata file **must exist at the same level as that of the API definition**. It shouldn't be nested at a different level.
## Metadata - An Example
Here is an example directory structure where `spec.json` is the API specification document that needs to be imported/transformed. The metadata file named `APIMATIC-META.json` is placed at the same level as the API specification document and in the same directory.
```
dir\
spec.json
APIMATIC-META.json
```
A sample of a metadata file `APIMATIC-META.json` is given below:
```json
{
"MergeConfiguration": {
"MergeApis": false
},
"ImportSettings": {
"PreferJsonSchemaNameOverTitle": true,
"AppendParentNameForClashes": false,
"AutoGenerateTestCases": true,
"PreferSwaggerOperationSummaryOverId": false
},
"ExportSettings": {
"ExportExtensions": false,
"UseDateTimeOnlyInRaml": false,
"AddRefSiblingDataInAllOfSchema": false,
"EncodeUrlParamsInPostman": true
},
"ServerConfiguration": {
"DefaultEnvironment": "production",
"DefaultServer": "default",
"Environments": [
{
"Name": "production",
"Servers": [
{
"Name": "default",
"Url": "http://example.com"
}
]
}
],
"Parameters": []
},
"TestGenSettings": {
"Configuration": {},
"TestTimeout": 30,
"PrecisionDelta": 0.01
},
"CodeGenSettings": {
"SynchronyMode": "Asynchronous",
"ModelSerializationScheme": "Json",
"ArraySerialization": "Indexed",
"Nullify404": true
}
}
```
## Configuring APIMatic Processes With Metadata
Using the APIMatic metadata file, you can configure the following processes in APIMatic in order to get the output that best suits your needs:
- The API definition import process can be [configured using import settings](/web-dashboard-retired).
- The API definition export process can be [configured using export settings](/web-dashboard-retired).
- The API definition validation process can be [configured using a validation configuration](/validate-lint-apis/configuring-validation).
- Merging of multiple API definitions can be enabled and [configured using a merge configuration and related settings](/manage-apis/api-merging/#configuring-the-merge-process).
- The API definition transformation process can be configured using a mix of the above mentioned settings as documented [here](/api-transformer/configuring-transformer/).
- The code generation process used for generating client SDKs from API definitions can be [configured using Code Generation settings](/generate-sdks/customize-sdks/codegen-settings/codegen-settings-overview/).
- The test case generation process during code generation can be configured using the [Test Case Generation settings](/testing/configure-test-case-generation/).
## Filtering Out Parts of API Definition With Metadata
The metadata offers the ability to filter out endpoints and their related data in an API definition on the basis of **tags**. Additionally, you can filter individual schema properties and parameters within your API specification. Depending on the API specification format, tags can be specified for endpoints, properties, and parameters in different ways, which is discussed in the sections below. Filtering this way can be useful for removal of any private or internal elements that are part of your API specification document but you don't want to import.
During filtering, when endpoints are removed any redundant model definitions and authentication configurations tied only to those endpoints will also be removed. The filtering options available are described below:
### Endpoint Level Filtering
| Property | Type | Details |
| -------- | ---- | ------- |
| `KeepEndpointsWithTags` | Array[String] | When this setting is used only the endpoints in an API definition that contain these tags will be kept while all others will be removed. If `RemoveEndpointsWithTags` is also used, then the removal of endpoints with tags specified in `RemoveEndpointsWithTags` takes place first while the filtering with current tags configuration applies later. |
| `RemoveEndpointsWithTags` | Array[String] | When this setting is used, all endpoints with the tags specified in this list are removed while others remain unaffected. If `KeepEndpointsWithTags` is also used, the endpoints with tags specified in the current tags configuration will be removed first and then the filtering on the basis of tags configuration in `KeepEndpointsWithTags` will take effect. |
| `MaximumAllowedEndpoints` | Integer | This will help remove any endpoints that fall above the maximum threshold specified using this setting. This type of filtering will be applied after any tags-specific filtering performed using `KeepEndpointsWithTags` or `RemoveEndpointsWithTags`. |
### Property and Parameter Level Filtering
| Property | Type | Details |
| -------- | ---- | ------- |
| `RemoveSchemaPropertiesWithTags` | Array[String] | When this setting is used, all schema properties with the tags specified in this list are removed from the API definition. If removing properties leaves behind orphaned schemas, those schemas are automatically removed as well. By default, examples are also updated to remove references to the filtered properties across endpoint-level examples, custom type examples, and child schemas that inherit from filtered parent schemas. |
| `RemoveParametersWithTags` | Array[String] | When this setting is used, all parameters (path, query, header, and cookie) with the tags specified in this list are removed from the API definition. If removing parameters leaves behind orphaned schemas, those schemas are automatically removed as well. |
:::caution
Use the `RemoveSchemaPropertiesWithTags` setting with caution as it involves significant risks. This feature removes properties at the schema level throughout your API specification and can have wide-ranging effects, including impacts to generated SDKs, documentation, schema validation, schema relationships, examples, and API contracts.
**[View Associated Risks and Impacts](#associated-risks-and-impacts)**
:::
### Configuring Endpoint Level Tags In Your API Specification Document
Tags can be specified for OpenAPI and RAML files as shown below:
#### OpenAPI (v2.0, v3.x)
OpenAPI offers grouping operations (or endpoints) using tags natively using the `tags` property:
```yml
/pets:
get:
operationId: listPets
tags:
- pets
```
#### RAML (v1.0)
For RAML, we [offer annotations to help specify tags at method level](/specification-extensions/raml-apimatic-annotations/#annotation-for-method-level-tags):
```yml
/pet:
get:
(x-tags):
- pets
displayName: List pets
```
### Configuring Property and Parameter Level Tags In Your API Specification Document
For more granular filtering, you can tag individual properties within schemas and parameters using the `x-tags` extension field.
#### Tagging Schema Properties
Use the `x-tags` field to associate tags with properties in your schema definitions:
```yml
DeviceInfo:
type: object
properties:
id:
type: string
x-tags: ["schema1"]
name:
type: string
x-tags: ["beta", "internal"]
status:
type: string
```
#### Tagging Parameters
Similarly, add `x-tags` to parameters at the endpoint level:
```yml
parameters:
- name: deviceId
in: path
required: true
schema:
type: string
x-tags: ["schema1"]
example: "device-123"
- name: apiVersion
in: query
required: false
schema:
type: string
x-tags: ["beta"]
example: "v2"
```
### Example Usage
#### Endpoint Level Filtering
Let's say you have two endpoints in your OpenAPI file. The first endpoint `listPets` has two tags `pets` and `private` specified while the second endpoint `listCatalogItems` has two tags `pets` and `public` specified:
```yml
/pets:
get:
operationId: listPets
tags:
- pets
- private
..........
/pets/catalog/entries:
get:
operationId: listCatalogItems
tags:
- pets
- public
..........
```
If you decide to keep endpoints with tag `pets`, upon API filtering both endpoints will be preserved since they both contain `pets` as their tag:
```json
{
"KeepEndpointsWithTags": ["pets"]
}
```
If you decide to remove the internal endpoints with tag `private`, upon API filtering only the first endpoint `listPets` and its related schema definitions will be removed while the information related to the second endpoint `listCatalogItems` will be preserved.
```json
{
"RemoveEndpointsWithTags": ["private"]
}
```
If you use both settings together as shown below, endpoints with the tag `private` and their related information will be removed first, and the remaining endpoints with the tag `pets` will be preserved. In the end, you'll be left with only one endpoint: `listCatalogItems`.
```json
{
"KeepEndpointsWithTags": ["pets"],
"RemoveEndpointsWithTags": ["private"]
}
```
#### Property and Parameter Level Filtering
Let's say you have a schema definition with tagged properties:
```yml
DeviceInfo:
type: object
properties:
id:
type: string
x-tags: ["public"]
name:
type: string
x-tags: ["beta"]
internalId:
type: string
x-tags: ["internal"]
status:
type: string
```
And an endpoint with tagged parameters:
```yml
/devices/{deviceId}:
get:
parameters:
- name: deviceId
in: path
required: true
schema:
type: string
x-tags: ["public"]
- name: debugMode
in: query
schema:
type: boolean
x-tags: ["internal"]
```
If you want to remove all internal and beta properties/parameters from your API definition:
```json
{
"RemoveSchemaPropertiesWithTags": ["beta", "internal"],
"RemoveParametersWithTags": ["internal"]
}
```
After filtering:
- The `name` and `internalId` properties will be removed from the `DeviceInfo` schema
- The `debugMode` parameter will be removed from the endpoint
- Only the `id` and `status` properties will remain in `DeviceInfo`
- Only the `deviceId` parameter will remain in the endpoint
- All examples referencing the removed **properties** (`name` and `internalId`) will be automatically cleaned up
#### Combining Endpoint and Property Level Filtering
You can use both endpoint-level and property-level filtering together by specifying each setting individually:
```json
{
"RemoveEndpointsWithTags": ["internal"],
"RemoveSchemaPropertiesWithTags": ["beta"],
"RemoveParametersWithTags": ["deprecated"]
}
```
Alternatively, you can use the **`RemoveInformationWithTags`** property to combine all three filtering levels with a single setting:
```json
{
"RemoveInformationWithTags": ["internal", "beta", "deprecated"]
}
```
When using `RemoveInformationWithTags`, the specified tags will be applied across all filtering levels simultaneously:
1. Remove all endpoints tagged with the specified tags
2. Remove all schema properties tagged with the specified tags and update all related examples
3. Remove all parameters tagged with the specified tags
4. Clean up orphaned schemas that are no longer referenced
**Example:**
If you use:
```json
{
"RemoveInformationWithTags": ["internal"]
}
```
This is equivalent to:
```json
{
"RemoveEndpointsWithTags": ["internal"],
"RemoveSchemaPropertiesWithTags": ["internal"],
"RemoveParametersWithTags": ["internal"]
}
```
All endpoints, schema properties, and parameters tagged with `internal` will be removed from your API definition in a single operation.
## Associated Risks and Impacts
When using the `RemoveSchemaPropertiesWithTags` feature, the following risks and impacts should be considered:
- Example descriptions/summaries may still reference removed properties, creating misleading documentation where text doesn't match actual content
- `minProperties`/`maxProperties` constraints may become impossible to satisfy after property removal
- Removed properties will be treated as unvalidated additional properties if `additionalProperties: true` is set
- When example cleanup is disabled through the [`import setting`](/web-dashboard-retired) `RemoveUndeclaredPropertiesFromExample` , removed properties appear as additional properties in the portal and generated code samples.
- Removing a discriminator property breaks the entire polymorphic schema structure
- Property removal from parent schemas propagates to all child schemas inheriting via `allOf`
- Removing distinguishing properties can make `oneOf`/`anyOf` schemas identical, causing validation ambiguity
- Default values assigned to removed properties are lost, potentially changing API behavior
- Callback payload structures change when they reference schemas with removed properties
- Links with runtime expressions break when they reference removed properties
## Overriding Parts of API Definition With Metadata
:::note
This section is intended for advanced use-cases only. We recommend that you [talk to our technical support team](https://www.apimatic.io/contact/) before proceeding.
:::
You can override the following parts of the API definition by specifying related objects in the Metadata:
- [API Description](#api-description)
- [Contact Details](#contact-details-override)
- [Authentication Information](#authentication-information-override)
- [Server Configuration](#server-configuration-override)
- [Additional Headers](#additional-headers-override)
### API Description
You can provide a description for your API in the APIMatic UI as described [here](/web-dashboard-retired). To define these details via the metadata file, you need to add a `Description` property as follows:
**Example:**
```json
{
"Description": "This is an API description. Add as many details as you like."
}
```
### Contact Details Override
The contact details can be defined in the APIMatic UI as described here [Contact Information](/web-dashboard-retired). To define these details via the metadata file, you need to specify the [Contact Object](#contact-object) as follows:
**Example:**
```json
{
"Contact": {
"Name": "John Doe",
"Url": "https://www.example.com/contact/details",
"Email": "john.doe@example.com"
}
}
```
#### Contact Object
**Name**: Contact
The Contact Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | Name of person or organization. |
| `Url` | String | URL pointing to further contact information. |
| `Email` | String | Email of the person or organization. |
### Authentication Information Override
The details on the authentication options available in the APIMatic UI are described [here](/web-dashboard-retired). To enable these options via the metafile, you need to specify the [Authentication Object](#authentication-object) as follows:
**Example:**
```json
{
"Authentication": {
"Type": "Basic",
"Parameters": [
{
"Name": "username",
"Description": "your username"
},
{
"Name": "key",
"Description": "your api key"
}
]
}
}
```
#### Authentication Object
**Name**: Authentication
The Authentication Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `Type` | [Authentication Type](#authentication-type) | Specifies the type of authentication mechanism to apply. The value must be a valid string value from the list of values specified in this [section](#authentication-type). |
| `Parameters` | Array[[Parameter Object](#parameter-object)] | The list of parameters that need to be sent as part of the authentication mechanism. |
| `OAuth2AuthorizationServer` | String | Name of server which serves as the base URL for the Authorization endpoint.|
| `AuthorizationUrl` | String | The route for the Authorization endpoint. This must be a relative URL. |
| `OAuth2Server` | String | Name of server which serves as the base URL for the Token endpoint. |
| `AccessTokenUrl` | String | The route for the Token endpoint. This must be a relative URL. |
| `Scopes` | Array[[Scope Object](#scope-object)] | List of scope definitions for [OAuth v2.0 authentication mechanism](/web-dashboard-retired). |
| `OAuth2ClientIdExample` | String | A value that can be used as an example or demo client ID for OAuth 2 auth types that support this parameter. |
| `OAuth2ClientSecretExample` | String | A value that can be used as an example or demo client secret for OAuth 2 auth types that support this parameter. |
| `OAuth2UsernameExample` | String | A value that can be used as an example or demo client username for OAuth 2 auth types that support this parameter. |
| `OAuth2PasswordExample` | String | A value that can be used as an example or demo client password for OAuth 2 auth types that support this parameter. |
#### Authentication Type
Following are valid values for available authentication types in APIMatic:
| Type | Details |
| ---- | ------- |
| `None` | No authentication mechanism will be applied. |
| `Basic` | Basic authentication flow will be applied. |
| `OAuth_v2_BearerToken` | OAuth v2.0 bearer token authentication mechanism will be applied. |
| `OAuth_v2_WebServerFlow` | OAuth v2.0 authorization code grant type will be used. |
| `OAuth_v2_TwoLeggedFlow_ClientCredentials` | OAuth v2.0 client credentials grant type will be used. |
| `OAuth_v2_ImplicitGrantFlow_UserAgent` | OAuth v2.0 implicit grant type will be used. |
| `OAuth_v2_Resource_Owner_Password` | OAuth v2.0 resource owner password grant type will be used. |
| `OAuth_v2_Password_Only` | A variant of OAuth v2.0 resource owner password grant type that doesn't require client id and client secret will be used. |
| `CustomQuery` | Authentication flow that uses custom parameters sent in the query will be used. |
| `CustomHeader` | Authentication flow that uses custom parameters sent in the header will be used. |
| `CustomField` | Authentication flow that uses custom parameters sent in as form parameters will be used. |
| `JWT` | JWT authentication mechanism will be applied. |
| `CookieAuth` | Cookie based authentication mechanism will be applied. |
#### Parameter Object
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | Name of the authentication parameter. |
| `Description` | String | Details of the authentication parameter. |
| `DefaultValue` | String | Any default value for the authentication parameter. |
**Example**:
```json
{
"Name": "apikey",
"Description": "An API key is required for authentication"
}
```
#### Scope Object
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | A unique user-friendly name or ID for the scope. |
| `Value` | String | Actual value of the scope to be used during OAuth v2.0 authentication. |
| `Description` | String | A text describing what the scope does. |
**Example**:
```json
{
"Name": "Read Notes",
"Value": "read:notes"
}
```
### Server Configuration Override
The details on the server configuration options available in the APIMatic UI are described [here](/web-dashboard-retired). To enable these options via the metafile, you need to specify the [Server Configuration Object](#server-configuration-object) as follows:
**Example:**
```json
{
"ServerConfiguration": {
"DefaultEnvironment": "production",
"DefaultServer": "default",
"Environments": [
{
"Name": "production",
"Servers": [
{
"Name": "default",
"Url": "https://example.com/production/{param}"
}
]
},
{
"Name": "sandbox",
"Servers": [
{
"Name": "default",
"Url": "https://example.com/sandbox/{param}"
}
]
}
],
"Parameters": [
{
"Name": "param",
"Type": "String",
"DefaultValue":"Default Value for Param"
}
]
}
}
```
#### Server Configuration Object
**Name**: ServerConfiguration
The Server Configuration Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `DefaultEnvironment` | String | This is the environment to be used by default across the API. |
| `DefaultServer` | String | This is the server to be used by default. This can be overridden at the endpoint level. |
| `Environments` | Array[[Environment Object](#environment-object)] | List of environments available in the API. An environment consists of a set of servers with base URL values. |
| `Parameters` | Array[[Server Parameter Object](#server-parameter-object)] | List of path parameter definitions that can be referenced by server urls in the server configuration environments. |
#### Environment Object
The Environment Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | Name of the environment (for example, `Production`). |
| `Description` | String | Brief description of the environment. |
| `DisableTryItOut` | Boolean | Default: `false`. When set to `true`, the Try It Out button will be disabled on the API portal for this environment, preventing users from making live API calls against it. |
| `Servers` | Array[[Server Object](#server-object)] | This lets you specify multiple servers within an environment. A server comprises of a name and a URL. The names of the hosts remain consistent over different environments but their values may vary. |
#### Server Object
The Server Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | Name of the server. |
| `Url` | String | Base URL for the server. |
#### Server Parameter Object
The Server Parameter Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | Name of the path parameter used in a server URL. |
| `Description` | String | This describes the path parameter. |
| `Type` | String | This is the name of the type assigned to the path/template parameter. A path parameter can be of the following types: String, Number, Number Enumeration, String Enumeration. |
| `DefaultValue` | String | Value that has to be assigned to Parameter |
### Additional Headers Override
The details on the additional headers available in the APIMatic UI are described [here](/web-dashboard-retired). To enable these options via the metafile, you need to specify the [Additional Headers Object](#additional-headers-object) as follows:
**Example:**
```json
{
"AdditionalHeaders": [
{
"Name": "header",
"Description": "This is a header description.",
"DefaultValue": "default value for header"
}
]
}
```
#### Additional Headers Object
**Name**: AdditionalHeaders
The Additional Headers Object has the following properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| `Name` | String | Name given to the header that has to be added with the API request. |
| `Description` | String | Brief description about the header. |
| `DefaultValue` |String | Value that has to be assigned to the header. |
---
# Merge Multiple API Definitions
Source: https://docs.apimatic.io/manage-apis/api-merging/
If you have multiple API specification documents and wish to create a unified API Portal or obtain a single SDK per language out of them, you can use our merging feature to combine the API specifications into one. The merging feature can also allow you to transform multiple API specifications into a single API specification in a format of your choice using [API Transformer](https://apimatic.io/transformer).
It's possible to merge together API specification documents of different formats, for example, OpenAPI, RAML, and others.
:::note
Merging multiple API specification documents shouldn't be confused with importing or transforming a single API specification split into multiple files which is handled by the importer/Transformer automatically.
:::
## How Does Merging Work?
When multiple API definitions are provided as input, the merger selects two API definitions at a time and merges them together. The output of the merged API is then merged with the third API definition, continuing until all definitions are merged. By default, APIMatic merges API definitions using the *Take Left* merge strategy. When two API definition files are being merged, APIMatic will try to keep elements such as endpoints and schemas from both the APIs while some elements may only be picked from the first API. The merging strategy, therefore, varies from component to component. However, if there is a conflict, the value from the first (left) API definition will take precedence by default. The merging process can be easily configured which will be discussed [later](#configuring-the-merge-process).
The process of merging two API specifications is illustrated below:

Merging of more than two API specifications can look something like as shown below:

## Merging Two API Specifications - A Basic Example
For this example, we will only consider merging two API specification documents for simplicity purposes. You can, however, add any number of specifications for merging.
1. Create a root directory in your local system, say `dir`.
2. Take any two API specification documents (say `spec1.json` and `spec2.json`) and place them in separate directories (say `dir1` and `dir2` respectively) within the root directory `dir` as follows:
```
dir\
dir1\
spec1.json
dir2\
spec2.json
```
3. Add an empty [Metadata](/manage-apis/apimatic-metadata/) JSON file in the root directory and assign it the name `APIMATIC-META.json`
```
dir\
dir1\
spec1.json
dir2\
spec2.json
APIMATIC-META.json
```
4. Open the Metadata file and add the following to enable merging.
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergedApiName": "Merged API"
}
}
```
If you don't intend to generate an SDK/portal but only want to perform a transformation, you will need to disable code-generation specific validation, which is performed during merging, by adding the flag `SkipCodeGenValidation` to the configuration merge settings as follows:
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergedApiName": "Merged API",
"MergeSettings": {
"SkipCodeGenValidation": true
}
}
}
```
Save the changes and close the file.
5. ZIP the contents of the root directory **without including the root directory itself**. The resulting zipped file should be ready for upload to APIMatic for [import](#importing-the-zipped-file-for-sdkportal-generation) or [transformation](#transforming-the-zipped-file). Make sure you are using the `.zip` format to ZIP your files.
### Importing the Zipped File for SDK/Portal Generation
1. On the [APIMatic Dashboard](https://app.apimatic.io/dashboard), click on the **Import** option.

2. Click on **Browse** and select the `.zip` file containing the API definitions to merge. Click on **Import**.

3. Before import, the ZIP file will be [validated](#validating-the-zipped-file) for possible syntax/semantic issues.
4. Once the merged API definition is imported, it will be visible in the list of APIs in the **Dashboard** as shown below:

5. You can now [create an API portal](/cli-getting-started/portal-quickstart-dac) or [generate SDKs](/generate-sdks/create-sdks/create-sdks-through-cli) for this merged API.
### Transforming the Zipped File
1. On the [APIMatic Dashboard](https://app.apimatic.io/dashboard), click on the **Transform API** option.

2. Click on **Choose file** and select the `.zip` file containing the API definitions to merge. Select the **Export Format** from the dropdown, then click on **Convert**.

3. Before transformation, the ZIP file will be [validated](#validating-the-zipped-file) for possible syntax/semantic issues.
4. If validation passes, you can click on **Proceed** to start downloading of the converted merged output.
### Validating the Zipped File
Before import or transformation, APIMatic performs validation of each of the API definition files that are to be merged as well as validation of the API definition created after merging. The validation involves checks to ensure that the API definitions are structurally correct and contain complete information to ensure comprehensiveness of the files. There are 3 levels of validation messages that you may encounter:
- **Errors:** Any syntax/semantic issues found in the API definition; for example, if a GET method contains a request body. API definition file import **can't proceed** in case of an error. You will be required to fix the issues listed for your definition if that happens.
- **Warnings:** Any unexpected behaviour that may affect the output; for example, if the parameter example provided is invalid. Warnings won't **halt** API import, but it's recommended that you fix these issues so your API definition results in the best possible experience.
- **Messages:** Recommendations or suggestions that can help enhance your API definition and its completeness. For example, messages can point out that an endpoint description or a parameter example is missing. Messages won't **halt** API import.
## API Merging
To perform merging of multiple API specifications, you need to correctly structure the input specifications and configure the merging process based on your needs. Each of these steps are discussed in detail below.
### Directory Structure
Structuring the API specification documents correctly is essential for correct output. Some key points to note are:
#### 1. Dedicated Sub-Directory for Each API Definition
Each API definition (whether it's a single file or composed of multiple files) needs to be placed in a dedicated sub-directory. There is no limit on the number of sub-directories, therefore, you can merge any number of API specification documents this way. The sub-directory can optionally contain a [metadata file](apimatic-metadata.md) for configuring how the specification document in this directory needs to be imported. The available configurations are discussed [here](/manage-apis/apimatic-metadata/#what-can-you-achieve-with-a-metadata-file).
#### 2. Parent Directory of Sub-Directories
The sub-directories need to be placed in a parent directory that **must contain a [metadata file](apimatic-metadata.md) at the same level** with [configurations](#configuring-the-merge-process) to enable and customize merging of the specifications in the sub-directories.
#### 3. Types of Sub-Directory Structuring in Parent Directory
##### Linear Sub-Directory Structure
In simpler cases, all sub-directories will likely be placed at the same level in the root directory, that is, a linear sub-directory structure. An example is shown below:
```json
dir\
APIMATIC-META-MAIN.json // Will contain merge settings
spec1\
openapi.json
APIMATIC-META.json // Can contain any specific settings for CodeGen, import/export etc
spec2\
openapi.json
spec3\
schemas\
pet.raml
dog.raml
cat.raml
main.raml
APIMATIC-META.json
```
- `spec1`, `spec2`, and `spec3` are three dedicated sub-directories for the API specifications that are to be merged.
- `spec3` is a RAML specification document split into multiple files whereas the OpenAPI specification documents in `spec1` and `spec2` comprises of a single file only.
- `spec1` and `spec3` each use a metadata file `APIMATIC-META.json` to configure how the `spec1` and `spec3` are imported, respectively.
- A metadata file `APIMATIC-META-MAIN.json` is present in the root directory `dir` that should contain the [Merge Configuration Object](#merge-configuration-object) to help enable and configure merging of its sub-directories. Therefore, its content can look something like:
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergeOrderOfDirectories": ["spec1", "spec2", "spec3"],
"MergedApiName": "Merged API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft"
}
}
}
```
:::important
The order of the API definition files in the `MergeOrderOfDirectories` setting matters, as the merging will be applied based on this order.
:::
- As can be seen from the example, it's possible to merge specifications of different formats like RAML and OpenAPI.
##### Nested Sub-Directory Structure
It's possible to nest sub-directories within another sub-directory. In such a case, the sub-directory becomes a parent directory and must contain the required metadata file to enable and configure merging of its child directories.
A nested sub-directory structure like this is recommended if out of all the API definitions that are required to be merged, some are semantically similar to each other (that is, share common parts in their API definitions) while others are completely different. So, you structure in a way such that the similar ones are merged together first and their output is then merged with other remaining distinct API definitions. An example is shown below:
```json
dir\
APIMATIC-META-MAIN.json
spec1\
spec3\
openapi.json
spec4\
openapi.json
APIMATIC-META-MAIN.json
spec2\
openapi.json
```
- `spec1` and `spec2` are two dedicated sub-directories for API specifications and are placed directly in the root directory `dir`.
- `spec3` and `spec4` are two dedicated sub-directories for API specifications but are placed in the parent directory `spec1`. Here `spec3` and `spec4` likely share some common parts in their API definitions.
- The metadata file `APIMATIC-META-MAIN.json` in `spec1` will contain the [Merge Configuration Object](#merge-configuration-object) and help enable merging of `spec3` and `spec4`. Its content can look like the following:
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergeOrderOfDirectories": ["spec3", "spec4"],
"MergedApiName": "First API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft"
}
}
}
```
- The metadata file `APIMATIC-META-MAIN.json` in root directory `dir` will contain the [Merge Configuration Object](#merge-configuration-object) and help enable merging of`spec1` and `spec2`. Its content can look like the following:
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergeOrderOfDirectories": ["spec1", "spec2"],
"MergedApiName": "Merged API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft"
}
}
}
```
- The merging of the above directory structure will work as follows:
1. `spec3` and `spec4` will be merged first based on the configuration present in the `APIMATIC-META-MAIN.json` in `spec1`.
2. The merged output of `spec1` from previous step will then be merged with `spec2` based on the configuration present in the `APIMATIC-META-MAIN.json` metadata file in the root directory `dir`.
### Configuring the Merge Process
The merge process can be enabled and configured using a [metadata file](apimatic-metadata.md) which is placed in the parent directory containing the sub-directories. The following two objects can be added in this file and help control how the sub-directories are imported and merged:
- [Global Import Settings](#global-import-settings)
- [Merge Configuration Object](#merge-configuration-object)
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergeOrderOfDirectories": ["SpecDirectory1", "SpecDirectory2"],
"MergedApiName": "Merged API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft"
}
},
"ImportSettings": {
"PreferJsonSchemaNameOverTitle": true
}
}
```
#### Global Import Settings
You can optionally provide global [import settings](/web-dashboard-retired) in the root metadata file that will help control how all API specifications in the sub-directories are imported. The global import settings applied this way can be overridden for any API by providing import settings in the API's sub-directory metadata file.
#### Merge Configuration Object
This is a required object using which you can enable merging and optionally configure it as well.
**Name**: MergeConfiguration
| Setting | Type | Purpose |
| ------- | ---- | -------- |
| MergeApis | Boolean | **Required** Enables merging of APIs. By default this is set to `false`. |
| MergeSettings | [Merge Settings Object](#merge-settings-object) | Settings to configure the merge process. See [Merge Settings](#merge-settings-object) object for more detail. |
| MergeOrderOfDirectories | Array[String] | Paths of the sub-directories to be merged, relative from the parent directory in which they're placed. **The order of the API definition files in this list matters, as the MergeSettings configuration will be applied based on this order.** |
| MergedApiName | String | Name of the final merged API. |
**Example**:
```json
{
"MergeApis": true,
"MergeOrderOfDirectories": ["SpecDirectory1", "SpecDirectory2"],
"MergedApiName": "Merged API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft"
}
}
```
#### Merge Settings Object
**Name**: MergeSettings
This object allows configuration of the merge process when merging two APIs.
| Setting | Type | Purpose | Default Value |
| ------- | ---- | ------- | ------------- |
| ConflictStrategy | Enum[[Merge Conflict Strategy](#merge-conflict-strategy)] | Conflict strategy to use when a conflict arises during merge. | `KeepLeft` |
| DescriptionConflictStrategy | Enum[[Merge Conflict Strategy](#merge-conflict-strategy)] | By default, the conflict strategy specified in `ConflictStrategy` will be used for resolving conflicts in descriptions. However, the default conflict strategy for descriptions can be overridden using this setting. | Value of `ConflictStrategy` |
| DeepCompareFieldTypes | Boolean | Whether to compare field level referenced custom types/models by names only or by actually retrieving and comparing their model type definitions. | `false` |
| AppendParentNameInNamingConflict | Boolean | Append parent name to entity when there is a conflict between names instead of appending a number at the end. | `false` |
| SkipCodeGenValidation | Boolean | Configures validation strictness of individual APIs and the merged API. | `false` |
| NumberStartIndexForNameConflict | Number | When resolving conflicts in names of components (for example, endpoints), a number is appended at the end of the conflicting name to make it unique. This setting controls the starting value of this number. | 1 |
| MergeMultipleAuthentication | Boolean | Allow more than one authentication schemes present in the individual APIs, or the APIs being combined, to be merged together. | `true` |
| PrefixEntityNamesWithApiNameBeforeMerge | Boolean | This setting will prefix names of all entities of an API with the API's name before merging, in order to prevent conflicts when this API is merged with another. The entities renamed this way include models, endpoints, endpoint level test cases, authentication schemes and those of server configuration, etc. | `false` |
| PostfixEntityNamesWithApiNameBeforeMerge | Boolean | This setting will postfix names of all entities of an API with the API's name before merging, in order to prevent conflicts when this API is merged with another. The entities renamed this way include models, endpoints, endpoint level test cases, authentication schemes and those of server configuration, etc. | `false` |
| DeduplicateModels | Boolean | This setting will remove or rename any duplicate/redundant model definitions to prevent clashes of models during merge. If deduplication is disabled, the models of the two APIs being merged will simply be combined together. Disable deduplication of models **only** if you are sure that the APIs being merged have models with unique names. Note, that names are compared in a case-insensitive manner therefore, if two models are named `status` and `Status` they're considered conflicting and one of these must be renamed to prevent a clash. | `true` |
| CompareModelsAndFieldsExamples | Boolean | When enabled, this setting will compare schema examples during the schema deduplication process in merging. (This step could be performance-costly.) | `false` |
#### Merge Conflict Strategy
When merging two APIs together, conflicts are possible, for example, entities with the same name can exist in both APIs but with different definitions. In such a case, one of the entities must be renamed to resolve the conflict. The merge conflict strategy helps the merger decide which of the conflicting entities to update or remove in order to resolve the conflict. The possible values of a merge conflict strategy and some details about them are given below:
| Value | Details |
| ----- | ------- |
| `KeepLeft` | The conflicting entity from the left API will be picked up as is while that of the right API will be discarded or updated depending upon the type of the entity being merged. |
| `KeepRight` | The conflicting entity from the right API will be picked up as is while that of the left API will be discarded or updated depending upon the type of the entity being merged. |
| `KeepBoth` | If applicable, values of both conflicting entities will be combined without alteration. If this strategy isn't applicable for an entity, the conflict resolution will fallback to using `KeepLeft`. |
| `Merge` | If applicable, values of both conflicting entities will be merged together intelligently. Some alteration is possible. If this strategy isn't applicable for an entity, the conflict resolution will fallback to using `KeepLeft`. |
### Post-Processing the Merged Output
It's possible to configure, filter or override parts of the merged API definition in the same way it's done for a regular import or transformation. This is achieved by adding required configurations in the same [metadata file](apimatic-metadata.md) that's provided in the parent directory and is used for enabling merging, for example, if you are looking to transform the merged output into OpenAPI and want extensions enabled when you do so, you can enable the export setting `ExportExtensions` in your parent directory metadata file as follows:
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergeOrderOfDirectories": ["SpecDirectory1", "SpecDirectory2"],
"MergedApiName": "Merged API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft"
}
},
"ExportSettings": {
"ExportExtensions": true
}
}
```
This way the OpenAPI output file obtained after merging and then transforming the merged API definition will have extensions included.
For more details on available options to post-process a merged output, please see relevant section [here](/manage-apis/apimatic-metadata/#what-can-you-achieve-with-a-metadata-file).
---
# Get API Integration Keys
Source: https://docs.apimatic.io/manage-apis/get-api-keys/
API Integration keys are your APIs unique identifiers for integrating with services and for managing your APIs via APIMatic's APIs. To view your API's integration keys:
1. On the [APIMatic Dashboard](https://app.apimatic.io/dashboard) click on the kebab menu (three vertical dots) on the API tile for which you want the API Integration key.

2. Select **API Integration Keys** from the options.

3. The keys will be displayed as follows:

---
# View API Logs
Source: https://docs.apimatic.io/manage-apis/view-api-logs/
You can view code generation and package publishing logs for an API.
- Each record for the **generated SDK** contains information of the time you generated this SDK, the platform you generated SDK for, from where the generated SDK is invoked (Website or API) and also a link to download this generated SDK without additional cost.
- Each record for the **published package** contains information of the date/time you published the package, template and repository you used for package publishing, package name, version and link to the published package.
1. On the [APIMatic Dashboard](https://app.apimatic.io/dashboard), click on the kebab menu (three vertical dots) on your API tile.

2. Select **View API Logs** from the options to show the logs.

3. To view the SDK logs for a specific version, select the API version from the drop-down menu and click on the **Zipped** tab.

4. To view the package publishing logs for a specific version, select the API version from the drop-down menu and click on the, select the **Published** tab.

:::note
This is different from the **View Logs** option which combines code generation logs of all the APIs instead of showing logs of just one particular API. Please refer to [Activity Log](account-management/activity-log.md) documentation for more details.
:::
---
# Overview
Source: https://docs.apimatic.io/validate-lint-apis/overview/
When a user uploads an API specification document on APIMatic, the document is passed through certain validation steps during which a number of validation messages may be shown to the user as output. The severity of the messages will indicate whether the user can proceed to do other actions on our products with his document or not e.g. transforming the API to some other format, generating an SDK or a portal, etc. We recommend [using our VS code extension](#vs-code-extension-for-validation) for easily validating and linting your API specification documents in a more familiar environment.
## Key Concepts
### Rules and Rulesets
Each message shown to the user indicates a **rule** that was violated. Related rules are grouped together in documents called **rulesets**. Therefore, a rule is uniquely identified by knowing the id of the ruleset to which the rule belongs (e.g. `apimatic-preliminary-validation`) and the id of the rule itself (e.g. `required-server-url `). If you prefer to keep things short, the same rule can also be uniquely identified with a rule code instead e.g. `APIMATICPRE_V036`.
### Severity of Messages
The severity of the messages can range from `Blocking` (very severe) to `Information` (not severe):
| Severity Level | Details |
| -------------- | ------- |
| Blocking | This is more severe than an **Error**. It indicates that the validation process has found a critical issue in the document that needs to be resolved before the document can be further validated. |
| Error | This is less severe than a **Blocking** error but is more severe than a **Warning**. It indicates presence of one or more syntax or semantic issues in the API specification document e.g. a request body defined in a GET method. An error will not block the validation process. However, the document needs to be fixed before it can be used to generate any further output e.g. transformed output, SDK, portal, etc. |
| Warning | This is less severe than an **Error** but more severe than an **Information** message. It indicates presence of one or more syntax/semantic issues in the API specification document which are not always severe enough to block the output generation. However, not fixing these issues in the document can affect the quality of the output e.g. a message indicating that the name exceeds maximum length restrictions can have adverse effects on the generated output. |
| Information | This is the least severe form of a message. These are generally just recommendations or suggestions that can help enhance your API definition and its completeness e.g. messages that point out that an endpoint description or a parameter example is missing. |
### Rule System of a Message
The messages shown to the users can belong to two types of rule systems:
| Rule System | Details |
| ----------- | ------- |
| Syntax | This system of rules is related to validity of structure of statements or expressions. It dictates which combinations of symbols, statements or expressions is valid and which is not e.g. JSON syntax dictates that all property keys are enclosed in quotes. |
| Semantic | As opposed to the syntax rule system, semantic rule system is more related to whether the constructs convey the correct meaning or are contexually valid or not e.g. a request body should not be defined in a GET method. This is syntactically valid but does not follow the semantic rule system. |
### Validation versus Linting Rules
| Rule Type | Details |
| --------- | ------- |
| Validation | Validation rules check for whether your API description is valid against pre-defined standards of the format in which your API description is written. Additionally, there can be checks to ensure that your API description is technically correct or not e.g. a parameter must have a name is a validation rule. |
| Linting | Linting rules are generally style checks or recommendations that can help enhance you API description document. However, not complying with those checks will not make your document invalid. e.g. a parameter must have a description is a linting rule. |
## Available Rulesets
Full list of available rulesets against which your API description file may be validated/linted is available [here](/rulesets/overview).
## Configuring Validation and Linting
You can configure how APIMatic default validation/linting rules are applied on your API description files using the APIMatic Metadata file validation configuration feature as described [here](/validate-lint-apis/configuring-validation).
## Adding Custom Rules
You can also create and add your own linting rules in a custom ruleset and apply that on your API description documents. For more details, please see documentation on [adding your own rules](/validate-lint-apis/adding-your-own-rules).
## VS Code Extension for Validation
If you use Visual Studio Code, we also [offer an extension](https://marketplace.visualstudio.com/items?itemName=apimatic-developers.apimatic-for-vscode) that can help you easily validate and lint multiple API description files (e.g. OpenAPI) without the need to head over to the APIMatic Dashboard each time. It will help you run standard checks on your API description files as well as additional rules enforced by APIMatic. Once validated, you can easily export your API description files to APIMatic Dashboard without leaving your extension. For more details please see [detailed documentation here](/validate-lint-apis/vs-code-apimatic-extension/overview).
---
# VS Code APIMatic Extension Overview
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/overview/
APIMatic [offers a VS Code extension](https://marketplace.visualstudio.com/items?itemName=apimatic-developers.apimatic-for-vscode&__hstc=245086810.2b533b0fade59d9ff8447ecf4505f32c.1699608692414.1706082233756.1706159622357.68&__hssc=245086810.2.1717741151156&__hsfp=4274364872&hsCtaTracking=a71b0d94-3c82-4f01-8650-1072ee264e52%7C5460378e-4f3a-43f1-985f-1290632e100e) that enables you to easily validate and lint your API definition files in any of the [supported formats](/web-dashboard-retired). The API definition files aren't only validated against standard checks but also linted for ensuring smoother SDK generation, Developer Experience Portal generation and API specification format transformation.

The extension provides a **richer validation experience** by offering dedicated views with messages organized for easy navigation, contextual data for each issues (for example, line and path information, call tree to trace origin) as well as detailed descriptions, hints and reference documentation links for resolving issues quickly. It also supports automatic fixing of common issues found in OpenAPI v3 files (for example, inline schemas) that hinder output quality or generation. You can also generate summary reports in multiple formats (PDF, HTML, JSON, Markdown) for sharing with any relevant stakeholders.
Once your API definition is ready, you can easily **export them to your APIMatic Dashboard** for SDK/DX portal generation without needing to leave the VS Code extension. Additionally, you can also perform **transformation to a selected export format** and obtain the output within your workspace.
## Installation Guide
First, make sure that you have:
1. Visual Studio Code version 1.75.0 or above installed. [Use download link](https://code.visualstudio.com/download).
2. A stable internet connection.
Next, to install the _APIMatic for VS Code_ extension, simply head over to the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=apimatic-developers.apimatic-for-vscode&__hstc=245086810.2b533b0fade59d9ff8447ecf4505f32c.1699608692414.1706082233756.1706159622357.68&__hssc=245086810.2.1717741151156&__hsfp=4274364872&hsCtaTracking=a71b0d94-3c82-4f01-8650-1072ee264e52%7C5460378e-4f3a-43f1-985f-1290632e100e):

On successful installation, the APIMatic API Explorer should be visible in the Activity Bar:

For further information regarding installation of a VS Code extension, please visit the official documentation [here](https://code.visualstudio.com/docs/editor/extension-marketplace#_install-an-extension).
## Getting Started - VS Code Walkthrough
To help you quickly familiarize yourself with all the main features and capabilities, the extension includes a comprehensive getting started walkthrough as part of the [VS Code welcome feature](https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_getting-started):

This step-by-step guide provides a hands-on experience, making it easier for you to get started.
If you're having trouble finding the walkthrough or need to revisit it later, you can also access it using the extension's [Help view](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#help--view) **Start Walkthrough** option:

## Getting Started - How to Validate an API Definition
### Step 1: Authorize Yourself With APIMatic
To start using the extension, you first need to authorize yourself with APIMatic. Click on the **Authorize** button visible in the welcome view:

This will open up the APIMatic login page in your default browser. If you are a new user, you will need to sign up first which should take a few quick steps (and its free):

Once you have successfully logged in, you will be redirected back into your VS Code extension:

Your session details will be visible in the [**Manage Session** view](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#manage-session-view) of the APIMatic API Explorer:

### Step 2: Open an API Workspace Folder
To validate your API definition, you need to have a dedicated workspace folder open in your VS Code where you will work with one or more files associated with the API definition itself. If you already have a folder open that also contains an API definition (for example, OpenAPI), you will receive a notification to open it as an API workspace in the extension. Click **Yes** to select it as your API workspace:

If you don't have an existing API workspace folder, you can still open it as your API workspace. For this guide, we use an empty workspace folder as shown below:

Navigate to the APIMatic API Explorer view in the Activity Bar and click on **Use Current Workspace Folder** to select current folder as your API workspace.

### Step 3: Import an API Definition
If your workspace already contains an API definition, its main entry file will be automatically detected and the validation should start automatically. However, for our current example the workspace doesn't contain any API definition, therefore, a welcome view is shown with various options to create/import an API definition.

We will import a JSON sample file using the relevant options as shown below:

### Step 4: Fix any issues in the API Definition
As soon as an API definition is added to the workspace, it will be automatically validated. You can also manually trigger validation by saving your API definition files.
When the validation completes, the APIMatic API Explorer views, Editor and Problems view will be populated with relevant data to help you tackle all issues.

Once you have resolved all blocker issues, you can export your API definition to your [APIMatic Dashboard](https://app.apimatic.io/dashboard) to start generating an SDK or a Developer Experience Portal.
## Capabilities
The VS Code extension offers the following:
- [Setting up an API workspace.](/validate-lint-apis/vs-code-apimatic-extension/setting-up-api-workspace)
- [Validating an API workspace.](/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace)
- [Automatically fixing an API workspace.](/validate-lint-apis/vs-code-apimatic-extension/auto-fixing-api-workspace)
- [Building an API workspace.](/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace)
- [Exporting an API workspace to APIMatic Dashboard.](/validate-lint-apis/vs-code-apimatic-extension/exporting-api-workspace/)
- [Transforming API workspace specification format.](/validate-lint-apis/vs-code-apimatic-extension/transforming-api-workspace/)
## Advanced
- [About Extension Components](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components.md)
---
# Setting Up an API Workspace
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/setting-up-api-workspace/
To work with one or more API definitions in the APIMatic's VS Code extension, you are first required to select a workspace folder in VS Code as your dedicated API workspace with all relevant files. There are several ways available to set up your API workspace and we will walk you through each of the available options below.
:::note
Ensure that your API workspace contains only relevant files for the API definition. See tips for [working with large workspaces](#managing-large-workspaces) in the extension without affecting performance.
:::
The documentation covers the following topics:
- [Opening an API Workspace](#opening-an-api-workspace)
- [Option 1: Open a New API Workspace](#option-1-open-a-new-api-workspace)
- [Option 2: Open Last API Workspace](#option-2-open-last-api-workspace)
- [Option 3: Use Current Workspace as API Workspace](#option-3-use-current-workspace-as-api-workspace)
- [Adding an API Definition to Your Workspace](#adding-an-api-definition-to-your-workspace)
- [Adding/Importing an Existing API Definition](#addingimporting-an-existing-api-definition)
- [Option 1: Adding a Sample File](#option-1-adding-a-sample-file)
- [Option 2: Importing an Existing File from Local System](#option-2-importing-an-existing-file-from-local-system)
- [Option 3: Importing an Existing File from Public URL](#option-3-importing-an-existing-file-from-public-url)
- [Creating an API Definition from Scratch](#creating-an-api-definition-from-scratch)
- [Option 1: From an Empty File](#option-1-from-an-empty-file)
- [Option 2: From a Template](#option-2-from-a-template)
- [Working with an API Definition](#working-with-an-api-definition)
- [Closing an API Workspace](#closing-an-api-workspace)
- [Managing Large Workspaces](#managing-large-workspaces)
- [Configuring Workspace Notifications](#configuring-workspace-notifications)
## Opening an API Workspace
If you just opened a workspace folder with an API definition (for example, OpenAPI) or opened an API definition file directly, you may receive a [notification](#configuring-workspace-notifications) to open the folder or the API definition's parent folder as an API workspace in the extension. Click **Yes** to select it as your API workspace:

Alternatively, you can simply navigate to the **APIMatic API Explorer** view from the **Activity Bar**. Based on your usage, you may see one or more of the following options:

Here is what you can expect from each of these:
### Option 1: Open a New API Workspace
The **Open New Workspace Folder** option will let you browse your system for a folder that you can use as your API workspace:

Choose a folder and click on **Select Folder** to open it in the **APIMatic API Explorer** view as an API workspace. Note, that this will close your existing workspace session, if any.
### Option 2: Open Last API Workspace
The **Open Last API Workspace Session** option will only be available if you've previously worked on an API workspace. Selecting this option will help restore your last API workspace session so you can resume working from where you left.
### Option 3: Use Current Workspace as API Workspace
The **Use Current Workspace Folder** option will be available if you have a workspace folder open that isn't already marked as an API workspace. Selecting this option will keep your current folder open but will make it accessible in the **APIMatic API Explorer** view as an API workspace.
## Adding an API Definition to Your Workspace
Once you have your API workspace ready, you can begin the next steps of adding an API definition along with any relevant files. We offer some options to help you get started, in the **Open/Create API Definition** side view which are discussed in more detail in the next few sections.

### Adding/Importing an Existing API Definition
If you already have a raw API definition file in your local system or at a public URL, you can import that into your workspace using the relevant import options. Alternatively, if you are just looking to explore the extension and get an idea of things, you can even add a sample file. All of these options should be visible to you under the **Add/Import** title:

#### Option 1: Adding a Sample File
Click on **Add Sample File**. You will be asked to select the desired output format (`json` or `yaml`) after which a `sample-petstore.` will be added in your API workspace instantly.

#### Option 2: Importing an Existing File from Local System
You can browse your local system and import any existing API definition file into your current API workspace using the **Import Existing File** option. The API definition file must be in one of the [supported formats](/web-dashboard-retired). Note, that multi-file selection or ZIP files aren't supported for this option.

#### Option 3: Importing an Existing File from Public URL
If your raw API definition file is available publicly at a URL, you can import it into your current API workspace using the **Import File from Public URL** option. The API definition file must be in one of the [supported formats](/web-dashboard-retired). Note, that multi-file selection or ZIP files aren't supported for this option.
Ensure that you have a stable network connection and then provide a valid public URL path in the input dialog that opens:

If the URL is valid, the file should download successfully into your workspace in a few seconds (depending upon the size):

### Creating an API Definition from Scratch
If you don't have an API definition, you can create one from scratch using options listed under the **Create** title:

#### Option 1: From an Empty File
Click on **Create Empty File**. You will be asked to select the desired output format (`json` or `yaml`) after which a `openapi.` will be added in your API workspace instantly.

#### Option 2: From a Template
We can help you create a basic OpenAPI definition by collecting relevant metadata and generating an API definition accordingly. Click on the **Create File from Template** option to begin.
- First, you will be required to enter a short meaningful name for your API service:

- Next, you will be asked to briefly describe what service your API provides:

- Next, enter the URL of the server at which your API is served:

- Lastly, pick an output format for your API definition file (JSON/YAML):

After the above data is collected, an API definition file will be instantly generated in your API workspace based on the collected information:

### Working with an API Definition
We recommend defining your API using the latest available OpenAPI specification version. If you feel the need to refer to the specification documentation at any time while working on your API definition, you can click on the API format name in the status bar at the bottom right side which will open the standard documentation within the extension in a separate tab:

## Closing an API Workspace
To close a currently open API workspace in the extension (not the VS Code), you can use the **Close API Workspace** option from the [Manage Session](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#manage-session-view) view:

You will be asked to confirm this action before proceeding:

Once closed, validation and other features won't work until the workspace is re-opened/re-selected as an API workspace.
:::note
Closing the API workspace will only remove the extension's access to the workspace folder. The workspace folder will still remain open in VS Code.
:::
## Managing Large Workspaces
For optimal performance, it's recommended to keep the API workspace small and focused with only relevant files present. Ideally, the workspace shouldn't exceed 20MB in size. However, if you have a large workspace that you would like to open in your VS code, there are certain ways available to improve extension performance. Without those measures, you may encounter performance related warnings as shown below:

Here are some tips for better performance when working with large workspaces:
- Manually delete any extra files or folders that aren't relevant and can be safely removed.
- Exclude the files or folders that aren't directly related to the API definition itself using the [Workspace File Navigator view's](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-file-navigator-view) [**Exclude**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#exclude-filefolder-from-api-workspace) option:

Excluded files/folders will remain in the workspace but will be safely ignored by the extension for all of its operations.
## Configuring Workspace Notifications
If the extension doesn't have any API workspace open, it will still run in the background, automatically detect API definition files and show relevant notifications:
- On loading a new workspace folder with one or more API definitions:

- On opening an API definition file directly:

If you no longer wish to receive such notifications, you can click on the **Don't Ask Again** option:

Disabling file specific notifications will disable notifications for all workspaces by default.
Disabling notifications shown for currently open workspace folder will, by default, disable notifications for that particular workspace only. You will be asked to confirm whether you wish to continue receiving notifications for other workspaces or not:

Once your notification preferences have been updated, you can change them at any time from the extension settings. To do this, navigate to the VS Code [**Settings**](https://code.visualstudio.com/docs/getstarted/settings) (click on the gear icon at the bottom left side of the **Activity Bar**):

Next, navigate to the **APIMatic** settings from the **Extensions** side-menu:

Here you can toggle notifications for the **_When API File is Detected_** setting either for a specific workspace or globally for all workspaces in the User tab, as per your preferences.
---
# Validating an API Workspace
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace/
Once your [API workspace is set up](/validate-lint-apis/vs-code-apimatic-extension/setting-up-api-workspace) along with an API definition, you can start validating it. The extension offers multiple dedicated views to help you get the information you need as efficiently as possible.

The documentation covers the following topics:
- [Triggering the Validation](#triggering-the-validation)
- [Validation Messages in the Problems View](#validation-messages-in-the-problems-view)
- [Validation Messages in the Active File Editor](#validation-messages-in-the-active-file-editor)
- [Issues at Cursor Position](#issues-at-cursor-position)
- [Obtaining a Workspace Validation Summary](#obtaining-a-workspace-validation-summary)
- [Generating Validation Reports](#generating-validation-reports)
- [Finding Additional Information for a Validation Issue](#finding-additional-information-for-a-validation-issue)
- [Configuring Validation](#configuring-validation)
- [Adding Your Own Linting Rules](#adding-your-own-linting-rules)
- [Merge-Aware Validation](#merge-aware-validation)
- [Configuring Maximum Validation Messages Limit](#configuring-maximum-validation-messages-limit)
## Triggering the Validation
The validation process triggers automatically with the following events:
- When the API workspace is loaded at startup.
- When a new API workspace is loaded after the workspace folder changes.
- When a user saves a file present in the API workspace.
In case of any trouble, the validation can also be manually triggered using the status bar button. Note, however, that the validation only works on saved files and any unsaved changes aren't considered:

For validation triggering to work as expected, it's important that your API workspace contains a main entry file in one of the [supported specification formats](/web-dashboard-retired) with all relevant identification metadata available, for example, OpenAPI `v3.1` files must contain a root level `openapi` property with value set as `3.1.0`. The extension automatically detects the main entry file based on this identification metadata, highlights its name and labels the detected file with a small `api` keyword next to the file name in the [**Workspace File Navigator**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-file-navigator-view) view:

If you don't see this label in front of any of your files, and your workspace contains multiple directories it's possible that your file is hidden from view. To reveal the main file in such cases, you can use the reveal feature. Hover near the [**Workspace File Navigator**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-file-navigator-view) view title and click on the [**Reveal All Main API Files**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#reveal-all-main-api-files) option:

This will expand all directories and highlight any files labelled as `api` .

If you are still unable to find a file with the `api` label, it's likely that your main entry file lacks the identification data we require. Please see our [troubleshooting tips](/web-dashboard-retired) to resolve such issues.
Once the main file is detected, you should see the validation process being triggered as expected. The validation process will run in the background. While the validation is running, you should see a `Validating...` message in the status bar:

## Validation Messages in the Problems View
Once the validation completes, you should see one or more validation logs in the VS Code **Problems** view if any issue is found in your API definition:

The validation log will be shown with the appropriate severity level and contain the source name (APIMatic), issue message, line/path information as well as any contextual data related to the issue in the form of key-value pairs, for example, in the above screenshot the name of the unused tag is shown in a key-value form with key set as `Undefined Tag`. The validation message will also list the issue code (`OPENAPI3APIMATIC_L235`) which can be used to view more details about it in the [**Learn More**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#learn-more-view) view.
## Validation Messages in the Active File Editor
If you currently have a workspace file open in the **Editor** with validation issues, those issues will be highlighted in the editor at a specific line and position with appropriate squiggles based on severity of messages. Hovering over a squiggly will provide you further information about the issue, for example, the source (APIMatic), issue message, line/path information as well as any contextual data related to the issue in the form of key-value pairs, for example, in the screenshot below the name of the unused tag is shown in a key-value form with key set as `Undefined Tag`. The hover message will also list the issue code (`OPENAPI3APIMATIC_L235`) which can be used to view more details about it in the [**Learn More**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#learn-more-view) view.

In some cases, the hover message may also show information about components referencing the current component using `$ref`:

For more details about this feature, please see related documentation [here](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#violation-call-trees).
### Issues at Cursor Position
The amount of information that can be provided for an issue in the hover message is limited. Therefore, the dedicated view named [**Active Violations**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#active-violations-view) can be used to view complete set of issues/violations and their details, based on where your current cursor position is in the active editor.

The details of a particular violation can include the following:
- Message associated with the issue.
- Severity of the issue.
- Key-value pairs contextual data (if any) associated with the issue.
- Location, for example, line/path information for the issue.
- Reference call tree to help trace origin of issue when the current component containing the issue is referenced by one or more components.
## Obtaining a Workspace Validation Summary
To get an overall summary of all validation issues found in the complete API workspace, you can use the dedicated [**Workspace Validation Summary**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-validation-summary-view) view. This view offers intelligent grouping of the issues to help you tackle problems efficiently as well as gives you an overall score of your workspace which can help roughly predict the quality of output you can hope to get in any API tool (including APIMatic) with your current API definition:

As can be seen in the screenshot, the issues in this view are grouped into various meaningful categories based on their severity, whether they're validation or linting messages or whether they affect code generation or documentation generation. Within these groups, the issue instances are further grouped on the basis of the issue message. Therefore, you can easily select a particular issue based on its severity and then be able to navigate through all of its instances across the whole workspace as well. Similarly, if you want to resolve validation issues before moving on to linting issues, you can do that easily as well.
### Generating Validation Reports
If you wish to share the validation summary of your API definition with external stakeholders, we recommend that you generate a validation report in one of the supported formats. Hover near the [**Workspace Validation Summary**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-validation-summary-view) view title and you should see a `Generate Audit Report(s)` button near the top right corner. Click on it:

Select the desired output format of the report (`JSON`/`HTML`/`Markdown`/`PDF`):

Next, you can optionally provide the name of the individual or organization to whom you intend to address the report:

Once the information collection is completed, the generated report will be downloaded into the root folder of your API workspace:

Here is a preview of a sample report generated with this option:

Note, that if multiple APIs are involved in the workspace or the workspace has also been built for APIMatic using the [**Build**](/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace/) option, multiple reports may be generated in the form of a ZIP file.
## Finding Additional Information for a Validation Issue
There are several alternative ways available to access more details for a validation issue, for example, hints, external documentation, and links. These include:
- Click on `(?)` next to an issue message in either the [**Active Violations**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#active-violations-view) or [**Workspace Validation Summary**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-validation-summary-view) views:

- OR click on the message code in the **Problems** view:

- OR hover over a problem in the **Editor** and click on the message code:

Doing any of the above actions will open up the [**Learn More** view](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#learn-more-view) with all relevant details associated with the issue:

This view can be [expanded further](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#expand-rule-details) to explore details more easily:

## Configuring Validation
You can configure the validation and linting process by providing a [validation configuration object](/validate-lint-apis/configuring-validation/#validation-configuration-object) in the APIMatic's Metadata file. The extension allows you to easily add a [Metadata](/manage-apis/apimatic-metadata/) file with a default validation configuration as follows:
- Hover near the [**Workspace File Navigator**](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#workspace-file-navigator-view) view title and click on the **Add APIMatic Metadata Configuration File** option:

- You will be asked to select all items you'd like to initialize in the APIMatic Metadata file. For the current example, we will only select `Validation` from the list:

- After proceeding, an APIMatic Metadata file will be successfully added in your workspace with a default validation configuration as shown below:

Please see our detailed documentation to learn more about [configuring validation](/validate-lint-apis/configuring-validation/). While configuring, you may find it useful to refer with the [Learn More view](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#learn-more-view) to obtain more details about the rule/ruleset you are looking to configure, for example, you can obtain the ids of the rule/ruleset as described [here](/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/#copy-rule-and-ruleset-id).
## Adding Your Own Linting Rules
The extension supports validation against any custom lint rules defined by the user. See our detailed documentation to learn more about [adding your own rules](/validate-lint-apis/adding-your-own-rules/).
## Merge-Aware Validation
APIMatic [supports merging](/manage-apis/api-merging/) of multiple API definitions. To ensure a successful merge, it's required that:
- Each API definition involved in the workspace is valid, that is, it has no validation errors.
- Each API definition, when built for APIMatic using the [**Build**](/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace/) option, results in a successful build.
- Each API definition when merged with another, results in a valid API definition which has no validation errors and also passes the build process.
The VS code extension lets you perform all of the above forms of validation layers on your APIs to be merged such that all views associated with validation, that were discussed earlier, are populated with data of all the APIs involved.
For better performance and ease of understanding, we recommend that you validate and build a single API definition at one time. This can be done by opening the API workspace folder containing only the specific API definition's files. Once you have ensured that all API's are valid this way, you can open the root workspace folder as your API workspace which contains the directories of all of your API definitions as well as the base APIMatic Metadata file responsible for initiating the merge process. [**Build**](/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace/) this folder to ensure that all merge related checks pass for all your API definitions. If build passes, you should be able to easily [export](/validate-lint-apis/vs-code-apimatic-extension/exporting-api-workspace/) your workspace to APIMatic Dashboard for SDK/portal generation.
## Configuring Maximum Validation Messages Limit
VS Code limits the maximum no. of validation messages per file to approximately 1000. To respect that and prevent any disconnect between the extension validation information and one shown on the **Editor** and **Problems** views, we've also limited the maximum no. of validation messages per file to be 999 by default. However, for bigger API definition files it's often common to see larger no. of issues in a single file. In such cases, if a user wishes to see the complete list of validation issues in the extension as well as generate full validation reports, they can change the maximum limit as per their needs or remove it entirely, from the extension settings. To do this, navigate to the VS Code [**Settings**](https://code.visualstudio.com/docs/getstarted/settings) (click on the gear icon at the bottom left side of the **Activity Bar**):

Next, navigate to the **APIMatic** settings from the **Extensions** side-menu:

Here the limit value set in the **_Max Problems Per File_** setting can be increased/decreased either for a specific workspace or globally for all workspaces in the _User_ tab, as per needs. To allow an infinite number of problems, leave the value empty.
Note, however, that changing the validation problems limit will only affect the extension views and validation reports and won't alter the VS Code **Problems** view or no. of **Editor** problems due to limits set by the VS Code itself.
---
# Auto Fixing an API Workspace
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/auto-fixing-api-workspace/
Auto fixing, as the name suggests, can help facilitate you by resolving some common issues in your API definition automatically. For example, OpenAPI and other popular API specification formats aren't inherently designed for code generation and therefore it's quite common to see inline schemas in API definitions. Inline schemas negatively impact the output quality of the generated SDKs/Developer Experience Portals. However, most users aren't familiar with them and may have trouble tackling them efficiently. This is where auto fixing can help as it can easily convert such schemas into global schemas by intelligently assigning unique but meaningful names to them. After auto fixing has completed, users will have full control to refine the names as they wish. Similarly, auto fixing can help resolve other common issues as well.

By default, the auto fix process runs for the whole API workspace and tries to resolve as many [supported issues](#rules-supported-for-auto-fixing) as possible. Support for auto fixing specific issues based on user preference will be added in the future.
## Pre-Requisites
Auto fixing requires the following:
- The API definition has been validated at least once.
- None of your API definition files contain basic JSON/YAML syntax errors. If errors are found, the auto fix may not proceed further or quit with the following message pop-up:

## Auto Fixing Your API Workspace
To begin auto fixing your API workspace, you need to click the (💡) icon from the left side of the status bar:

The auto fix process will start in the background after verifying that the validation process has occurred. While the auto fixing is running, you should see a `Auto-fixing...` message in the status bar:

If your API definition contains issues that can't be auto fixed or the auto fixing fails, you will see the following message pop-up:

If the auto fixing proceeds successfully, you should shortly start seeing live logs for the changes being made to the files including information of what was added/removed/updated and where:

Once the auto fix process completes, you will have the option to either save or undo all the changes made:

At this point you can review the logs to make your decision and proceed accordingly. If you choose to save all changes, the workspace will be re-validated and issues fixed will be removed from the validation list.
## Auto Fixing Specific Violation or Instance
If you prefer not to auto fix the entire API workspace, the VS Code Extension also supports fixing individual violations or even specific instances of a violation.
To fix all instances of a particular violation, hover over the violation in the **Workspace Validation Summary**. You will see a (💡) icon next to it. Clicking this icon will trigger auto fixing for all instances related to that specific violation.

You can also choose to fix just a single instance instead of all related ones. Hover over the specific instance in the violations list and click the (💡) icon that appears next to it. This will apply the fix only to that particular occurrence.

These targeted options give you greater flexibility and control when addressing validation issues in your OpenAPI definition.
## Rules Supported for Auto Fixing
Depending upon the use-cases, auto fixing may support automatically resolving issues associated with the following rules only:
- [resolvable-reference](/rulesets/input-file-validation/resolvable-reference/)
- [operation-id-exists](/rulesets/openapi-v3-apimatic-linting/operation-id-exists/)
- [no-inline-complex-schema-definition](/rulesets/openapi-v3-apimatic-linting/no-inline-complex-schema-definition/)
- [no-inline-enum-schema-definition](/rulesets/openapi-v3-apimatic-linting/no-inline-enum-schema-definition/)
- [valid-operation-id](/rulesets/openapi-v3-codegen-syntax-linting/valid-operation-id/)
- [info-description-exists](/rulesets/openapi-v3-docsgen-linting/info-description-exists/)
- [at-least-one-tag-reference](/rulesets/openapi-v3-apimatic-linting/at-least-one-tag-reference/)
- [pre-defined-operation-tag-in-global-tags](/rulesets/openapi-v3-apimatic-linting/pre-defined-operation-tag-in-global-tags/)
- [unique-tag](/rulesets/openapi-v3-apimatic-linting/unique-tag/)
- [unique-case-insensitive-global-tag-name](/rulesets/openapi-v3-codegen-linting/unique-case-insensitive-global-tag-name/)
- [unique-schema-enum-list-items](/rulesets/openapi-v3-standards-linting/unique-schema-enum-list-items/)
- [parameter-example-or-examples-exist](/rulesets/openapi-v3-docsgen-linting/parameter-example-or-examples-exist/)
- [schema-example-or-default-value-exists](/rulesets/openapi-v3-docsgen-linting/schema-example-or-default-value-exists/)
- [valid-schema-examples](/rulesets/openapi-v3-standards-linting/valid-schema-examples/)
- [operation-optional-parameters-after-required-parameters](/rulesets/openapi-v3-codegen-linting/operation-optional-parameters-after-required-parameters/)
This list will be updated as more and more rules are supported for auto fixing.
---
# Building an API Workspace
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace/
If you are looking to generate SDKs, Developer Experience Portals or simply transforming your API definition's format to another specification format, you need to ensure that your API definition is valid for and compatible with APIMatic. This is ensured through a "Build" step that essentially converts the API definition into an intermediate format supported by APIMatic and runs additional checks on it. If the build is successful, you can proceed to generating SDKs/portals or transforming as required. If not, you will need to take some extra steps in your API definition to ensure they are ready for APIMatic. The build process for transformation is more flexible than one performed for code generation which strictly enforces a few extra checks e.g. those related to naming conventions.
## Pre-Requisites
In order to build your API workspace in the VS Code extension, it is required that your workspace has passed through the validation layer and that did not result in any validation errors (blocking or otherwise). If it did, you may see an error like below:

Note, that validation warnings or any linting errors are allowed and will not prevent the build from proceeding.
## Building the API Workspace
To build your API workspace, you need to click the tools (🛠️) icon from the left side of the status bar:

The build process will start in the background after verifying that the validation process has occurred and did not result in any blocking errors. While the build is running, you should see a `Building...` message in the status bar:

Depending on whether the build passes or not, you will see a `Build Passed` or a `Build Failed` message in the status bar:

The validation views will be populated with additional messages from the build process with codes beginning with `APIMATIC`. If the build fails, the messages will include errors as well.

You will need to re-trigger the build process each time the validation information changes for the API workspace.
### Building for API Specification Transformation
By default, the build process will enforce code generation specific checks as well. If you only intend to perform a simple API specification transformation for your API definition, you should configure the validation process as described [here](/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace/#configuring-validation) and set the `SkipCodeGenerationChecks` flag to `true`.
---
# Exporting an API Workspace to APIMatic Dashboard
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/exporting-api-workspace/
You can easily export your API workspace from within the VS Code extension to your [Dashboard](https://app.apimatic.io/dashboard) once your API definition is ready. The export will essentially collect all files from the API workspace and [import](/web-dashboard-retired) them as a single API entity in the [Dashboard](https://app.apimatic.io/dashboard). The exact behavior you can expect from this feature is discussed in this document.

## Pre-Requisites
- You must be authorized with APIMatic using an **Authentication Key** to export your API workspace. To obtain an authentication key please see relevant documentation [here](/account-management/obtaining-auth-keys/). When exporting, you will be prompted to provide the authentication key the first time:

Only if the provided key is valid, will you be allowed to proceed with the export. You won't be prompted for the key again for as long as it's valid.
- In order to export your API workspace to the Dashboard, it's required for your workspace to pass the [Build](validate-lint-apis/vs-code-apimatic-extension/building-api-workspace) first. The build must be run with code generation checks enabled, that is, if you are using an [APIMatic Metadata file](/manage-apis/apimatic-metadata/) it must not set the `SkipCodeGenerationChecks` flag in the [Validation Configuration](/validate-lint-apis/configuring-validation/#validation-configuration-object) to `true`.
## Exporting the API Workspace
To export your API workspace, click on the upload (☁️) icon from the left side of the status bar:

The export process will begin instantly. If your workspace isn't already built, the build process will start first:

If the build passes, the export process will proceed to importing the workspace into the APIMatic Dashboard. At this point you should see a `Exporting...` message in the status bar:

If you are exporting for the first time, a successful export will create a new API group entity in your APIMatic Dashboard:

The exported entity should be visible in your Dashboard:

Subsequent export requests will update the existing entity if it still exists and with the same API name. When updating the same version of an existing API group entity, existing version will only be replaced after taking consent. If consent isn't given, a new API group entity will be created in the Dashboard instead:

If a new version is being exported for the same API group entity (that is, with the same name), it will be added as a separate new version within the same API group entity without replacing the older versions:

This is how it will look like for your API entity in the Dashboard:

## Configuring the Export Process
An export from the VS Code extension is essentially an "import" into the Dashboard. You can largely control how this import works and affects the SDK/Developer Experience portal generation, using various [configuration options](/web-dashboard-retired).
The VS Code extension allows you to easily add a [Metadata](/manage-apis/apimatic-metadata/) file with default import settings as follows:
- Hover near the **Workspace File Navigator** view title and click on the **Add APIMatic Metadata Configuration File** option:

- You will be asked to select all items you'd like to initialize in the APIMatic Metadata file. For the current example, we will only select `Import` from the list:

- After proceeding, an APIMatic Metadata file will be successfully added in your workspace with default import settings as shown below:

## For More Information
You can find out more details [here](/web-dashboard-retired) about how an exported API definition's import to the Dashboard works.
---
# Transforming API Workspace Specification Format
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/transforming-api-workspace/
You can easily transform the API specification format being used by your API workspace to a different format using our VS Code extension's Transform feature.

## Pre-Requisites
- You must be authorized with APIMatic using an **Authentication Key** to transform your API workspace. To obtain an authentication key please see relevant documentation [here](/account-management/obtaining-auth-keys/). When transforming, you will be prompted to provide the authentication key the first time:

Only if the provided key is valid, will you be allowed to proceed with the transformation. You will not be prompted for the key again for as long as it is valid.
- In order to transform your API workspace, it is required for your workspace to pass the [Build](/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace/#building-for-api-specification-transformation) first.
## Transforming the API Workspace Format
To transform your API workspace specification format, click on the two-way arrow (`<->`) icon from the left side of the status bar:

Select the desired output API specification format from the list e.g. OpenAPI `v3.1`:

Next, select the destination folder where you would like to save the transformed output file:

After selecting a folder, if your workspace isn't already built, the build process will start first:

If the build passes, the transformation process will start next. During this, you should see a `Transforming...` message in the status bar:

When the transformation is complete, the converted output will be downloaded into your workspace root folder:

## Configuring the Transformation Process
Transformation can be easily configured using various [available options](/api-transformer/configuring-transformer/). Since transformation is essentially import and export steps combined into one step, the VS Code extension allows you to easily add a [Metadata](/manage-apis/apimatic-metadata/) file with default import and export settings as follows:
- Hover near the **Workspace File Navigator** view title and click on the **Add APIMatic Metadata Configuration File** option:

- You will be asked to select all items you'd like to initialize in the APIMatic Metadata file. For the current example, we will only select `Import` and `Export` from the list:

- After proceeding, an APIMatic Metadata file will be successfully added in your workspace with default import and export settings as shown below. You can play around with these settings to control the transformation process as per your needs:

## For More Information
You can find out more details [here](/api-transformer/overview-transformer/) about our API Transformer solution and its related information.
---
# About Extension Components
Source: https://docs.apimatic.io/validate-lint-apis/vs-code-apimatic-extension/about-extension-components/
The APIMatic's VS Code extension makes two major contributions to the VS Code:
- An [APIMatic API Explorer view container](#apimatic-api-explorer-view-container) and
- Several [status bar actions](#status-bar-actions).
This document covers each of the above component in detail.
## APIMatic API Explorer View Container
You will find all important views associated with the extension, in the **APIMatic API Explorer** view located in the Activity Bar. These views allow for easy API file navigation as well as for understanding validation issues better.

Full list of views associated with the APIMatic API Explorer view container is given below:
1. [Workspace File Navigator View](#workspace-file-navigator-view)
2. [Workspace Validation Summary View](#workspace-validation-summary-view)
3. [Active Violations View](#active-violations-view)
4. [Learn More View](#learn-more-view)
5. [Manage Session View](#manage-session-view)
6. [Help 💡 View](#help--view)

### Workspace File Navigator View
The main purpose of this view is to make it easier for users to navigate through and work with files and folders involved in the [API workspace](/validate-lint-apis/vs-code-apimatic-extension/setting-up-api-workspace/).

This view offers the following functionalities:
- [Open Files in the Editor](#open-files-in-the-editor)
- [Main API File Highlighting and Labelling](#main-api-file-highlighting-and-labelling)
- [Reveal All Main API Files](#reveal-all-main-api-files)
- [Add an APIMatic Metadata File](#add-an-apimatic-metadata-file)
- [APIMatic Metadata Files Labelling](#apimatic-metadata-files-labelling)
- [Exclude File/Folder from API Workspace](#exclude-filefolder-from-api-workspace)
- [Refresh View](#refresh-view)
- [Edit Files and Folders](#edit-files-and-folders)
- [Collapse All Folders](#collapse-all-folders)
#### Open Files in the Editor
Clicking on a file's name will open it in the VS Code Editor. However, only textual or non-binary files can be opened this way.
#### Main API File Highlighting and Labelling
To distinguish API definition's main entry files from other files, they are given a default background color and have an `api` label attached after the file name:

#### Reveal All Main API Files
If you are dealing with multiple API definitions in your API workspace or your main entry file for the API definition is nested within a folder, you can use the reveal feature to bring all main API files in the workspace directories into view. This will uncollapse all collapsed directory names to reveal nested items.
- Hover near the **Workspace File Navigator** view title and click on the **Reveal All Main API Files** option as shown below:

- This will instantly expand all directories and reveal all highlighted main API files:

#### Add an APIMatic Metadata File
If your API workspace lacks an APIMatic [Metadata](/manage-apis/apimatic-metadata/) file, the view offers an option to quickly add one:
- Hover near the **Workspace File Navigator** view title and select the **Add APIMatic Metadata Configuration File** option as shown below:

- You will be asked to select one or more configuration objects to initialize by default. Pick as per requirements:

- A metadata file with selected configurations will be instantly added in the API workspace:

#### APIMatic Metadata Files Labelling
To distinguish APIMatic's [Metadata](/manage-apis/apimatic-metadata/) files in the view from other files, a `meta` label is attached after their file name:

#### Exclude File/Folder from API Workspace
If your workspace contains files or folders that aren't directly linked to the API definition but are part of your API project only, it is recommended that you exclude them from your API workspace using the **Exclude** option in the **Workspace File Navigator**:

This option is also available in the context menu for each file/folder:

Excluding a file/folder adds its path to the root level `.apimaticvscodeignore` file (created from scratch if one doesn't exist already) of the API workspace in the form of a glob pattern:

This action will also hide the file/folder from the **Workspace File Navigator** view. The extension will safely ignore all such files during validation and all other operations.
#### Refresh View
If the files/folders involved in the API workspace have changed outside the VS Code extension, you can refresh the navigator view to get updated information for each file and folder. This can be done by hovering near the **Workspace File Navigator** view title and clicking on the refresh (🔃) icon:

This will reload the files and folders as well as re-validate the workspace.
#### Edit Files and Folders
The files and folders in this view appear as read-only since basic file related functionalities (e.g. renaming, deleting or adding) are already available in the VS Code's [Explorer](https://code.visualstudio.com/docs/getstarted/userinterface#_explorer) view. If you still wish to perform some file/directory related actions, click on the pencil (✏️) icon that becomes visible on hover near the navigator view's title or the file/directory name:
- Edit option near the file/directory name:

- Edit option near the File Navigator view title:

Clicking on this will switch the active view to the Explorer and highlight your selected file/directory name in it so you can quickly perform required actions there.

An alternative approach to doing this would be to open the context menu for a file/folder and clicking on the **Edit** option:

#### Collapse All Folders
To quickly collapse all folders in the API workspace, hover near the **Workspace File Navigator** view title and click on the collapse all icon:

All expanded directories will instantly be closed.
### Workspace Validation Summary View
This view shows a summary of validation status of the complete API workspace.

#### Generate Reports
To share the validation summary with external stakeholders, you can generate one or more reports by clicking on the report (🗒️) button visible in the top right corner when you hover on the **Workspace Validation Summary** view title:

Here is a preview of a sample report generated with this option:

To learn more about generating reports, please check out our documentation [here](/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace/#generating-validation-reports).
#### Validation Status
The overall pass/fail status is shown in the **Status** property. Possible values and what they mean are defined below:
| Status | Details |
| ------ | ------- |
| Passed | All files in the API workspace are valid and have no issues. You can safely proceed to generating desired output from your API definition(s). |
| Passed With Warnings | One or more files in the API workspace have some warnings but this won't be a blocker for generating an output from your API definition(s). |
| Failed With Errors | One or more files in the API workspace contain errors that need to be resolved before you can generate any output for your API definition(s). |
| Failed With Blocking Errors | One or more files in the API workspace contain blocker issues that are preventing the validation process from completing. Once these issues are resolved the validation process will resume and may detect more issues. No output can be generated from the API definition(s) unless all blocking issues (current and any upcoming) are resolved. |
The overall status is decided based on the [severity of messages](/validate-lint-apis/overview/#severity-of-messages) logged for the API workspace.
#### Score
Labelled as **Percentage Score**, this is another measure to help you quickly determine how good or bad your API workspace definitions are doing in terms of number of issues, severity, type of issues, etc. You should aim for a score above 80% to get a better output from your API definition(s) in any API tool.
#### Total Messages
Labelled as **Total**, this property shows the total number of issues present across all files in your API workspace. This includes a sum of issue types and their particular instances.
#### Messages by Severity
Validation issues/messages are grouped based on [severity](/validate-lint-apis/overview/#severity-of-messages) level to help you tackle blocker issues first followed by warnings and so on. The severity level is followed by a count of message instances that are of the selected severity level.
#### Validation/Linting Messages
Issues are also grouped based on whether they are validation messages or linting messages. The total count of message instances of the selected type is mentioned at the end of the label.
#### Code Generation and Documentation Messages
Issues that are likely to affect code generation output are grouped under the **Code Generation** category. Similarly, issues that can affect quality of auto-generated documentation are grouped under the **Documentation** category. The total count of message instances of the selected category is mentioned at the end of the label.
#### Instances Grouped by Message
At the top-level, the messages are grouped either by severity or based on whether they are validation or linting messages. Instances of messages belonging to these groups are further grouped on the message value. Label of such groups show the message value followed by a count of instances belonging to the message. This grouping can be useful if you want to tackle a particular issue and all of its instances first before moving on to another issue.

If you want to understand what a message means, view hints to resolve the issue or just want to see more details about the rule that the message belongs to, you can click on the `(?)` visible when you hover near the message value. This should open the [Learn More View](#learn-more-view) with all relevant details.
#### Navigating to a Message Instance
Message instances are likely to have a file and line/path information attached to them. Clicking on an instance will take you to where the instance is located by first opening the target file and then highlighting the target line in the file. In some cases, where the instance may not be directly associated with a file, a path information will be available and clicking on the instance will not have any effect.
#### Collapse All Nodes
If the information becomes overwhelming you can quickly collapse all nodes of the view using the **Collapse All** option from the right corner of the view title:

After collapsing, all inner nodes will be collapsed and only the root level ones will be shown:

### Active Violations View
This view provides additional contextual information for one or more violations that are currently active in either the Editor or in other views like the [Workspace Validation Summary view](#workspace-validation-summary-view).
The information shown on hovering over a squiggly in the Editor, when working with an API workspace file, is quite limited. It is also possible that multiple issues exist at the squiggly point which makes the hover messages more confusing especially since they lack any severity information:

To make it easier to tackle issues at a particular point in the file open in the Editor, the **Active Violations** view updates itself with every cursor position change in the Editor and shows a list of issues/violations applicable at that position. For each issue, additional contextual information is provided as well to help users resolve issues more efficiently.

#### Selected
When a user selects a violation from either the list of violations from the [**Cursor**](#cursor) property of the Active Violations view or from the [Workspace Validation Summary view](#workspace-validation-summary-view), the selected violation and its details are shown under the **Selected** property of the Active Violations view.

#### Cursor
This property shows the line number and position/column of your cursor in the active Editor followed by a total count of issues or violations nested inside it which are applicable at that particular position.
The data that is available for each violation is described in the next few sections.
#### Violation Message
For each violation the root node represents the message associated with the issue, visible to you when you hover over the squiggly in the editor and which describes the problem in few short words.
If you want to understand what a violation message means, view hints to resolve the issue or just want to see more details about the rule that the message belongs to, you can click on the `(?)` visible when you hover near a violation message value. This should open the [Learn More View](#learn-more-view) with all relevant details.
#### Violation Severity
Labelled as **Severity**, this property indicates the [severity level of the message](/validate-lint-apis/overview/#severity-of-messages).
#### Violation Location
Labelled as **Location**, this property shows the file path and the line number and position range within the file at which the issue exists i.e. unlike the cursor position which indicates a single point in the file, this location will contain full information of starting and ending line numbers and positions. If you click on the location information it will also highlight the specific range in the file.
#### Violation Path
Labelled as **Path**, this property shows either the breadcrumb path to the particular location or the JSON reference path, whatever is available.
#### Violation Contextual Data
Each issue may have dynamic key-value pairs attached with it that represents additional context for the issue:

#### Violation Call Trees
Labelled as **Call Tree**, this property contains complete data about components referencing the current component in question, using `$ref`. As the name suggests, this information is represented as a "tree" where the root node is the current component containing the issue and child nodes are components that are directly referencing this component using `$ref`. Inner children of these child nodes will be nodes directly referencing those nodes using `$ref` and so on. The purpose of a call tree is to help you understand scenarios where the issue may have originated based on **how** it was referenced.
Here is an example of an OpenAPI file where the same object is incorrectly referenced as both a Parameter Object and as a response Schema Object:

Due to this, the referenced component has an error shown at the `required` property value:

This `required` property is allowed to be a boolean if it is referenced as a Parameter Object. But the same `required` property can't be a boolean if it is referenced as a Schema Object. This implies that the error on the property `required` is due to the incorrect response Schema Object reference:

The call tree helps confirm this by showing only the incorrect response Schema Object reference as the root cause for the error on the `required` property:

In this way, if the response schema reference is removed, the issue will be resolved. Without a call tree, it would have been difficult to understand the origin of the issue in the referenced component.
#### Collapse All Nodes
If the information becomes overwhelming you can quickly collapse all nodes of the view using the **Collapse All** option from the right corner of the view title:

After collapsing, all inner nodes will be collapsed and only the root level ones will be shown:

### Learn More View
As the name suggests, this view helps you learn more about a particular issue by providing details about the rule associated with the issue. The information listed here is also available for each rule in our [official documentation of each ruleset](rulesets/overview/). The goal of providing the same information within the extension is to help save the user's time in searching for details to better understand the issue and to easily view hints for resolving it efficiently.

#### Open Rule Details in This View
Details of a rule associated with an issue can be opened from:
- [Workspace Validation Summary](#workspace-validation-summary-view) view. Learn more about it [here](#instances-grouped-by-message).
- [Active Violations](#active-violations-view) view. Learn more about it [here](#violation-message).
- Clicking on the message "code" from the **Problems** view or from the message visible in **Editor** when hovering over a problem. Learn more about it [here](/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace/#finding-additional-information-for-a-validation-issue).
#### Expand Rule Details
If you feel the need to repeatedly consult the Learn More view details or are having trouble navigating through the details because of the small view area, you can choose to expand the details and open them in a separate Editor tab instead. To do this, simply hover near the view title and click on the **Expand Validation Rule Details** button:

Or click on the **View More** option at the bottom of the view:

The details will open in a separate tab as follows:

A detailed breakdown of each property in this view is described below:
| Property | Details |
| -------- | ------- |
| Rule Code | A short, unique identifier of the rule among all available rulesets. |
| Message | The message displayed to the user (unless overridden) if this rule is violated. |
| Description | Describes what the rule expects/dictates. |
| Tips | Tips that can be followed to resolve any issues that occur when the rule is violated. |
| Helpful Links | External links that can help provide more information for understanding the issues that occur when the rule is violated. |
| Rule Id | Unique identifier of the [rule in a ruleset](/validate-lint-apis/overview/#rules-and-rulesets). |
| Ruleset Id | Unique identifier of the [ruleset](/validate-lint-apis/overview/#rules-and-rulesets) to which the rule belongs. |
| Default Severity | The default severity of the message which is displayed when the rule is violated. This severity may be overridden via configuration. |
| Rule Type | Whether the rule is a [validation rule or a linting rule](/validate-lint-apis/overview/#validation-versus-linting-rules). |
| Rule System Type | The [rule system](/validate-lint-apis/overview/#rule-system-of-a-message) that this rule belongs to. |
| Category | A broad semantic category of the rule in the ruleset. |
| Tags | Keywords or tags associated with the rule. |
| Possible Impact On | A list of APIMatic products where you can expect your output to be negatively impacted if this rule is violated. |
#### Copy Rule and Ruleset Id
While [configuring validation](/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace/#configuring-validation), you may feel the need to find out a particular rule's id or its ruleset id. The Learn More view can be helpful in such cases as it allows you to copy the relevant ids. Simply hover near the id values in the view and click on the clipboard (📋) icon to copy the value:

#### Clear the View
To clear the details visible in the view, hover near the view title and click on the **Clear Validation Rule Details** button in the top right corner:

After clicking, details of the rule will be removed from the view until you select any other rule.
### Manage Session View
This view contains details about your current session including your name and email information. This information is obtained after you [authorize the extension](/validate-lint-apis/vs-code-apimatic-extension/overview/#step-1-authorize-yourself-with-apimatic) using your APIMatic account:

The view also provides options to manage the current session e.g. closing the currently open API workspace (if any) or resetting the session completely.
#### Close the API Workspace
If you have an [API workspace currently open](/validate-lint-apis/vs-code-apimatic-extension/setting-up-api-workspace/#opening-an-api-workspace) in the APIMatic API Explorer, you can close it in the extension by using the **Close API Workspace** option:

You will be asked to confirm this action before proceeding:

Once closed, validation and other features will not work until the [workspace is selected as an API workspace again](/validate-lint-apis/vs-code-apimatic-extension/setting-up-api-workspace/#opening-an-api-workspace).
:::note
Closing the API workspace will only remove the extension's access to the workspace folder. The workspace folder will still remain open in VS Code.
:::
#### Reset and Logout
If you wish to log out from the extension, you can click on the **Reset & Logout** button:

You can also use the right corner option from the view title for the same purpose:

You will be asked to confirm this action before proceeding:

To use the extension after logging out, you will need to [authorize yourself with APIMatic](/validate-lint-apis/vs-code-apimatic-extension/overview/#step-1-authorize-yourself-with-apimatic) again.
:::note
Logging out of the extension will only remove your access to the extension functionality and erase personal information from it e.g. name and email, but will not log you out of your APIMatic account elsewhere.
:::
### Help 💡 View
As the name suggests, this view contains all relevant links and options to help you get started with the extension.

You can use the **Start Walkthrough** option to open the [Getting Started APIMatic walkthrough](/validate-lint-apis/vs-code-apimatic-extension/overview/#getting-started---vs-code-walkthrough) in your VS Code. To report any issues, share feedback or get your queries answered, you can reach out to the APIMatic team through the **Contact Us** option or view detailed logs for troubleshooting using the **View Logs** option. You can also navigate to the dedicated extension documentation using the **Open Documentation** option.
## Status Bar Actions
The APIMatic VS Code extension offers various workspace and editor level actions in the status bar:

### Workspace Actions
In VS Code, actions that affect the whole workspace are located on the left. This is also the case for workspace actions provided by APIMatic in the extension:

Following workspace actions are available:
- [Validating the API Workspace](/validate-lint-apis/vs-code-apimatic-extension/validating-api-workspace/).
- [Auto-fixing the API workspace](/validate-lint-apis/vs-code-apimatic-extension/auto-fixing-api-workspace/).
- [Building the API workspace](/validate-lint-apis/vs-code-apimatic-extension/building-api-workspace/).
- [Exporting the API workspace to APIMatic Dashboard](/validate-lint-apis/vs-code-apimatic-extension/exporting-api-workspace/).
- [Transforming the API workspace specification format to another](/validate-lint-apis/vs-code-apimatic-extension/transforming-api-workspace/).
The status bar may also display status messages from time to time when one of the above processes are running:

### Editor Reference Documentation Action
In VS Code, actions that are contextual or language-specific go towards the right. Accordingly, when working with API files in the Editor, the extension can display the API specification format name with a (📖) icon in the right end of the status bar as shown below:

Clicking on it will open the reference documentation linked to the specification. Documentation compatible with VS Code (e.g. GitHub URLs) will open within the extension. Others may use your default web browser to show the documentation:

---
# GitHub App Overview
Source: https://docs.apimatic.io/validate-lint-apis/apimatic-github-app/github-app-overview/
## Overview
The **[APIMatic OpenAPI Linter](https://github.com/apps/apimatic-openapi-linter)** is a GitHub App designed to help you maintain high-quality OpenAPI definitions that are optimized for code generation and API documentation. With over **1200 built-in rules**, this tool validates your OpenAPI definitions to ensure that they meet the standards necessary for generating clean, efficient code and API portals.
This GitHub App integrates seamlessly with your repositories to provide automatic validation of OpenAPI definitions whenever a pull request (PR) is created or updated, ensuring that your definitions are always in top shape.
## Key Features
- **1200+ Built-in Rules**: Lints your OpenAPI definitions with a focus on quality code generation and API documentation.
- **Continuous Integration**: Validates OpenAPI definitions after every pull request to ensure consistent code quality.
- **GitHub Checks**: Displays validation results directly in the PR, helping you identify issues before merging.
- **Detailed Validation Reports**: Generates detailed audit reports that can be shared and reviewed by your team.
- **Multiple Definitions Support**: Supports validating multiple OpenAPI definitions in the same repository.
- **Customizable Configuration**: Tailor the app to your needs, such as enabling/disabling GitHub checks or selecting specific definitions to validate.
## Exploring GitHub App's Components
### Validation Summary in PRs
- **Single OpenAPI Definition**: When a single OpenAPI definition is validated, the app adds a summary comment to the PR showing the validation results.

- **Multiple OpenAPI Definitions**: If your PR modifies multiple OpenAPI definitions, each definition will have a separate validation result displayed in a collapsible format.

- **Merging Multiple Definitions**: If you're merging multiple OpenAPI definitions into one by defining OpenAPI definitions path in `.apimaticsettings.json`, the app validates both individual and merged definitions. The PR comment will include a validation summary for the merged API definition.

- **Detailed Audit Report**: After the validation summary, a link to the full audit report is provided. Click the link to view a detailed breakdown of the validation results, including specific rule violations and suggestions for fixing them.

### Validation Dashboard
Right after your successful installation, you are redirected to the dashboard that lists all the repositories where the app is installed along with all OpenAPI definitions available in each repository.
The Dashboard also enables you to validate any OpenAPI file and see the detailed validation report.

### GitHub Checks Integration
- **Successful Validation**: If all checks pass, you can merge the PR.
- **Validation Errors**: If the validation fails, GitHub will mark the check as failed, but you can choose to skip the checks if `IgnoreValidationErrors` is set to `true`.
- **Configuration Errors**: If there are any configuration issues (unauthorized installation, missing configuration file, or incorrect file paths), the app will provide appropriate notifications.

---
# Installing GitHub App
Source: https://docs.apimatic.io/validate-lint-apis/apimatic-github-app/installing-github-app/
## Pre-requisites
Before getting started, ensure you have the following:
- **Repository Permissions**: You must have the appropriate permissions to install the app on your GitHub repository. If you're a member of an organization, the organization owner must approve the installation.
- **APIMatic Account**: You need a free APIMatic account. Create one at [APIMatic.io](https://www.apimatic.io).
## Getting Started
### Step 1: Install the App
1. Go to the **[APIMatic OpenAPI Linter](https://github.com/apps/apimatic-openapi-linter)** GitHub App page and click "Install" to install the app.
2. Choose the GitHub account or organization where you want to install the app.
3. Select the repositories where you want the app to run.
4. Authorize the app with your APIMatic account (you will be automatically redirected to APIMatic's login page). Don't close the page until the authorization is successful and you see the dashboard.

:::note
If you're installing on an organization, the organization owner must approve the installation.

:::
### Step 2: Configure the App (Optional)
Once installed, the app automatically triggers the validation on each pull request creation or synchronization.
#### Define OpenAPI Definition Paths
If you want to validate specific OpenAPI files or merged OpenAPI definitions, you may use `.apimaticsettings.json` file to define OpenAPI definition paths explicitly.
Here's an example:
```json
{
"OpenAPIDefinitionPaths": [
"path/to/openapi/directory",
"path/to/openapi.yaml",
"path/to/openapi.json"
]
}
```
This configuration tells the linter which OpenAPIs to validate.
#### Skip Specific OpenAPI Definitions from Validation
In certain cases, you might want to exclude specific OpenAPI definition files from the validation process, especially when you haven't explicitly defined `OpenAPIDefinitionPaths` and the GitHub App automatically detects all modified OpenAPI definitions in a pull request.
To skip validation for specific files or directories, use the `SkipOpenAPIDefinitionPaths` option in your configuration file. This is useful when you want to prevent validation of files that are still in progress, deprecated, or not relevant to the current workflow.
Here's an example:
```json
{
"SkipOpenAPIDefinitionPaths": [
"path/to/openapi/directory",
"path/to/openapi.yaml",
"path/to/openapi.json"
]
}
```
Each entry in the array can point to a specific file or an entire directory. When specified, these paths will be excluded from validation even if they're detected as modified in a pull request.
#### Configure GitHub Checks
If you have branch protection rules that prevent merging PRs with failing checks, you can disable the GitHub checks by adding the following to your configuration file:
```json
{
"IgnoreValidationErrors": true
}
```
:::note
`IgnoreValidationErrors` is set to `false` by default, meaning GitHub checks will fail on validation errors. You can override this behavior by setting `IgnoreValidationErrors` to `true`.
:::
## How It Works
After installation and configuration, the APIMatic OpenAPI Linter GitHub App automatically triggers validation for every pull request (PR) created or updated.
### Validation Process
1. When a PR is created or synchronized, the app runs the validation process in the background.
2. The results are displayed in the **PR Comment** section.
3. If validation passes, the PR can be merged. If validation fails, the PR will be blocked from merging (unless you don't have branch protection rules enabled or you opt to skip validation with `IgnoreValidationErrors` set to `true`).
## Customizing Validation
APIMatic's OpenAPI Linter uses a highly configurable validation engine, allowing you to configure the checks based on your needs.
- **Enabling/Disabling Rules**: [Customize the validation](../../configuring-validation/) by enabling or disabling specific rules or entire rulesets in your configuration file.
- **Custom Rules**: You can [add custom validation rules](../../adding-your-own-rules/) to meet specific requirements for your API definitions.
### Example of Custom Rule Configuration
```json
{
"Id": "my-custom-ruleset",
"Rules": [
{
"Id": "max-operation-id-length-30",
"VerificationMethod": "Length",
"Targets": [
{
"JsonPath": "$.paths.*.*.operationId"
}
],
"VerificationMethodArgs": {
"Maximum": 30
},
"Message": "Operation id is too long."
}
]
}
```
This example shows how to enable a custom rule with specific parameters.
## Troubleshooting
### Common Issues
1. **Unauthorized Installation**: Make sure the GitHub app is installed correctly on the desired repositories and that the APIMatic account is properly linked.
2. **Invalid Configuration File**: Ensure that the file is syntactically correct and that its content is accessible.
3. **Incorrect OpenAPI Paths**: Double-check the file paths in your configuration file to ensure they're correct.
4. **Failed Checks**: If validation fails, check the PR comments or the detailed audit report for more information on which rules failed.
For any further questions or support, visit our [Support Page](https://www.apimatic.io/contact).
---
# Configuring Validation
Source: https://docs.apimatic.io/validate-lint-apis/configuring-validation/
You can configure the validation process as per your requirements by providing a [validation configuration](#validation-configuration-object) in the [APIMatic's Metadata file](manage-apis/apimatic-metadata.md) which needs to be uploaded along with the API definition/specification:
```json
{
"ValidationConfiguration": {
"SkipLinting": true
}
}
```
The capabilities that this configuration provides is as follows:
* Skipping some rules of a ruleset, the entire ruleset or a group of rulesets e.g. skipping all linting rulesets.
* Enabling only some rules from a ruleset and skipping the rest.
* Enabling rules of a ruleset that are kept disabled by default either because of low priority or any other reason.
* Overriding severity of rules depending on needs e.g. converting a warning into error.
:::note
The capabilities differ w.r.t. whether the ruleset is meant for validation or linting. **Validation rules/rulesets can only be enabled but not skipped nor can their severity be changed**.
:::
### Validation Configuration Object
The available properties and their respective types are as follows:
| Property | Type | Details |
| -------- | ---- | ------- |
| SkipCodeGenerationChecks | Boolean | When set to `true`, linting checks associated with code/SDK generation will not be performed. Code generation checks are enabled by default unless you are performing only transformations in the [API Transformer](https://apimatic.io/transformer). |
| SkipLinting | Boolean | **Default**: `false`. When set to `true`, all linting rulesets will be entirely skipped and only validation rulesets will be applied. |
| Rulesets | Map[String, [Ruleset Configuration](#ruleset-configuration-object)] | Configuration for each ruleset. The key is the unique id/code that identifies a ruleset and the value provides required configurations for that ruleset. The rulesets not specified here will work with default behavior. |
**Example 1** - Skip all linting rules:
```json
{
"SkipLinting": true
}
```
**Example 2** - Configuring a ruleset:
The following configuration will let you skip the rule `no-ambiguous-path` from the `openapi-v3-standards-linting` ruleset and also downgrade the severity of all rules in the ruleset from `Warning` to `Information`. Here, `no-ambiguous-path` and `openapi-v3-standards-linting` are rule and ruleset ids respectively.
```json
{
"Rulesets": {
"openapi-v3-standards-linting": {
"Severity": "Information",
"Rules": {
"Skip": ["no-ambiguous-path"]
}
}
}
}
```
### Ruleset Configuration Object
This configuration object will let you configure a single ruleset. The available properties and their respective types are as follows:
| Property | Type | Details |
| -------- | ---- | ------- |
| Skip | Boolean | **Default**: `false`. When set to `true`, all checks from the ruleset will be skipped/ignored. Only applicable for linting rulesets. |
| Severity | [Rule Severity](/validate-lint-apis/overview/#severity-of-messages) | The severity set here will override severity level of all rules in the ruleset. Only applicable for linting rulesets. If a rule in this ruleset has severity overrides provided in the [rules configuration of the ruleset](#ruleset-rules-configuration-object), the rule level severity configuration will take precedence. |
| FilePath | String | Relative path to a [custom ruleset file](/validate-lint-apis/adding-your-own-rules/#creating-and-applying-a-custom-ruleset-file). |
| Rules | [Rules Configuration](#ruleset-rules-configuration-object) | Configuration for specific rules of the ruleset can be provided here. Rules not configured explicitly or implicitly here will work with default behavior. |
**Example**
```json
{
"Skip": true
}
```
### Ruleset Rules Configuration Object
This configuration will let you configure rules of a ruleset. The available properties and their respective types are as follows:
| Property | Type | Details |
| -------- | ---- | ------- |
| EnableAll | Boolean | **Default**: `false`. When set to `true`, all rules of the ruleset will be applied including those that may be disabled by default and any configurations provided under `EnableOnly` or `Enable` will be ignored. |
| EnableOnly | Array[String] | If a list of rule ids/codes is provided, only those rules from the ruleset will be applied and others will be skipped regardless of any default configuration or configurations provided using the `Enable` setting. Only applicable for linting rulesets. |
| Enable | Array[String] | A list of rule ids/codes to enable. This can be used to enable rules from a ruleset that may be disabled by default for any reason (low priority or any other). The default behavior will be used for rules not specified here. |
| Skip | Array[String] | If a list of rule ids/codes is provided, they will not be applied. Only applicable for linting rulesets. Rules listed here will be ignored regardless of any configurations provided under `EnableAll`, `EnableOnly` or `Enable`. |
| Severity | Map[String, [Rule Severity](/validate-lint-apis/overview/#severity-of-messages)] | This will let you override severity of a rule e.g. changing an error to warning. Only applicable for linting rulesets. The key should be the id/code of the rule you wish to change severity of. |
**Example 1** - Enable only selected rules from a ruleset:
```json
{
"EnableOnly": [
"unique-case-insensitive-header-parameter-names", //using rule id
"OPENAPI3STANDARDS_L065" //using rule code
]
}
```
**Example 2** - Skip a rule from a ruleset:
```json
{
"Skip": [
"no-ambiguous-path"
]
}
```
**Example 3** - Changing severity of a rule:
```json
{
"Severity": {
"valid-schema-example": "Error"
}
}
```
### Complete Validation Configuration Example
The examples above show individual configuration objects in isolation. Below is a complete example showing how all the pieces fit together inside the [APIMatic's Metadata file](manage-apis/apimatic-metadata.md). This is the full structure that should be uploaded alongside your API definition/specification:
```json
{
"ValidationConfiguration": {
"SkipCodeGenerationChecks": false,
"SkipLinting": false,
"Rulesets": {
"openapi-v3-standards-linting": {
"Skip": false,
"Severity": "Information",
"Rules": {
"EnableAll": false,
"EnableOnly": [
"unique-case-insensitive-header-parameter-names",
"no-ambiguous-path",
"valid-schema-example"
],
"Skip": [
"no-ambiguous-path"
],
"Severity": {
"valid-schema-example": "Error"
}
}
},
"openapi-v3-apimatic-linting": {
"Skip": true
}
}
}
}
```
In this example:
* `SkipCodeGenerationChecks` and `SkipLinting` are set at the top level of the `ValidationConfiguration` object.
* Two rulesets are configured under `Rulesets`: `openapi-v3-standards-linting` and `openapi-v3-apimatic-linting`.
* For `openapi-v3-standards-linting`, the default severity is downgraded to `Information`, only specific rules are enabled via `EnableOnly`, the `no-ambiguous-path` rule is skipped, and the `valid-schema-example` rule severity is overridden to `Error`.
* The `openapi-v3-apimatic-linting` ruleset is entirely skipped.
:::note
You don't need to include every property shown above. Only specify the properties you want to customize. All others use their default values.
:::
---
# Adding Your Own Rules
Source: https://docs.apimatic.io/validate-lint-apis/adding-your-own-rules/
:::note
This feature is currently **only supported** for OpenAPI `v2.0` and `v3.0` files and works only when the `UseStrictValidation` [import setting](/web-dashboard-retired) is set to `true`.
:::
If you are looking to add your own rules beyond the capabilities provided by our built-in rulesets, you can create a custom ruleset and apply that on your API specification document.
### How Do Custom Rules Work?
In a custom ruleset, you can configure rules that use built-in methods to verify one or more of the selected target components. If the target component fails verification, a lint warning will be logged. The severity of these messages as well as other details can be easily configured to suit your needs when defining the rules.
### Creating and Applying a Custom Ruleset File
Custom rules need to be defined inside a custom ruleset file placed at a path relative to the main API specification document. The file must use valid JSON/YAML syntax and contain the [Ruleset Object](#ruleset-object) at root level.
**Example**:
```json
{
"Id": "my-custom-ruleset",
"Rules": [
{
"Id": "max-operation-id-length-30",
"VerificationMethod": "Length",
"Targets": [
{
"JsonPath": "$.paths.*.*.operationId"
}
],
"VerificationMethodArgs": {
"Maximum": 30
},
"Message": "Operation id is too long."
}
]
}
```
In order to apply a custom ruleset on your API specification document, it needs to be referenced from within a APIMatic Metadata file's [validation configuration](/validate-lint-apis/configuring-validation) as shown below:
```json
{
"ValidationConfiguration": {
"Rulesets": {
"my-custom-ruleset": {
"FilePath": "/path/to/ruleset/file"
}
}
}
}
```
### Ruleset Object
This object represents the root object that's placed in a custom ruleset file. The available properties are listed below:
| Property Name | Type | Description |
| ------------- | ---- | ----------- |
| Id | String | **Required**. Unique identifier of the ruleset. Use only alphanumeric characters or dashes. |
| Rules | Array[[Custom Lint Rule Object](#custom-lint-rule-object)] | **Required**. List of custom rule definitions that need to be applied on target components. The list must contain at least one rule definition. |
| Name | String | A short user-friendly name of the ruleset. |
| Description | String | A detailed description of the ruleset. |
| Severity | [Severity](/validate-lint-apis/overview/#severity-of-messages) | **Default**: `Warning`. Global declaration of severity of all rules. Can be overridden at rule level. |
| ExternalLinks | Array[String] | List of external links that may provide additional details about the ruleset. |
| Tags | Array[String] | Tags that will be shown along with rules of the ruleset for more context and to facilitate searching. |
### Custom Lint Rule Object
The available properties to describe a custom rule are listed below:
| Property Name | Type | Description |
| ------------- | ---- | ----------- |
| Id | String | **Required**. Unique identifier of the rule across the ruleset. Use only alphanumeric characters or dashes. |
| Targets | Array[[Rule Target Object](#rule-target-object)] | **Required**. Identifies the target components that need to be verified with the current rule. The list must contain at least one target. |
| VerificationMethod | [Verification Method](#verification-methods) | **Required**. Name of the pre-defined method that needs to be applied on the selected object as part of the rule verification. |
| VerificationMethodArgs | Map[String, Any] | Key-value pairs containing arguments to pass to the verification method where the key represents the argument name. Depending upon the selected `VerificationMethod`, one or more arguments may be required. |
| Message | String | The message that needs to be displayed during the validation process if a violation of the rule is found. If not specified, a default message will be used. It's recommended to keep this message short. |
| Severity | [Severity](/validate-lint-apis/overview/#severity-of-messages) | By default, the ruleset level global severity will be applicable (`Warning` by default). The global severity can be overridden with the severity specified here. |
| Name | String | Short user-friendly name for the rule. |
| Description | String | Describes the rule in detail. For example, it can specify what kind of verification is expected and on what types of target components. |
| ExternalLinks | Array[String] | External links that can provide more details about the current rule. |
| Hints | Array[String] | Any tips/suggestions that can help someone easily resolve the violations of the current rule. |
| Tags | Array[String] | Tags that can be shown with the rule for more context and to help in searching as well. |
### Rule Target Object
The available properties to help select rule target components are listed below:
| Property Name | Type | Description |
| ------------- | ---- | ----------- |
| JsonPath | String | **Required**. A valid JSONPath expression that helps locate and select the components on which the rule needs to be applied. |
| KeysOnly | Boolean | The target objects will be converted into a list of keys (extracted from the top level of an object). **Only applicable if selected targets are objects.** |
| SelectWithKeys | Array[String] | For each target object, only properties with specified keys will be evaluated. Mutually exclusive with `IgnoreWithKeys`. **Only applicable if selected targets are objects.** |
| IgnoreWithKeys | Array[String] | For each target object, properties with specified keys won't be evaluated. Mutually exclusive with `SelectWithKeys`. **Only applicable if selected targets are objects.** |
### Verification Methods
Available verification methods are listed below:
| Method Name | Description |
| ----------- | ----------- |
| Pattern | More details can be found [here](/validate-lint-apis/verification-methods/pattern). |
| Order | More details can be found [here](/validate-lint-apis/verification-methods/order). |
| Length | More details can be found [here](/validate-lint-apis/verification-methods/length). |
| Required | More details can be found [here](/validate-lint-apis/verification-methods/required). |
---
# Overview
Source: https://docs.apimatic.io/rulesets/overview/
## Available Rulesets
API description files imported into APIMatic are [validated and linted](/validate-lint-apis/overview) against the rulesets listed below, along with their reference documentation:
* [APIMatic](/rulesets/apimatic)
* [OpenAPI/Swagger](/rulesets/openapi)
* [API Blueprint](/rulesets/api-blueprint)
* [RAML](/rulesets/raml)
* [Postman](/rulesets/postman)
* [HAR](/rulesets/har)
* [Insomnia](/rulesets/insomnia)
* [WADL](/rulesets/wadl)
* [WSDL](/rulesets/wsdl)
* [I/O Docs](/rulesets/i-o-docs)
* [Google Discovery](/rulesets/google-discovery)
* [Data](/rulesets/data)
---
# APIMatic Rulesets
Source: https://docs.apimatic.io/rulesets/apimatic/
The list of rulesets currently used by APIMatic for validating any API specification document is given below. These may include additional checks that a specification's standard may not enforce itself but are necessary to ensure good quality output from various APIMatic's products like Code Generator, DX Portal generator, Transformer, etc.
## Validation Rulesets
* [Input File Validation](/rulesets/input-file-validation/overview)
* [Metadata File Validation](/rulesets/metadata-validation/overview)
* [User Custom Ruleset Syntax Validation](/rulesets/custom-ruleset-syntax-validation/overview)
* [User Custom Ruleset Validation](/rulesets/custom-ruleset-validation/overview)
* [APIMatic Post-Processing Validation](/rulesets/apimatic-post-processing-validation/overview)
* [APIMatic Post-Processing Validation for Code-Generation](/rulesets/apimatic-post-processing-codegen-validation/overview)
* [APIMatic Preliminary Validation](/rulesets/apimatic-preliminary-validation/overview)
* [APIMatic Validation for Code Generation](/rulesets/apimatic-codegen-validation/overview)
* [APIMatic Gavel Validation](/rulesets/apimatic-gavel-validation/overview)
* [APIMatic Process Validation](/rulesets/apimatic-process-validation/overview)
* [APIMatic Syntax Validation](/rulesets/apimatic-syntax-validation/overview)
## Linting Rulesets
* [APIMatic Preliminary Linting](/rulesets/apimatic-preliminary-linting/overview)
* [APIMatic Linting for Portal Generation](/rulesets/apimatic-docs-linting/overview)
---
# OpenAPI Rulesets
Source: https://docs.apimatic.io/rulesets/openapi/
The list of rulesets currently used by APIMatic for validating OpenAPI documents (`v1.x`, `v2.0`, `v3.x`) is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [OpenAPI v3 Syntax Validation](/rulesets/openapi-v3-syntax-validation/overview)
* [OpenAPI v3 Standards Validation](/rulesets/openapi-v3-standards-validation/overview)
* [OpenAPI/Swagger v2 Standard Validation](/rulesets/swagger-v2-standards-validation/overview)
* [OpenAPI/Swagger v2 Syntax Validation](/rulesets/swagger-v2-syntax-validation/overview)
* [OpenAPI/Swagger v1 Validation](/rulesets/swagger-v1-validation/overview)
## Linting Rulesets
* [OpenAPI v3 Syntax Linting](/rulesets/openapi-v3-syntax-linting/overview)
* [OpenAPI v3 Standards Linting](/rulesets/openapi-v3-standards-linting/overview)
* [OpenAPI v3 APIMatic Linting](/rulesets/openapi-v3-apimatic-linting/overview)
* [OpenAPI v3 APIMatic Syntax Linting](/rulesets/openapi-v3-apimatic-syntax-linting/overview)
* [OpenAPI v3 APIMatic Linting for Code Generation](/rulesets/openapi-v3-codegen-linting/overview)
* [OpenAPI v3 APIMatic Syntax Linting for Code Generation](/rulesets/openapi-v3-codegen-syntax-linting/overview)
* [OpenAPI v3 APIMatic Linting for Portal Generation](/rulesets/openapi-v3-docsgen-linting/overview)
* [OpenAPI v3 APIMatic Syntax Linting for Portal Generation](/rulesets/openapi-v3-docsgen-syntax-linting/overview)
* [OpenAPI v2 APIMatic Linting](/rulesets/swagger-v2-apimatic-linting/overview)
* [OpenAPI v3 Agentic Tools Linting](/rulesets/openapi-v3-agentic-tools-linting/overview)
---
# API Blueprint Rulesets
Source: https://docs.apimatic.io/rulesets/api-blueprint/
The list of rulesets currently used by APIMatic for validating API Blueprint documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [API Blueprint Validation](/rulesets/api-blueprint-validation/overview)
---
# RAML Rulesets
Source: https://docs.apimatic.io/rulesets/raml/
The list of rulesets currently used by APIMatic for validating RAML documents (`v0.8`, `v1.0`) is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [RAML Validation](/rulesets/raml-validation/overview)
---
# Postman Rulesets
Source: https://docs.apimatic.io/rulesets/postman/
The list of rulesets currently used by APIMatic for validating Postman documents (e.g. Postman Collections `v1.0` or `v2.x`, Postman Data Dump, Postman Environment file, etc.) is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [Postman Validation](/rulesets/postman-validation/overview)
---
# HAR Rulesets
Source: https://docs.apimatic.io/rulesets/har/
The list of rulesets currently used by APIMatic for validating HAR documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [HAR Validation](/rulesets/har-validation/overview)
---
# Insomnia Rulesets
Source: https://docs.apimatic.io/rulesets/insomnia/
The list of rulesets currently used by APIMatic for validating Insomnia Export format documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [Insomnia Validation](/rulesets/insomnia-validation/overview)
---
# WADL Rulesets
Source: https://docs.apimatic.io/rulesets/wadl/
The list of rulesets currently used by APIMatic for validating WADL `v2006` and `v2009` documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [WADL Validation](/rulesets/wadl-validation/overview)
---
# WSDL Rulesets
Source: https://docs.apimatic.io/rulesets/wsdl/
The list of rulesets currently used by APIMatic for validating WSDL `v1.1` documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [WSDL Validation](/rulesets/wsdl-validation/overview)
---
# I/O Docs Rulesets
Source: https://docs.apimatic.io/rulesets/i-o-docs/
The list of rulesets currently used by APIMatic for validating I/O Docs documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [I/O Docs Validation](/rulesets/io-docs-validation/overview)
---
# Google Discovery Rulesets
Source: https://docs.apimatic.io/rulesets/google-discovery/
The list of rulesets currently used by APIMatic for validating Google Discovery documents is provided below. These include rules defined by the standard as well as additional checks enforced by APIMatic for a better output.
## Validation Rulesets
* [Google Discovery Validation](/rulesets/google-discovery-validation/overview)
---
# Data Rulesets
Source: https://docs.apimatic.io/rulesets/data/
The list of rulesets currently used by APIMatic for validating data documents (e.g. JSON data, JSON schema, YAML data, XML data, XML schema) is provided below. These rulesets help verify compatibility of such documents with APIMatic as well as ensure they follow valid syntax.
## Validation Rulesets
* [JSON Validation](/rulesets/json-validation/overview)
* [JSON Schema Validation](/rulesets/json-schema-validation/overview)
* [YAML Semantic Validation](/rulesets/yaml-semantic-validation/overview)
* [YAML Syntax Validation](/rulesets/yaml-syntax-validation/overview)
* [XML Validation](/rulesets/xml-validation/overview)
---
# Specification Extensions Overview
Source: https://docs.apimatic.io/specification-extensions/spec-extensions-overview/
APIMatic allows you to extend the functionality of your OpenAPI/Swagger, API Blueprint and RAML specification files to cater to features not supported in the standard API specification. This allows you to configure APIMatic products including API Transformer, Code Generator and more. Some of the extensions also enable you to utilize parameter types for resources that aren't natively available otherwise.
APIMatic offers [Code Generation settings](/generate-sdks/customize-sdks/codegen-settings/codegen-settings-overview) to configure generic code styling, endpoint settings, model settings, continuous integration settings and more during code generation. Similarly, [Server Configurations](/web-dashboard-retired) can be used to create multiple environments, multiple servers, and server urls with template parameters.
OpenAPI/Swagger supports [vendor extensions](https://swagger.io/docs/specification/openapi-extensions/) and RAML supports [annotations](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#annotations), so this allows users to extend their API specifications to utilize code generation, test generation and server configuration.
The specification extensions are supported through the following features of APIMatic:
1. [API Transformer](api-transformer/overview-transformer.md)
2. [APIMatic API](pathname:///platform-api#/http/getting-started)
3. [Importing API Specification](/web-dashboard-retired)
## Supported Extensions
You can find detailed documentation for APIMatic extensions available for OpenAPI/Swagger, API Blueprint and RAML:
- [OpenAPI CodeGen Extensions](swagger-codegen-extensions.md)
- [OpenAPI Server Configuration Extensions](swagger-server-configuration-extensions.md)
- [OpenAPI Test Cases Extensions](swagger-test-cases-extensions.md)
- [API Blueprint Extensions](blueprint-extensions.md)
- [RAML Annotations](raml-apimatic-annotations.md)
---
# OpenAPI CodeGen Extensions
Source: https://docs.apimatic.io/specification-extensions/swagger-codegen-extensions/
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
OpenAPI/Swagger (`v2.0`, `v3.x`) facilitates third-party vendors to implement tool-specific extensions. These extensions allow customizing behaviors beyond simple API definitions. We at APIMatic also offer extensions that are specific to Code Generation and can be specified within your OpenAPI definition file. These extensions allow you to customize the APIMatic code generation engine as per your requirements. The following documentation discusses the extensions available and how to use them.
## Code Generation Settings and OpenAPI Extensions
In the case of Swagger/OpenAPI, we provide extensions that you can use within your OpenAPI definition to specify code generation settings and get the desired customizability. We also provide similar extensions for API Blueprint whose details can be viewed at [API Blueprint Extensions](specification-extensions/blueprint-extensions.md). The extensions are supported by both the "Import" API operation, as well as by our Code Generation as a Service API.
## CodeGen Extensions and How To Use Them
We offer the following CodeGen extensions:
1. [Advanced Settings for Endpoints](#advanced-settings)
2. [Additional Headers](#additional-headers)
3. [Basic Authentication Extensions](#basic-authentication-extensions)
4. [OAuth 2.0 Extensions](#oauth-20-extensions)
5. [Discriminator Value Extension](#discriminator-value-extension)
6. [Enumeration Extensions](#enumeration-extensions)
7. [Datetime Extensions](#datetime-extensions)
8. [Dynamic Response Extension](#dynamic-response-extension)
9. [Exception Model Name Extension](#exception-model-name-extension)
10. [Example Extensions](#example-extensions)
11. [API Metadata Extensions](#api-metadata-extensions)
12. [API Filtering Roles Extension](#api-filtering-roles-extension)
13. [Applied Authentication Options Extension](#applied-authentication-options-extension)
13. [Pagination Extension](#pagination-extension)
14. [Webhook Group Extension](#webhook-group-extension)
15. [Callback Group Extension](#callback-group-extension)
16. [SSE Sentinel Extension](#sse-sentinel-extension)
### Advanced Settings
APIMatic allows further customization of endpoints (called operations in OpenAPI) through the Advanced Settings extensions. These extensions can be specified inside the Operation Object ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#operationObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#operationObject)).
Two extensions are currently available which are defined below:
1. [Operation Settings](#operation-settings)
2. [Multiple Body Parameters Setting](#multiple-body-parameters-setting)
3. [Deprecation Details](#deprecation-details)
4. [Overriding Parameter Names](#overriding-parameter-names)
#### Operation Settings
These settings are specified using property name `x-operation-settings`. See an example as follows:
```json
"paths": {
"/pets": {
"post": {
...
"operationId": "addPet",
"x-operation-settings": {
"collectParameters": false,
"allowDynamicQueryParameters": true,
"allowDynamicFormParameters": false,
"isMultiContentStreaming": false,
"methodName": "create",
"groupName": "pets",
"forceRetries": true
}
}
}
}
```
Details of the properties available within this extension are given below:
| Property | Type | Purpose |
| -------- | ---- | ------- |
| `collectParameters` | Boolean | When true, this operation's parameters are expected to passed as a collection. For example in PHP, the generated method expects a Map containing parameters as Key-Value pairs. This is currently implemented for PHP, Python, GO, and Objective-C. |
| `useModelPostfix` | Boolean | When true, a postfix "Model" is appended to all classes generated from schemas. |
| `allowDynamicQueryParameters` | Boolean | When true, the generated method has an additional Map input, which may contain dynamic number of query parameters as Key-Value pairs. |
| `allowDynamicFormParameters` | Boolean | When true, the generated method has an additional Map input, which may contain dynamic number of form parameters as Key-Value pairs. |
| `isMultiContentStreaming` | Boolean | When true, it indicates that this operation is a streaming endpoint. For example, Twitter Streaming API endpoints. |
| `parameterCollectionName` | String | Represents the name of the model that represents CollectedParameters. |
| `methodName` | String | When specified, it's used instead of the operation name (extracted from the operation ID/summary) for generating method names in SDKs. While an operation ID in OpenAPI needs to be unique across the complete API, the method name should ideally be unique among all operations in a particular path item only. |
| `responseMapping` | [Response Mapping Object](#response-mapping-object) | Response mapping strategy to use for mapping the HTTP response to the result passed to the endpoint caller in an SDK. This will override the response mapping specified in the CodeGen settings if any. |
| `groupName` | String | When specified, it's used for generating the endpoint's group name in SDKs/docs instead of the first tag name specified in an Operation object. |
| `forceRetries` | Boolean | When set to `true`, the SDKs can force retry an endpoint regardless of whether it's idempotent or not. If `false`, the endpoints won't be retried. By default, only idempotent endpoints are retried. |
| `errorTemplates` | Map [String, String] | Custom-templated messages that can be provided for overriding default exception messages thrown in SDKs for error responses. More details can be found [here](#error-templates). Note, that an error template specified at operation level will override the one specified under [CodeGen settings](/generate-sdks/customize-sdks/codegen-settings/exception-settings/#error-templates) for the same error template key. |
| `skipAdditionalHeaders` | Boolean | When set to `true`, any [additional headers](#additional-headers) applied at API level will be ignored for the current endpoint. This is set to `false` by default. |
#### Multiple Body Parameters Setting:
Since OpenAPI doesn't allow defining multiple body parameters, you can use this setting to help unwrap any body parameter into multiple body parameters for Code Generation purposes. Essentially, this setting is a `boolean` flag specified using the name `x-unwrap-body` inside the Operation object. You can simply define a schema in the OpenAPI/Swagger file (generally inside `#/definitions` or `#/components/schemas` depending on the OAS/Swagger version) where schema fields will represent the body parameters. Link this schema in the body parameter definition of the Operation object and set the flag to `true`. We will then automatically unwrap the body schema into multiple body parameters during the import process.
A usage example of the flag described above is shown below:
```json
"post": {
"summary": "Multiple body parameters",
"parameters": [{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/bodySchema"
}
}],
"x-unwrap-body": true
}
```
Here the schema fields of `bodySchema` represent the actual body parameters.
#### Deprecation Details:
This extension can be used inside the Operation object using key `x-deprecation-details`. This extension allows you to define additional details for your operation if it has been declared as deprecated using the OAS `deprecated` property. The properties available for describing the deprecated operation in more detail are:
| Property | Type | Purpose |
| -------- | ---- | ------- |
| message | String | Helps describe any additional information about the deprecated operation for example reason, alternative, etc. |
| deprecatedInVersion | String | Helps specify the version in which this item was deprecated. |
A usage example of the above extension is given below:
```json
"post": {
...
"operationId": "addPet",
"summary": "Deprecated operation",
"deprecated": true,
"x-deprecation-details": {
"message": "This operation is deprecated. Use createPet",
"deprecatedInVersion": "2.0"
}
}
```
#### Overriding Parameter Names
To enhance the usability and clarity of parameter names in your SDKs and API documentation, you can use the parameter-level extension `x-unique-name`. This extension allows you to:
1. **Resolve Duplicate Names**: Provide a unique secondary name for parameters that share the same name, ensuring clarity in the Code and API portal.
2. **Simplify Long or Unfriendly Names**: Replace overly lengthy or technical parameter names with a user-friendly alternative, improving the overall developer experience.
##### Key Considerations
- The name specified in `x-unique-name` must not conflict with any existing parameter names in the API.
- This secondary name is **only used for display purposes** in the Code and API portal and doesn't alter the actual API calls or their behavior.
##### Example
Here's an example of how to use `x-unique-name`:
```yaml
parameters:
- name: id
in: query
required: true
schema:
type: string
x-unique-name: userId
- name: id
in: path
required: true
schema:
type: string
x-unique-name: orderId
```
In the example above:
- Both `id` parameters are distinguished using `x-unique-name` as `userId` and `orderId` in the Code and API documentation.
- API consumers will see these friendly names in the SDKs and the portal, but the actual parameter name remains `id` for API requests.
This extension ensures your Code and API documentation is intuitive and developer-friendly without impacting the technical implementation.
### Additional Headers:
APIMatic allows defining global headers that are sent with every API call using the Addition Headers extension. These headers are in addition to any headers required for authentication or defined as parameters. These headers can be specified inside the Security Scheme Object ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securitySchemeObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#securitySchemeObject)) using property name `x-additional-headers`. See an example below:
```json
"securityDefinitions": {
"basicAuth": {
"type": "basic",
"x-additional-headers": [
{
"name": "api-version",
"description": "The version number indicator for the API",
"default": "1.1"
},
{
"name": "sdk-version",
"description": "The version number indicator for the SDK",
"default": "1.1.0.1"
}
...
]
}
}
```
```json
"securitySchemes": {
"basicAuth": {
"type": "http",
"scheme": "basic",
"x-additional-headers": [
{
"name": "api-version",
"description": "The version number indicator for the API",
"schema": {
"default": "1.1"
}
},
{
"name": "sdk-version",
"description": "The version number indicator for the SDK",
"schema": {
"default": "1.1.0.1"
}
}
...
]
}
}
```
An additional header is defined using a subset of the properties of the Parameter Object ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameterObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#parameterObject)). The available properties are:
| Property | Type | Purpose |
| -------- | ---- | ------- |
| name | String | Name of the header |
| description | String | Any details regarding the header |
| default | String | Any default value for the header |
### Basic Authentication Extensions
By default, basic authentication requires `username` and `password` as input parameters. If you need to override the names of these parameters for code generation, you can use the extensions described below:
| Extension | Type | Description |
| --------- | ---- | ----------- |
| `x-rename-username-as` | String | The alternate name for `username` parameter for example `name` |
| `x-rename-password-as` | String | The alternate name for `password` parameter for example `secret` |
Both the above extensions can be used inside the Security Scheme Object ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securitySchemeObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#securitySchemeObject)) as follows:
```json
"securityDefinitions": {
"basicAuth": {
"type": "basic",
"x-rename-username-as": "name",
"x-rename-password-as": "secret"
}
}
```
```json
"securitySchemes": {
"basicAuth": {
"type": "http",
"scheme": "basic",
"x-rename-username-as": "name",
"x-rename-password-as": "secret"
}
}
```
### OAuth 2.0 Extensions:
APIMatic also offers several extensions to help you configure your OAuth 2.0 security definition. For v2.0, you can use these extensions inside the [Security Scheme Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securitySchemeObject) and for v3.x inside the [OAuth Flow Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#oauthFlowObject) as follows:
```json
"securityDefinitions": {
"oauth2": {
"type": "oauth2",
"flow": "password",
"tokenUrl": "http://example.com/tokenurl",
"x-skip-client-authentication": false,
"x-oauth2-clientid-example": "clientid",
"x-oauth2-clientsecret-example": "clientsecret",
"x-oauth2-credentials-placement": "header",
"x-oauth2-username-example": "username",
"x-oauth2-password-example": "password"
}
}
```
```json
"securitySchemes": {
"oauth2": {
"type": "oauth2",
"flows": {
"password": {
"tokenUrl": "http://example.com/tokenurl",
"x-skip-client-authentication": false,
"x-oauth2-clientid-example": "clientid",
"x-oauth2-clientsecret-example": "clientsecret",
"x-oauth2-credentials-placement": "header",
"x-oauth2-username-example": "username",
"x-oauth2-password-example": "password",
"x-allow-additional-oauth-fields": true,
"x-additional-oauth-fields": {
"prop1":{
"type": "string"
},
"prop2":{
"type": "integer"
}
}
}
}
}
}
```
The detailed explanation of all these extensions is given below:
| Extension | Type | Description | Applicable to Flows |
| -------- | ---- | ------- | ---- |
| `x-skip-client-authentication` | Boolean | The OAuth 2.0 flow of resource owner password credentials will normally involve client app authentication using Client Id and Client Secret. However, if you want to skip this authentication for Code Generation purposes, you can set its value to `true` | `password` |
| `x-oauth2-clientid-example` | String | Specifies a value that can be used as an example or demo client ID | `*password`, `implicit`, `application`, `accessCode` |
| `x-oauth2-clientsecret-example` | String | Specifies a value that can be used as an example or demo client secret | `*password`, `implicit`, `application`, `accessCode` |
| `x-oauth2-credentials-placement` | String | Specifies where the client credentials (client ID and secret) are sent when calling the token endpoint. Use `header` to send them in the HTTP Basic `Authorization` header, or `body` to send them as `x-www-form-urlencoded` body parameters. Defaults to `header`. | `*password`, `application`, `accessCode` |
| `x-oauth2-username-example` | String | Specifies a value that can be used as an example or demo client username | `password` |
| `x-oauth2-password-example` | String | Specifies a value that can be used as an example or demo client password | `password` |
| `x-allow-additional-oauth-fields` | Boolean | When enabled, allows additional properties return in OAuth 2.0 flows. | `password`, `implicit`, `application`, `accessCode` |
| `x-additional-oauth-fields` | Object | Specifies an object of properties returned in OAuth 2.0 flow. | `password`, `implicit`, `application`, `accessCode` |
| `x-default-scopes` | Array (string) | Specifies the default scopes to be used with the OAuth2 security scheme. These scopes are used when none are explicitly provided. | `password`, `implicit`, `application`, `accessCode` |
| `x-revoke-token` | Object | Defines the token revocation settings for the OAuth2 scheme. The object may include: 1. `Url` (string): The endpoint to revoke the token. 2. `TokenType` (string): The type of token being revoked (For example, `Refresh` or `Access`). 3. `TokenTypeHint` (string, optional): A hint about the type of token submitted for revocation. | `password`, `implicit`, `application`, `accessCode` |
:::note *
The extension isn't applicable to flow `password` if `x-skip-client-authentication` is set to `true`.
:::
### Discriminator Value Extension
OpenAPI makes use of a property `discriminator` to support polymorphism in custom types. As per OpenAPI, the value of this property must be the name of the parent model or the children models depending on which type the object represents. However, we allow our users to specify a custom discriminator value using the APIMatic's Discriminator Value extension. This value will override the default custom type name.
#### Usage
The extension is used through the `x-discriminator-value` property.
| Property | Type | Purpose |
| -------- | ---- | ------- |
| `x-discriminator-value` | String | Custom discriminator value |
For OpenAPI 1.2, the extension can be used inside the [Model Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/1.2.md#527-model-object) while for 2.0, it can be used inside the [Definitions Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#definitionsObject). In case of OpenAPI 3.x, the extension can be used inside the [Discriminator Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#discriminatorObject). All of this is illustrated in the examples below:
```json
"Pet": {
"id": "Pet",
"required": [
"name",
"petType"
],
"properties": {
"name": {
"type": "string"
},
"petType": {
"type": "string"
}
},
"subTypes": ["Cat"],
"discriminator": "petType",
"x-discriminator-value": "GenericPet"
}
```
```json
"Pet": {
"type": "object",
"required": [
"name",
"petType"
],
"properties": {
"name": {
"type": "string"
},
"petType": {
"type": "string"
}
},
"discriminator": "petType",
"x-discriminator-value": "GenericPet"
}
```
```json
"Pet": {
"title": "Pet",
"required": [
"name",
"petType"
],
"type": "object",
"properties": {
"name": {
"type": "string"
},
"petType": {
"type": "string"
}
},
"discriminator": {
"propertyName": "petType",
"x-discriminator-value": "GenericPet"
}
}
```
### Enumeration Extensions
We currently provide two extensions to let you enhance the models we generate from your enumerations. These are:
| Extension | Type | Description | Applicable to OpenAPI/Swagger Objects |
| --------- | ---- | ----------- | ----------------------------- |
| `x-enum-elements` | Enum Element Object | Provide additional meta-data for your enumerations by assigning a unique name for each element of your enum as well as specify a brief description for each | [Parameter Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameterObject), [Items Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#items-object), [Header Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#header-object), `Schema Object` ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schema-object), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject)) |
| `x-enum-model-name` | String | Specify a custom name for the enumeration model to be generated | [Parameter Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameterObject) when `in` isn't set to `body`. For other objects, use `title` for this purpose |
#### Usage
The following example demonstrates the usage of both extensions in a Parameter Object:
```json
{
"name": "numbers",
"in": "query",
"required": true,
"type": "string",
"enum": [
"1",
"2",
"3",
"4"
],
"x-enum-elements": [
{
"name": "One",
"description": "First element"
},
{
"name": "Two",
"description": "Second element"
},
{
"name": "Three",
"description": "Third element"
},
{
"name": "Four",
"description": "Fourth element"
}
],
"x-enum-model-name": "Number Elements"
}
```
### Datetime Extensions
You can specify various date-time formats using our editor, the details of which are available at [Datetime Formats](/web-dashboard-retired). OpenAPI supports only one of these formats that is, Rfc3339. To let you make use of other datetime formats, we provide custom formats which you can specify through the `format` property at the time of defining a type. As per OAS ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)), the `format` property is an open string-valued property, and can have any value to support documentation needs.
Taking advantage of the above, we make the following formats available to help you finely define the date-time type:
| Name | Description |
| ---- | ----------- |
| `date-time` | Supported by OpenAPI/Swagger by default. Represents datetime Rfc3339 format |
| `date-time-rfc1123` | Helps represent datetime that uses Rfc1123 format |
| `unix-timestamp` | Helps represent datetime using Unix or Epoch time |
### Dynamic Response Extension
APIMatic supports type `Dynamic` for success responses where type schema isn't known or can't be easily defined. To use this type inside any version of Swagger, you can use our extension `x-is-dynamic` inside the response schema as follows:
```json
{
"responses": {
"201": {
"description": "Successful operation",
"schema": {
"type": "object",
"x-is-dynamic": true
}
}
}
}
```
### Exception Model Name Extension
We auto-generate [exceptions models](/web-dashboard-retired) from the error response schema definitions to provide better support for handling API errors in generated code. By default, the models generated this way use the original schema's name/title and have a `_Error` postfix attached to them. You can, however, choose to override the auto-generated name with one of your own using our `x-exception-model-name` extension in OpenAPI's `Schema Object` ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schema-object), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject)).
| Name | Type | Description |
| ---- | ---- | ----------- |
| `x-exception-model-name` | String | When set, this name will override the default name assigned to an auto-generated exception model. |
**Example**:
```json
{
"paths": {
"/pets": {
"get": {
"operationId": "getPets",
.....................
"responses": {
"400": {
"description": "Unexpected error",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/BadRequest"
}
}
}
}
}
}
}
},
"components": {
"schemas": {
"BadRequest": {
"x-exception-model-name": "ErrorResponse",
"type": "object",
"properties": {
"code": {
"type": "string"
},
"message": {
"type": "string"
}
}
}
}
}
}
```
In the above example, the exception model imported into APIMatic will be named `ErrorResponse` instead of `BadRequest_Error`.
### Example Extensions
Swagger 2.0 doesn't have support for parameter level examples. If you need to specify examples for the [Parameter Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameterObject), you can do so by using our extension described below:
| Extension | Type | Description |
| --------- | ---- | ----------- |
| `x-example` | Any | Example value for the parameter |
```json
{
"name": "param1",
"in": "query",
"required": false,
"type": "string",
"x-example": "example value for param1"
}
```
### API Metadata Extensions
The Info Object in OpenAPI ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#infoObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#infoObject)) allows providing metadata about the API. We also offer some extensions that lets our users specify additional information about their API using this section.
| Extension | Type | Description |
| --------- | ---- | ----------- |
| `x-image-uri` | String | An absolute URL that points to a display image for the API |
#### Example
```json
"info": {
"version": "1.1",
"title": "Swagger Petstore",
"x-image-uri": "http://example.com/image.png"
}
```
### API Filtering Roles Extension
APIMatic supports role-based API filtering. If you choose to filter your API by roles, the resulting portal will only contain documentation for those endpoints available to the specific one or more roles. It works by matching endpoint-level tags with tags associated with specific roles. Information about the endpoint level tags comes from `tags` supported in OpenAPI at Operation level. However, to help specify information about available roles in the API, we support an extension called `x-roles` in the root OpenAPI object. See an example of it below:
#### Example Usage
```yml
info:
version: 1.0.0
title: Swagger Petstore
x-roles:
- name: private-role
id: "2"
tags:
- pets
description: private role
```
In below case, role with id `2` will have access to operations with `tags` containing "pet" but not those tagged as `store`.
```yml
/pet:
post:
tags:
- "pet"
summary: "Add a new pet to the store"
...............
/store/inventory:
get:
tags:
- "store"
summary: "Returns pet inventories by status"
description: "Returns a map of status codes to quantities"
operationId: "getInventory"
.............
```
Details of the properties available within this extension are given below:
| Property | Type | Purpose |
| -------- | ---- | ------- |
| name | String | Name of the role. |
| id | String | Unique identifier of the role. |
| description | String | Provides more details about the role. |
| tags | array[String] | List of String-valued tags associated with the role. |
### Applied Authentication Options Extension
You can extend the security information you apply globally or at operation level by adding additional metadata that can help provide more details about the security being applied. This metadata can be added using our extension `x-security-options-meta` which is applicable at the root OpenAPI/Swagger Object ([v2](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#swagger-object), [v3](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.0.md#oasObject)) and the Operation Object ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#operationObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#operationObject)).
Details of the properties available within this extension are given below:
| Property | Type | Purpose |
| -------- | ---- | ------- |
| name | String | A user-friendly name for the security option. |
| description | String | Provides more details about the security option. |
#### Example Usage
```yml
security:
- {}
- apiKey: []
x-security-options-meta:
- name: No Authentication
description: Authentication can be skipped. This will allow limited functionality, however.
- name: API Key
description: Pass the API key provided to you in your account settings. This will allow you full access to functionality.
```
:::warning
The number of items inside the extension must match the number of options in the `security` property else the extension data will be considered invalid or incomplete.
:::
### Webhook Group Extension
The `x-webhooks` extension, defined at the root OpenAPI Object (v3.x only), enables you to specify webhook groups for handling incoming event notifications from external services. This extension introduces advanced capabilities such as event-based discrimination and payload signature verification, helping you organize, secure, and manage webhook interactions within your API. It provides a structured way to group and configure webhooks, making complex event handling more consistent and reusable.
The `x-webhooks` extension contains one or more named webhook groups. Each group name acts as a key, with its configuration as the value.
```yaml
x-webhooks:
groupName1: # First webhook group
description: ...
discriminator: ...
payloadVerification: ...
groupName2: # Second webhook group
description: ...
discriminator: ...
```
#### Webhook Group Structure
In the webhook group structure, each webhook group maps onto a Webhook Handler in SDK, which is responsible for handling and configuring related webhooks.
| Property | Type | Required | Description |
|--------------------|--------------------|----------|--------------------------------------------|
| description | String | Optional | A human-readable description of the webhook group. |
| discriminator | [Discriminator](#discriminator-structure) | Optional | Defines webhook routing logic. |
| PayloadVerification | [PayloadVerification](#payload-verification-structure) | Optional | Defines request authenticity validation. |
#### Discriminator Structure
| Property | Type | Required | Description |
|-----------------|--------|----------|--------------------------------------------------------------------|
| `propertyPointer` | String | Yes | [JSON Pointer](https://datatracker.ietf.org/doc/html/rfc6901) (request-body only) is used to point discriminator property in the root request body. |
| `mapping` | Object | Optional | Maps event type values (keys) to webhook identifiers. |
#### Payload Verification Structure
| Property | Type | Required | Description |
|------------------------|--------------------------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| signatureHeader | String | Yes | Name of the header containing the signature. |
| description | String | Optional | Human-readable description of the verification configuration. |
| algorithm | Enum (`HMAC-SHA256`, `HMAC-SHA512`) | Yes | Algorithm to use for verification. | |
| digestEncoding | Enum (`hex`, `base64`, `base64url`) | Optional (default = `hex`) | Encoding used for the digest. |
| messageTemplate | String | Optional(default=`{$request.body}`) | Template describing the message to sign. Supports placeholders: • `{$request.body}` → raw request body • `{$method}` → HTTP method • `{$request.header.}` → specific header value • `{$request.body#/property}` → JSON pointer into request body. Default: `{$request.body}`. |
| signatureValueTemplate | String | Optional(default=`{digest}`) | Template describing the signature value format. Supports `{digest}` placeholder: • `"{digest}"` → plain digest • `"v0={digest}"` → prefixed • `"sha256={digest}"` → prefixed with algorithm name • `"complex={digest}"` → arbitrary prefix. Default: `{digest}`. |
### Using the x-webhook-group Extension
To associate a webhook with a webhook group, include the x-webhook-group extension inside your webhook definition.
This ensures the webhook inherits routing and verification logic from the referenced group.
#### Example Usage
```yaml
x-webhooks:
rides:
description: Ride and driver lifecycle events
discriminator:
propertyPointer: "$request.body#/event_type"
mapping:
ride.status.updated: rideStatusUpdated
driver.assigned: driverAssigned
payloadVerification:
signatureHeader: X-Signature
algorithm: HMAC-SHA256
messageTemplate: "{$request.body}"
signatureValueTemplate: "sha256={digest}"
```
```yaml
webhooks:
rideStatusUpdated:
post:
summary: Ride status updated
x-webhook-group: rides # ← associate with webhook group
requestBody:
content:
application/json:
schema:
type: object
properties:
event_type: # ← propertyPointer points here
type: string
example: ride.status.updated
status:
type: string
example: completed
```
### Callback Group Extension
The `x-callbacks` extension, defined at the root OpenAPI Object (v3.x only), enables you to specify callback groups for handling outgoing asynchronous requests (callbacks) to client-provided endpoints. Its structure mirrors the `x-webhooks` extension, providing advanced capabilities such as event-based discrimination and payload signature verification, ensuring consistent and secure callback handling
The `x-callbacks` extension contains one or more named callback groups. Each group name acts as a key, with its configuration as the value.
```yaml
x-callbacks:
groupA: # First callback group
description: ...
discriminator: ...
payloadVerification: ...
groupB: # Second callback group
description: ...
discriminator: ...
payloadVerification: ...
```
#### Callback Group Structure
The callback group structure follows the same design as the [Webhook Group Structure](#webhook-group-structure).
#### Using the `x-callback-group` Extension
To associate a callback with a callback group, include the x-callback-group extension inside your callback definition.
This ensures the callback inherits routing and verification logic from the referenced group.
#### Example Usage
```yaml
x-callbacks:
rideUpdates:
description: Callback group for ride status updates
discriminator:
propertyPointer: 'request.body#/event_type'
mapping:
ride.status.updated: rideStatusUpdatedCallback
payloadVerification:
description: HMAC verifier for ride callbacks
algorithm: HMAC-SHA256
digestEncoding: hex
signatureHeader: X-Signature
messageTemplate: "{$request.body}"
signatureValueTemplate: "v0={digest}"
```
```yaml
paths:
/rides:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
callback_url:
type: string
- callback_url
callbacks:
rideStatusUpdatedCallback:
'{$request.body#/callback_url}':
post:
x-callback-group: rideUpdates # ← associate with callback group
requestBody:
content:
application/json:
schema:
type: object
properties:
event_type:
type: string
example: ride.status.updated # ← propertyPointer applies here
status:
type: string
enum:
- accepted
- completed
- cancelled
```
## Response Mapping Object
Response Mapping Object is designed as a discriminated union with Type as the discriminator.
Currently, two types are supported:
### Simple
Matches the current behavior i.e response from endpoint is treated as the result or error.
```json
{
"Type": "Simple"
}
```
### Field-Based
Data is extracted from a nested-field in the response's JSON object. Additionally, an error field can also be specified. Each element of the DataField or ErrorField corresponds to one level of nesting and implies the name of the field to be accessed for the data.
```json
{
"Type": "FieldBased",
"DataField": ["nested", "data"],
"ErrorField": ["error"]
}
```
## Error Templates
Error templates are custom-templated messages that can be provided for overriding default exception messages thrown in SDKs for error responses. They can be defined using a map like structure as shown below:
```json
"errorTemplates": {
"401": "Response returned an error with status code {$statusCode}.",
"402": "Error occurred: {$response.body#/errors/0/reason}",
"5XX": "Internal server error, Code: {$statusCode}.", //this error message will be thrown for all error responses with status codes belonging to the 5XX range.
"0": "An error occurred. Code: {$statusCode}" //this error message will be thrown for all error responses that are not covered explicitly in the error templates.
}
```
Here,
- **Key of an error template:** Should be a valid HTTP error status code (400 - 599) or range (for example, 4XX, 5XX). The key can be set to 0 to represent any undeclared error codes.
- **Value of an error template:** The exception message that the SDK must return in case of an error response belonging to the range specified in the template key. The error message defined here has support for templates that are replaced by real data at runtime. More details about the required syntax for the message can be found in the [next section](#error-template-message-syntax).
### Error Template Message Syntax
The error template message is capable of supporting template expressions that hold placeholders which are replaced with actual data at runtime. A template expression must start and end with curly braces `{}`. The available placeholders that can be used are listed below:
| Placeholder | Details |
| ----------- | ------- |
| `$statusCode` | This is replaced by the actual response's status code at runtime for example, for an error response 401, the SDK exception message with a provided error template of `Response returned an error with status code {$statusCode}.` will become `Response returned an error with status code 401.` |
| `$response.header.headerKey` | This is replaced with the content of the response header whose name's specified in place of the `headerKey` part of the placeholder for example, for a response with header `X-Cache` set to `Hit`, the SDK exception message with a provided error template like `Could not fetch response data. Cache: {$response.header.X-Cache}` will become `Could not fetch response data. Cache: Hit`. |
| `$response.body#JsonPointer` | This placeholder is replaced with the content of the response body. `#JsonPointer` is an **optional** segment of the placeholder to help retrieve a specific part of the JSON response body using [JSON pointer syntax](https://www.rfc-editor.org/rfc/rfc6901). If the value is non-primitive, it will be serialized first for example, for an error response with body `{"error": {"reason": "Unauthorized"}}`, the SDK exception message for provided error template like `Response returned with error: {$response.body#error/reason}` will become `Response returned with error: Unauthorized`. |
### Pagination Extension
To simplify SDK generation for paginated APIs, we support a custom `x-pagination` extension that allows us to interpret and handle pagination strategies consistently. You can define this extension alongside the `schema` object inside the response `content`. It helps us identify the pagination strategy in use and automatically generate logic to handle pagination on behalf of the SDK user.
This extension supports four common pagination types: `offset`, `page`, `cursor`, and `link`. Each entry in the `x-pagination` array corresponds to one strategy used by the endpoint.
| Property | Type | Required For | Description |
|----------|------|--------------|-------------|
| `type` | Enum (`offset`, `page`, `cursor`, `link`) | All | Specifies the pagination strategy used by the API. |
| `input` | String | `offset`, `page` or `cursor` | A JSON pointer (custom syntax) to indicate where the pagination input value (For example, `offset`, `cursor`) is expected in the request. |
| `result` | String | All | A JSON pointer that tells us where to find the data records in the response. |
| `output` | String | `cursor` | A JSON pointer to extract the new cursor value from the response body or headers. |
| `next` | String | `link` | A JSON pointer that identifies the location of the `next` link in the response body or headers. |
| `limit` | String | Optional | A JSON pointer to the page-size (limit) parameter in the request. Applicable to `offset` and `page` pagination. Must reference an integer value. |
| `totalItems` | String | Optional | A JSON pointer to the total number of available items in the response. Applicable to `offset` pagination. Must reference an integer value. |
| `totalPages` | String | Optional | A JSON pointer to the total number of available pages in the response. Applicable to `page` pagination. Must reference an integer value. |
| `hasMore` | String | Optional | A JSON pointer to a Boolean value in the response that indicates whether more results are available. Applicable to `offset`, `page`, and `cursor` pagination. |
We support referencing request parameters (for example, `$request.query#/offset`, `$request.headers#/cursor`) and response values (for example, `$response.body#/data`, `$response.headers#/next`) using custom pointers, which follow a simplified [JSON pointer-like](https://datatracker.ietf.org/doc/html/rfc6901) syntax. Header references use the same `#/` separator as query and body references. For example, `$request.headers#/cursor` (not `$request.headers.cursor`).
The optional `totalItems`, `totalPages`, and `hasMore` properties always reference values in the response, using either `$response.body#/...` or `$response.headers#/...`. `totalItems` and `totalPages` must point to an integer value, and `hasMore` must point to a Boolean value.
The optional `limit` property references the page-size parameter in the request, using the same format as `input` (for example, `$request.query#/limit` or `$request.path#/page_size`), and must point to an integer value. It lets pagination detect the last page: when a page returns fewer items than the requested `limit`, the current page is the last one and pagination can stop without issuing an extra request.
Below are different pagination types with JSON examples.
#### Pagination Types and Examples
##### Offset Pagination
This strategy uses an offset query parameter to skip records. The data items are located in the data field of the response body. This example also declares the page-size parameter (`limit`) and exposes the optional total item count (`totalItems`) and a flag indicating whether more results are available (`hasMore`).
```json
{
"get": {
"responses": {
"200": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/PaymentResponse"
},
"x-pagination": [
{
"type": "offset",
"input": "$request.query#/offset",
"limit": "$request.query#/limit",
"result": "$response.body#/data",
"totalItems": "$response.body#/total",
"hasMore": "$response.headers#/x-has-more"
}
]
}
}
}
}
}
}
```
##### Page-Based Pagination
This approach reads the current page number from a request header and expects the response body to contain the paginated items directly. It also declares the page-size parameter (`limit`) and exposes the optional total page count (`totalPages`) and a flag indicating whether more results are available (`hasMore`).
```json
{
"get": {
"responses": {
"200": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/PaymentResponse"
},
"x-pagination": [
{
"type": "page",
"input": "$request.headers#/page",
"limit": "$request.query#/page_size",
"result": "$response.body",
"totalPages": "$response.headers#/x-total-pages",
"hasMore": "$response.body#/has_more"
}
]
}
}
}
}
}
}
```
##### Cursor-Based Pagination
This type uses a `cursor token` for paging through items. It reads the current cursor from the request headers and expects the new cursor in the response headers. It also exposes an optional flag indicating whether more results are available (`hasMore`).
```json
{
"get": {
"responses": {
"200": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/PaymentResponse"
},
"x-pagination": [
{
"type": "cursor",
"input": "$request.headers#/cursor",
"output": "$response.headers#/cursor",
"result": "$response.body",
"hasMore": "$response.body#/has_more"
}
]
}
}
}
}
}
}
```
##### Link-Based Pagination
Link pagination relies on a full `next` URL provided in the response headers, which is used to fetch the next set of results. The data is returned in the response body.
```json
{
"get": {
"responses": {
"200": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/PaymentResponse"
},
"x-pagination": [
{
"type": "link",
"next": "$response.headers#/next",
"result": "$response.body"
}
]
}
}
}
}
}
}
```
### SSE Sentinel Extension
Some [Server-Sent Events streams](/generate-sdks/sdk-features/server-sent-events-streaming) mark their end by sending a final frame carrying a fixed sentinel value (for example, `[DONE]`) instead of just closing the connection. The `x-sse-sentinel` extension lets you declare that terminator on a `text/event-stream` response so the generated SDK ends the stream cleanly when the frame arrives.
Define it alongside the `schema` object inside the `text/event-stream` entry of the response `content`. Its value is the exact string a frame's `data` payload must equal to be treated as the terminator. Quote the value in YAML when it contains characters that YAML treats specially (for example, the `[` and `]` in `[DONE]`), so it's parsed as a string rather than a flow sequence.
| Property | Type | Description |
|----------|------|-------------|
| `x-sse-sentinel` | String | The exact `data` payload that marks the end of the stream. The matching frame ends iteration; it's not yielded to the consumer and isn't decoded against the response schema, so it need not match the payload type. |
```json
{
"post": {
"responses": {
"200": {
"content": {
"text/event-stream": {
"schema": {
"$ref": "#/components/schemas/CreateChatCompletionStreamResponse"
},
"x-sse-sentinel": "[DONE]"
}
}
}
}
}
}
```
---
# OpenAPI Test Case Extensions
Source: https://docs.apimatic.io/specification-extensions/swagger-test-cases-extensions/
The OpenAPI description format (most commonly known as Swagger) allows its users to extend their specification for an API at various points by making use of [vendor extensions](https://swagger.io/docs/specification/openapi-extensions/). This allows them to add any additional data that can better describe the API. By convention, these extension properties are always prefixed by `x-` and must have a valid JSON value. APIMatic utilizes this feature to provide users with extensions that lets them extend their API specification in order to configure and enhance the output from APIMatic products that suits their needs better.
This document focuses on extensions that allow users to specify test data in their OpenAPI/Swagger API specification which APIMatic can then utilize to automatically generate valid test cases in each language upon SDK generation. Other extensions available are documented here:
- [OpenAPI CodeGen Extensions](swagger-codegen-extensions.md)
- [OpenAPI Server Configuration Extensions](swagger-server-configuration-extensions.md)

The test data extensions that APIMatic offers are based on the Gavel specification.
## Gavel Specification
Gavel is a tool from `Apiary.io` that is used to validate HTTP API calls based on comparisons between expected and real requests/response JSON objects. For our purposes, we have made use of only the `HTTP Request` and `Expected HTTP Response` JSON objects present in the gavel specification.
### HTTP Request
This helps you define the details about an HTTP request that will be sent.
| Property | Type | Explanation |
| -------- | ---- | ----------- |
| method | `string` | This refers to the HTTP methods used for sending the request. Valid values include `GET`, `POST`, `DELETE`, `PATCH`, `PUT` |
| uri | `string` | Uniform resource identifier used to locate and identify a resource. May contain query parameters `(/pets?pet-id=1)` and template parameters `(/pets/{pet-id})`. |
| headers | `Map[string, string]` | Key-value pairs containing information for request headers like the `Content-Type`, `Accept`, etc. Key should be the header name while the value would be the header value. |
| body | `string` | The request body can contain input parameters depending on the `Content-Type` specified in the headers. This is not applicable in case of the HTTP method `GET`. |
**Example:**
```json
{
"method": "GET",
"uri": "/ip",
"headers": {
"user-agent": "curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5",
"host": "httpbin.org",
"accept": "*/*"
},
"body": ""
}
```
### Expected HTTP Response
This helps you define the expected response for the HTTP request you sent using details of the [previous section](#http-request).
| Property | Type | Explanation |
| -------- | ---- | ----------- |
| statusCode | `string` | The expected HTTP status code of the response e.g. `200`. |
| headers | `Map[string, string]` | Key-value pairs containing information for request headers like the `Content-Type`, `Accept`, etc. Key should be the header name while the value would be the expected value of the header. |
| body | `string` | The expected body data of the response. |
**Example:**
```json
{
"statusCode": "200",
"headers": {
"content-type": "application/json",
"date": "Wed, 03 Jul 2013 13:30:53 GMT",
"server": "gunicorn/0.17.4",
"content-length": "30",
"connection": "keep-alive"
},
"body": "{\n \"origin\": \"94.113.241.2\"\n}"
}
```
## Specifying Test Cases Using Gavel Specification
To specify one or more test cases based on gavel specification in OpenAPI/Swagger would require the use of our `x-unitTests` extension in the `Operation Object` ([v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#operationObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#operationObject)). This extension is an array of objects where each object is comprised of the following:
| Property | Type | Explanation |
| -------- | ---- | ----------- |
| request | [`HTTP Request Object`](#http-request) | **Required** This is where you define the input test data for your operation. |
| expectedResponse | [`Expected HTTP Response Object`](#expected-http-response) | **Required** This is where you define the response specific test data corresponding to the request data defined under the `request` property. |
APIMatic will take this array of test cases within each operation and convert them to test cases in the preferred programming language. For any test case, if the real response from the operation is different from that specified then the test case will fail. In this way the two objects help specify test data for test cases.
**Example:**
A `POST` operation containing one query parameter `pet-id` that retrieves the information of a pet (e.g. its name) based on its `pet-id` can be tested with a test case using the following specification:
```json
"post": {
"operationId": "findPets",
"parameters": [
{
"name": "pet-id",
"in": "query"
}],
"x-unitTests": [
{
"request": {
"method": "GET",
"uri": "/pets?pet-id=1"
},
"expectedResponse": {
"statusCode": "200",
"headers": {
"content-type": "application/json"
},
"body": {
"name": "Dolly"
}
}
}
]
}
```
:::note
If the `request` object contains parameters within `body` (invalid for `GET` method) then the `Content-Type` MUST be present in the `request` `headers` property.
:::
### Extended Gavel Specification
We have extended the Gavel specification with some configuration flags to fine-tune test case generation in APIMatic. These are optional flags that will assume default values if they are not explicitly specified.
#### Configuration Flags in Unit Test Object
| Flags | Type | Default Value | Explanation |
| ----- | ---- | -------------- | ------------- |
| x-testName | `string` | Operation `name` | Specifies the name of the test case to be generated. |
| x-testDescription | `string` | Operation `description` | Describes what the test case does. |
| x-testShouldPass | `boolean` | `true` | Should this test pass? If `false`, the test would be required to fail to pass. |
| x-testEnabled | `boolean` | `true` | Is this test enabled? Disabled tests are not generated and are not validated. Tests can be disabled in case they are outdated after an operation description is updated. |
**Example:**
```json
"x-unitTests":[
{
"request":{
"method":"GET",
"uri":"/pets?pet-id=1"
},
"expectedResponse":{
"statusCode":"200",
"headers": {
"content-type": "application/json"
},
"body":" {\"name\":\"Dolly\"}"
},
"x-testName":"getPetInfo",
"x-testEnabled":"true",
"x-shouldPass":"true",
"x-testDescription":"Get pet information from its id"
}
]
```
#### Configuration Flags in HTTP Expected Response Object
These flags can be specified along with the [Expected Response Object](#expected-http-response):
| Flags | Type | Default Value | Explanation |
| ----- | ---- | ------------- | ------------ |
| x-allowExtraHeaders | `boolean` | `true` | Specifies whether other headers than those specified in `headers` object within the `expectedResponse` are allowed or not. |
| x-bodyMatchMode | Enum [`string`] | `NONE` | Valid values are `NONE`, `RAW`, `KEYS`, `KEYSANDVALUES`, `NATIVE`. Specifies how `body` in the `expectedResponse` is compared to the actual response body. More information on the Match modes can be found at [Body Match Modes](testing/defining-test-case.md#body-match-mode). |
| x-arrayOrderedMatching | `boolean` | `false` | If `true`, testing of arrays will include order checking of elements as well. |
| x-arrayCheckCount | `boolean` | `false` | If `true`, the arrays will be tested to see if they are equal in length. If both `x-arrayOrderedMatching` and `x-arrayCheckCount` are `true`, arrays will be strictly checked for equality i.e. their order as well as size must match. |
**Example:**
```json
"x-unitTests": [
{
"request": {
"method": "GET",
"uri": "/pets?pet-id=1"
},
"expectedResponse": {
"statusCode": "200",
"headers": {
"content-type": "application/json"
},
"body": " {\"name\":\"Dolly\"}",
"x-bodyMatchMode": "KEYS",
"x-allowExtraHeaders": "true"
}
}
]
```
## Inline Test Data Specification
To specify test values for security parameters or operation parameters you can also use the `x-testValue` extension property.
### Security Scheme Object
You can use the `x-testValue` within the `Security Scheme Object` to specify a test value for the particular security parameter e.g. you can specify a test API key as follows:
```json
"apikey": {
"type": "apiKey",
"name": "apikey",
"in": "query",
"x-testValue":"4d883edc9e6eba86bf1cc2dd4024d612"
}
```
:::note
The alternative to this would be to specify this value within gavel specification (within the Request uri if the apikey is in query or within the Request headers if the apikey is in headers)
:::
Basic authentication generally requires a username and a password. To specify test values for these parameters you can declare `x-testValue` as an array of type `BasicAuthTestValue Object`.
`BasicAuthTestValue Object` consists of two properties:
| Property | Type | Details |
| -------- | ---- | ------- |
| name | String | Name of the parameter e.g. username |
| value | String | A test value for that parameter |
#### Example
```json
"basicAuth": {
"type": "basic",
"x-testValue":[{
"name":"username",
"value":"user123"
},
{
"name":"password",
"value":"pass123"
}]
}
```
### Operation Parameters
We can also specify inline test values for operation parameters using `x-testValue` as follows:
```json
"get": {
"operationId": "findPets",
"parameters": [
{
"name": "pet-id",
"in": "query",
"description": "",
"required": true,
"x-testValue": "1"
}
]
}
```
:::note
In case a parameter test value is specified in both the gavel specification and in inline specification of parameters the value in the gavel specification will be given preference.
:::
---
# OpenAPI Server Configuration Extensions
Source: https://docs.apimatic.io/specification-extensions/swagger-server-configuration-extensions/
OpenAPI/Swagger (v2.0, v3.x) facilitates third-party vendors to implement tool specific extensions. These extensions allow customizing behaviors beyond simple API definitions. We've enabled a similar category of extensions that help you customize APIMatic code generation engine as per your requirements. The current documentation targets the extensions available for you to specify server configuration information. You can view details on other available APIMatic extensions for OpenAPI at:
1) [OpenAPI CodeGen Extensions](specification-extensions/swagger-codegen-extensions.md)
2) [OpenAPI TestCase Extensions](specification-extensions/swagger-test-cases-extensions.md)
APIMatic also provides a similar extension for API Blueprint whose details can be viewed at [API Blueprint Extensions](specification-extensions/blueprint-extensions.md). All the mentioned extensions are supported by both the **Import API** operation, as well as by our Code Generation as a Service API.
## Server Configuration
Server configurations can be used to create multiple environments, multiple servers that can be used with specific endpoints and server urls with template parameters. You can view more details on this at [Server Configuration](/web-dashboard-retired).
## OpenAPI Extensions for Specifying Server Configuration
APIMatic offers you OpenAPI vendor extensions that you can use to specify server configuration information within your OpenAPI/Swagger API definition file. When you import this file, we will extract server configuration information from this extension. The alternate way to specify this information is by using the APIMatic editor once you have imported your API definition file.
### Server Configuration Extension
This extension must be used within the "info" object by using the property `x-server-configuration`. Details about this object can be viewed at Info Object [v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#infoObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#infoObject).
```json
{
"openapi": "3.0.0",
"info": {
...,
"x-server-configuration": {
...
}
},
...
}
```
The fields available are:
| Name | Type | Details |
| ---- | ---- | ------- |
| **default-environment** | String | Environment to be used by default |
| **default-server** | String | Server to be used by default |
| **environments** | [[Environment Object](#environment-object)] | List of environments available |
| **parameters** | [[Parameter Object](#parameter-object)] | List of template parameters |
#### Server Configuration Object
##### Example
```json
{
"x-server-configuration": {
"default-environment": "production",
"default-server": "default",
"environments": [
{
"name": "production",
"servers": [
{
"name": "default",
"url": "http://example.com/{templateParam}"
}
]
}
],
"parameters": [
{
"name": "templateParam",
"description": "It is a template parameter",
"schema": {
"type": "string",
"enum": [
"abc",
"def",
"ghi"
],
"default": "abc"
}
}
]
}
}
```
:::caution OpenAPI 3.x Root Servers
The Server Configuration extension will override any information specified in the `servers` property of the OpenAPI 3.x [root object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#openapi-object).
:::
#### Environment Object
The environment object is used to define a single environment. An environment consists of a set of servers with base URL values. The fields available in this object are:
| Name | Type | Details |
| ---- | ---- | ------- |
| **name** | String | Name of the environment |
| **description** | String | Details about the environment |
| **disableTryItOut** | Boolean | Default: `false`. When set to `true`, the Try It Out button will be disabled on the API portal for this environment, preventing users from making live API calls against it. |
| **servers** | [[Server Object](#server-object)] | A list of servers in a particular environment |
##### Example
```json
{
"name": "production",
"description": "Production environment",
"servers": [
{
"name": "default",
"url": "http://example.com/{templateParam}"
}
]
}
```
#### Server Object
The user can specify multiple servers within an environment. A server comprises of a name and a url. The fields available in this object are:
| Name | Type | Details |
| ---- | ---- | ------- |
| **name** | String | Name of the server |
| **url** | String | Base URL for the server |
##### Example
```json
{
"name": "default",
"url": "http://example.com/{templateParam}"
}
```
#### Parameter Object
Parameter Object helps define the template parameters that can be used inside urls. These parameters are defined using the Parameter Object [v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameterObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#parameterObject) with rules that apply for parameters in template. In addition to those, you must also specify a default value for the parameter using the `default` property.
##### Example
```json
{
"name": "templateParam",
"description": "It is a template parameter",
"schema": {
"type": "string",
"enum": [
"abc",
"def",
"ghi"
],
"default": "abc"
}
}
```
:::caution Parameter Type
The parameter can only be of the following types: `string`, `number`, `number` enum, `string` enum.
:::
### Endpoint Server Name Extension
The base URL for a specific endpoint can be overridden by using the server name extension in the Operation Object [v2](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#operationObject), [v3](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#operationObject). The extension consists of the following single field:
| Name | Type | Details |
| ---- | ---- | ------- |
| **x-server-name** | String | Name of the server |
#### Example
```json
{
"get": {
"description": "Get operation",
"x-server-name": "default",
"tags": [
"Examples"
],
"operationId": "Example",
"produces": [
"application/json"
],
"parameters": [],
"responses": {
"200": {
"description": ""
}
}
}
}
```
## Conclusion
In this way you can specify server configuration in your OpenAPI file using our APIMatic extensions. You will then not be required to manually add this information through the editor every time you import your OpenAPI file.
---
# API Blueprint Extensions
Source: https://docs.apimatic.io/specification-extensions/blueprint-extensions/
APIMatic allows you to specify additional metadata with API Blueprint that will let you configure APIMatic products (including API Transformer, CodeGen, etc.) to produce better results. Some of the extensions also enable you to utilize parameter types for resources that aren't natively available in API Blueprint. This documentation will cover all details related to these extensions.
## API Version Extension
This extension allows you to specify your API's version which isn't supported in API Blueprint by default.
### How to Use the Extension?
You can specify the API version in API Blueprint's [Metadata section](https://apiblueprint.org/documentation/specification.html#def-metadata-section) using the `VERSION` property as follows:
```txt
FORMAT: 1A
HOST: http://api.datumbox.com/
VERSION: 2.0.0
```
## CodeGen Settings Extension
These extensions allow customizing the behaviour of APIMatic's Code Generation Engine. You can control the naming conventions, configuration stores and have your custom code branding. These settings are referred by us as the Code Generation Settings and you can find more details on these at [Code Generation Settings](/generate-sdks/customize-sdks/codegen-settings/codegen-settings-overview). Instead of having to import your API Blueprint into APIMatic and then using the Editor UI to specify these settings, you can now utilize these extensions to specify them in your API definition file. A similar extension is also available in OpenAPI/Swagger whose details can be viewed at [OpenAPI/Swagger CodeGen Extensions](specification-extensions/swagger-codegen-extensions.md)
### How to Use the Extension?
We extended the API Blueprint [Metadata section](https://apiblueprint.org/documentation/specification.html#def-metadata-section) to specify additional properties. See example below:
```txt
FORMAT: 1A
HOST: http://api.datumbox.com/
GENERATEASYNCCODE: TRUE
USEMETHODPREFIX: TRUE
USEMODELPOSTFIX: TRUE
USECONTROLLERPOSTFIX: TRUE
USEENUMPOSTFIX: TRUE
USECONSTRUCTORSFORCONFIG: TRUE
IOSUSEAPPINFOPLIST: TRUE
IOSGENERATECOREDATA: FALSE
ANDROIDUSEAPPMANIFEST: TRUE
COLLECTPARAMETERS: FALSE
CSHARPDEFAULTNAMESPACE: ACME.CORP.API
JAVADEFAULTNAMESPACE: com.acme.corp.api
APPENDCONTENTHEADERS: TRUE
BRANDLABEL: ACME CORP.
USERAGENT: APIMATIC 2.0
ENABLEADDITIONALMODELPROPERTIES: FALSE
APPLYCUSTOMIZATIONS: [ custom-f3a77d, custom-f3a77h ]
# DatumBox
Datumbox offers a Machine Learning platform composed of 14 classifiers and Natural Language processing functions.
..............
```
The various metadata parameters available and their details are given below:
| Setting | Type | Purpose |
| ------- | ---- | ------- |
| GENERATEASYNCCODE | Boolean | When true, the CodeGen engine generates asynchronous C# and Java code. |
| USEMETHODPREFIX | Boolean | When true, HTTP verbs are used as prefix for generated controller methods. |
| USEMODELPOSTFIX | Boolean | When true, a postfix "Model" is appended to all classes generated from schemas. |
| USECONTROLLERPOSTFIX | Boolean | When true, a postfix "Controller" is appended to all controllers generated from path groups. |
| USEENUMPOSTFIX | Boolean | When true, a postfix `Enum` is appended to all enumerations lifted from `allowedValues`. |
| USECONSTRUCTORSFORCONFIG | Boolean | When true, configuration values for example authentication credentials, are accepted as controller constructor parameters. Otherwise, these values generate variables in a Configuration class. |
| IOSUSEAPPINFOPLIST | Boolean | When true, configuration values for example authentication credentials, are expected in app-info.plist file for the iOS SDK. When set, this setting ignores useConstructorsForConfig flag. |
| IOSGENERATECOREDATA | Boolean | When true, iOS CoreData schema and classes are generated. |
| ANDROIDUSEAPPMANIFEST | Boolean | When true, configuration values for example authentication credentials, are expected in AndroidManifest.xml file for the Android SDK. When set, this setting ignores useConstructorsForConfig flag. |
| COLLECTPARAMETERS | Boolean | When true, operation parameters are expected to passed as a collection. For example in PHP, the generated method expects a Map containing parameters as Key-Value pairs. This is currently implemented for PHP, Python, GO, and Objective-C. When set, this is applied globally on all endpoints/resources. |
| CSHARPDEFAULTNAMESPACE | String | A valid C# namespace value to be used as the default namespace. Leave empty or null to automatically generate. |
| JAVADEFAULTNAMESPACE | String | A valid Java package name to be used as the base package name. Leave empty or null to automatically generate. This value is applied for both Java and Android code generation templates. |
| APPENDCONTENTHEADERS | Boolean | When true, code generation engine automatically detects request and response schema and appends content headers for example "accept: application/json" and "content-type: application/json" headers for JSON serialization mode. |
| ENABLEPHPCOMPOSERVERSIONSTRING | Boolean | When true, adds `version` component to `composer.json` file in PHP SDKs. This can cause [conflicts](https://github.com/composer/packagist/issues/587#issuecomment-142686483) with Git tag-based version publishing and should be used with care. |
| PHPCOMPOSERPACKAGENAME | String | This will set the name in composer.json file for PHP SDKs. You must provide a string with the format your-vendor-name/package-name. |
| BRANDLABEL | String | A string value to brand the generated files. For example: "Acme Corp." |
| USERAGENT | String | A string value to use as user-agent in the API calls. This is useful for analytics and tracking purposes. For example: "SDK V1.1" |
| ENABLEADDITIONALMODELPROPERTIES | Boolean | When true, additional or unknown properties in the response JSON are collected into a dictionary. |
| GENERATEINTERFACES | Boolean | When true, interfaces for controller classes are generated in the generated SDKs |
| NULLIFY404 | Boolean | When true, null response will be returned on the HTTP status code 404 |
| VALIDATEREQUIREDPARAMETERS | Boolean | When true, required API endpoint parameters are validated to be not null |
| TIMEOUT | Float | When true, the requests will timeout after the specified duration |
| PROJECTNAME | String | The name of the project for the Generated SDKs |
| USECOMMONSDKLIBRARY | Boolean | When true, a common library comprising of common classes is used by the generated SDKs |
| ARRAYSERIALIZATION | String | Format of serialization of arrays in form and query parameters. Valid values are `Indexed`, `UnIndexed`, `Plain`, `CSV`, `TSV`, `PSV` |
| APPLYCUSTOMIZATIONS | [String] | List of customer-specific customizations to apply. |
## Parameter Type Extensions
### Number Extensions
One of the primitive type that Blueprint offers for resource parameters is `number`. However, Blueprint doesn't natively support numbers of precision types for example decimal/floating point numbers. APIMatic extension allows you to further categorize number types as Long, Precision, Integers. By default, the numbers in Blueprint will be considered as `Precision` during import. However, you can specify them as `Long` or `Integer` as follows:
* To specify number parameters of type `Long`, use **{LONG}** in the description for your parameters e.g here `userId` will be treated as `Long`.
```markdown
+ Parameters
+ userId: 1 (required, number) - {LONG} User ID
```
* To specify number parameters of type `Integer` use **{INT}** in the description for your parameters for example, here `accountId` will be treated as `Integer`
```markdown
+ Parameters
+ accountId: 1 (required, number) - {INT} Account ID
```
### DateTime Extensions
In Blueprint if you want to have a parameter of type `date` you will need to use type `string` and declare the parameter as follows:
```markdown
+ dateparam: `2015-05-05T12:30:00` (optional, string)
```
During import, this parameter won't be treated any different from other parameters of type `string`. In order to utilize the APIMatic DateTime types (`Date`, `DateTime`) you can use the following extensions:
* To specify a parameter as `DateTime` (that contains both date and time) use **`{DATETIME}`** in the description for the parameter e.g.
```markdown
+ datetimeparam: `2015-05-05T12:30:00` (optional, string) - {DATETIME} This is a datetime parameter
```
* To specify a parameter as `Date` (in which time is treated as null) use **{DATE}** in the description for the parameter e.g.
```markdown
+ dateparam: `2015-05-05` (optional, string) - {DATE} This is a date parameter
```
### File Type Extension
There is no native support in API Blueprint for parameters of type `File`. If your API makes use of parameters of type `File` and you intend to utilize APIMatic `File` type you can use our file type extension in API Blueprint. APIMatic will then automatically extract the type information from the extension during any of the conversions/imports. Just use **{FILE}** in the description for the parameter. In the following example, the parameter `toUpload` will be treated as a File parameter located in the Form data.
```markdown
+ Parameters
+ toUpload (string, required) - {FILE} File to upload.
```
For more details on the field types available in APIMatic, please visit [Field Types](/web-dashboard-retired)
### URI Parameter Extensions
API Blueprint doesn't natively support complex type [URI parameters](https://apiblueprint.org/documentation/specification.html#uri-parameters-section) for example you can't have array URI parameters. We, however, allow you to specify array URI parameters by using the **{ARRAY}** extension in the parameter description. APIMatic will then treat these parameters as arrays for example here `arrayNumber` will be treated as an array of type `number`
```markdown
+ Parameters
+ arrayNumber: 1 (required, number) - {ARRAY} parameter is a number array
```
---
# APIMatic RAML Annotations
Source: https://docs.apimatic.io/specification-extensions/raml-apimatic-annotations/
RAML `v1.0` supports [annotations](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#annotations) that provide a mechanism to extend the API specification with metadata beyond the one supported by its official specification. APIMatic allows its users to extend their specification with annotations that can help configure output from APIMatic products such as API Transformer, Code Generation, Portal/Docs Generation etc.
Before you can use annotations in your API specification, you must also add a declaration for them in the root-level `annotationTypes` node as per the [spec](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#:~:text=Annotations%20used%20in%20an%20API%20specification%20MUST%20be%20declared%20in%20a%20root-level%20annotationTypes%20node). For each annotation that we provide, this document will also provide you details about the declaration to be added.
The annotations offered by APIMatic are listed below:
1. [Role-Based Access Annotations](#role-based-access-annotations)
2. [File Input Annotation](#file-input-annotation)
3. [Unit Tests Annotation](#unit-tests-annotation)
## Role-Based Access Annotations
APIMatic supports role-based API filtering. If you choose to filter your API by roles, the resulting portal will only contain documentation for those endpoints available to the specific role(s). It works by matching endpoint-level tags with tags associated with the available roles.
Roles can be defined in the RAML specification using the `roles` annotation in the root RAML object while method-level tags can be added through the `x-tags` annotation.
### Annotation for Roles
To describe the possible list of roles for an API, the `roles` annotation can be used.
#### Annotation Type Declaration
To apply this annotation, you will first have to declare it under the `annotationTypes` root node as follows:
```yml
annotationTypes:
roles:
type: array
items:
type: object
properties:
id:
required: true
type: string
name:
required: false
type: string
description:
required: false
type: string
x-tags:
required: true
type: array
items:
type: string
```
Details of the properties available within a particular role object are:
| Property | Type | Purpose |
| -------- | ---- | ------- |
| name | string | Name of the role. |
| id | string | Unique identifier of the role. |
| description | string | Provides more details about the role. |
| x-tags | List[string] | List of String-valued tags associated with the role. |
#### Example Usage for Annotation
An example of applying `roles` annotation at the root RAML object is:
```yml
(roles):
- name: private
id: 2
description: private role
x-tags:
- pets
```
This means that role with id `2` will only have access to methods tagged as `pets`.
### Annotation for Method level tags
Tags can be added to methods as a list of strings.
#### Annotation Type Declaration
To apply the `x-tags` annotation anywhere in your specification, you will first have to declare it under the `annotationTypes` root node as follows:
```yml
annotationTypes:
x-tags:
type: array
items:
type: string
```
#### Example Usage for Annotation
You can apply this annotation at method level as follows:
```yml
/pet/{id}:
get:
(x-tags):
- pets
displayName: Get pet by id
```
## File Input Annotation
By default, file type request parameters are considered part of multipart/form-data in APIMatic. If, however, you are looking to send the file directly as part of the request body then this default behavior in APIMatic can be overridden by using the boolean `sendFileInBody` annotation at method level.
### Annotation Type Declaration
To use this annotation, you will first have to declare it under the `annotationTypes` root node as follows:
```yml
annotationTypes:
sendFileInBody:
type: boolean
```
### Example Usage for Annotation
The annotation can be applied at method level as shown below:
```yml
/file:
post:
(sendFileInBody): true
body:
binary/octet-stream:
```
## Unit Tests Annotation
APIMatic [auto-generates test cases from your RAML specification](https://apimatic.io/blog/2017/04/from-raml-example-objects-to-test-cases/) if it contains sufficient examples data to create one. When you generate an SDK, the test cases are converted to language-specific unit-tests that can easily let you test your SDKs. However, if you are interested in writing test cases yourself with real test data and within your RAML specification, then you can make use of our unit tests annotation. This annotation lets you easily add multiple test cases against each of your RAML `v1.0` [methods](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#methods) using the `(unitTests)` property. A detailed breakdown and usage examples for this annotation is given below.
### Specifying Unit Tests Using Gavel Specification
The unit tests annotation makes use of Gavel specification to define the structure of a test case. Gavel is a tool from [Apiary](https://apiary.io) that is used to validate HTTP API calls based on comparisons between expected and real requests/response JSON objects. For our purposes, we have made use of only the `HTTP Request` and `Expected HTTP Response` JSON objects present in the gavel specification. Apart from these, we've extended the Gavel specification to add a few configuration options that are useful for test-case generation in APIMatic.
#### Unit Test Object
| Property | Type | Explanation |
| -------- | ---- | ----------- |
| request | [`HTTP Request Object`](#http-request-object) | **Required** This is where you define the request specific test data. |
| expectedResponse | [`Expected HTTP Response Object`](#expected-http-response-object) | **Required** This is where you define the response specific test data corresponding to the request data defined under the `request` property. |
A few optional configuration flags are also available:
| Flags | Type | Default Value | Explanation |
| ----- | ---- | -------------- | ------------- |
| testName | `string` | RAML [Method](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#methods) `displayName` | Specifies the name of the test case to be generated. |
| testDescription | `string` | RAML [Method](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#methods) `description` | Describes what the test case does. |
| testShouldPass | `boolean` | `true` | Should this test pass? If `false`, the test would be required to fail in order to pass. |
| testEnabled | `boolean` | `true` | Is this test enabled? Disabled tests are not generated and are not validated. Tests can be disabled in case they are outdated after an operation description is updated. |
#### HTTP Request Object
This object lets you describe your test request in more detail.
| Property | Type | Explanation |
|--------- | ---- | ----------- |
| method | Enum[`string`] | **Required** This refers to the HTTP methods used for sending the request. Valid values include `GET`, `POST`, `DELETE`, `PATCH`, `PUT`. |
| uri | `string` | **Required** Uniform resource identifier used to locate and identify a resource. May contain query parameters (`/pets?pet-id=1`) and template parameters (`/pets/{pet-id}`). |
| headers | `object` | Key-value pairs containing information for request headers like the `Content-Type`, `Accept`, etc. Key should be the header name while the value would be the header test value. |
| body | `string` | The Request body can contain input parameters depending on the `Content-Type` specified in the headers. This is not applicable in case of method `GET`. |
#### Expected HTTP Response Object
This object lets you describe your expected response for the test request defined in the [previous section](#http-request-object).
| Property | Type | Explanation |
| -------- | ---- | ----------- |
| statusCode | `string` | **Required** The expected HTTP status code of the response e.g. `200`. |
| headers | `object` | Key-value pairs containing information for request headers like the `Content-Type`, `Accept`, etc. Key should be the header name while the value would be the expected value of the header. |
| body | `string` | The expected body data of the response. |
Additionally, a few configuration flags are also available:
| Flags | Type | Default Value | Explanation |
| ----- | ---- | ------------- | ------------ |
| allowExtraHeaders | `boolean` | `true` | Specifies whether headers other than those specified in the `headers` property of the [Expected HTTP Response](#expected-http-response-object) are allowed or not. |
| bodyMatchMode | Enum [`string`] | `NONE` | Specifies how `body` in the [Expected HTTP Response](#expected-http-response-object) is compared to the actual response body. More information on the Match Modes can be found at [Body Match Modes](testing/defining-test-case.md#body-match-mode). Valid values are `NONE`,`RAW`, `KEYS`, `KEYSANDVALUES`, `NATIVE`. |
| arrayOrderedMatching | `boolean` | `false` | If `true`, testing of arrays will include order checking of the array elements as well. |
| arrayCheckCount | `boolean` | `false` | If `true`, the arrays will be tested to see if they are equal in length. If both `arrayOrderedMatching` and `arrayCheckCount` are true, arrays will be strictly checked for equality i.e. their order as well as size must match. |
### Annotation Type Declaration
In order to define unit tests in Raml v1.0 specification, you first have to define its type under `annotationTypes` root node as follows.
```yml
annotationTypes:
unitTests:
type: array
items:
type: object
properties:
testName:
required: false
type: string
testShouldPass:
required: false
type: boolean
testEnabled:
required: false
type: boolean
testDescription:
required: false
type: string
request:
required: true
type: object
properties:
method:
required: true
type: string
enum:
- GET
- PUT
- POST
- DELETE
- PATCH
uri:
required: true
type: string
body:
required: false
type: string
headers:
required: false
type: object
additionalProperties: true
expectedResponse:
required: true
type: object
properties:
allowExtraHeaders:
required: false
type: boolean
bodyMatchMode:
required: false
type: string
enum:
- NONE
- NATIVE
- KEYS
- KEYSANDVALUES
- RAW
arrayOrderedMatching:
required: false
type: boolean
arrayCheckCount:
required: false
type: boolean
matchResponseSchema:
required: false
type: boolean
statusCode:
required: true
type: string
statusMessage:
required: false
type: string
body:
required: false
type: string
```
### Example Usage for Annotation
The unit tests annotation can be applied on any RAML [Method](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#methods) object using the `(unitTests)` property which is an array of [Unit Test](#unit-test-object) objects as shown below:
```yml
/dummyResource:
post:
displayName: dummyName
(unitTests):
- request:
method: POST
uri: /message?id=4
headers:
user-agent: >-
curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
OpenSSL/0.9.8x zlib/1.2.5
host: httpbin.org
accept: '*/*'
body: dummyBody
expectedResponse:
allowExtraHeaders: true
bodyMatchMode: KEYS
arrayOrderedMatching: false
arrayCheckCount: false
matchResponseSchema: true
statusCode: '200'
headers:
content-type: application/json
date: 'Wed, 03 Jul 1821 13:30:53 GMT'
server: gunicorn/0.17.4
content-length: '30'
connection: keep-alive
body: |
[{"from": "dFrom","to": ["d1","d2","d3"],"text": "description."}]
testName: getPetInfo
testEnabled: true
shouldPass: true
testDescription: Get pet information from its id
```
The information from these method/endpoint level unit tests is then converted to language-specific test cases upon SDK generation.
---
# API Transformer Overview
Source: https://docs.apimatic.io/api-transformer/overview-transformer/
You can convert API definition/specification files into any format of your choice from amongst more than 10 supported formats including **OpenAPI** (previously known as Swagger), **RAML** and **API Blueprint** (complete list available in the later sections). This allows you to fully utilize all tools and functions that come with each format and saves the extra cost of having to rewrite your API definitions all over again.
## How Does Transformer Work?
The API specification document you input goes through the following steps internally while you're only performing a one step - transformation:
1. The API specification is imported.
2. The imported API definition is validated.
3. If the API passes validation, the API is converted/exported to desired format.
:::note
When an API definition passes through the import phase during transformation it's not added to the Dashboard as is the case when explicitly [importing an API](/web-dashboard-retired).
:::
## Configure Transformer
You can fine-tune and customize the transformation process according to your needs. This includes the ability to configure both import and export stages of the transformation and much more. Please visit our related documentation on this topic [here](configuring-transformer.md).
## Supported Formats in API Transformer
Refer to the lists below for detail on which versions and formats are supported for input and output of the Transformer:
### Supported Input Formats
The API Transformer supports the following API specification formats as input and converts them into the selected [output format](#supported-output-formats):
|API Specification Format | Version | File Format |
|---------------------------|-----------------|------------------------------|
|OpenAPI/Swagger |3.1 3.0 2.0 1.x|JSON/YAML JSON/YAML JSON/YAML JSON|
|RAML |1.0 0.8 |YAML YAML |
|Postman Collection |2.0 1.0 |JSON JSON |
|Insomnia |3 |JSON/YAML |
|HAR |1.2 |JSON |
|API Blueprint |1A |Markdown |
|WADL - W3C |2009 |XML |
|WSDL - W3C |1.1 |XML |
|Google Discovery |- |JSON |
|I/O Docs - Mashery |- |JSON |
|APIMATIC |- |JSON |
#### Transforming an API Specification With Multiple Files
If your API specification document is split up into multiple files for reusability purposes or any other reasons, we recommend that you create a ZIP file and add all relevant files to it. Then, upload this ZIP file when transforming. Ensure that all referenced files are part of the ZIP file and all relative paths to the files within the ZIP file are valid, to avoid any issues during the transformation, for example, if you are uploading a RAML ZIP file, ensure that all files referenced using `!include` or `$ref` are all present in the uploaded ZIP file.
It's recommended that in a ZIP file, the main API specification file is present in the root directory. If that's not the case, Transformer will iterate the ZIP file contents and pick the first file that validates as a main file in one of the supported input formats.
#### Transforming Multiple API Specifications
If you wish to transform multiple API specifications to generate a single API specification in any format, then you need to [enable merging](/manage-apis/api-merging/) in the root directory, ZIP all files and then transform the ZIP file. It's very important to correctly structure the API specification documents when merging, to get desired results.
When merging multiple API definitions for purpose of transforming the output, we **recommend** that you turn off strict validation meant specifically for Code Generation use-cases. This can be done by enabling the merge setting `SkipCodeGenValidation`.
### Supported Output Formats
The API Transformer supports conversion of the provided [input API specification](#supported-input-formats) into the following formats:
|API Specification Format | Version | File Format |
|---------------------------|-----------------|------------------------------|
|OpenAPI/Swagger |3.1 3.0 2.0 1.2|JSON/YAML JSON/YAML JSON/YAML JSON|
|RAML |1.0 0.8 |YAML YAML |
|Postman Collection |2.0 1.0 |JSON JSON |
|Insomnia |3 |JSON/YAML |
|API Blueprint |1A |Markdown |
|WSDL - W3C |1.1 |XML |
|WADL - W3C |2009 |XML |
|GraphQL Schema |- |GraphQL |
|APIMATIC |- |JSON |
---
# Transforming API Specifications
Source: https://docs.apimatic.io/api-transformer/transform-api-spec/
Depending on your environment, APIMatic offers the following ways to transform API definition files to a format of your choice if you have an API definition in one of the [supported formats](/api-transformer/overview-transformer#supported-input-formats):
- [Web](#transform-api-via-web)
- [API](#transform-api-definition-via-api)
- [APIMatic CLI](#transform-api-via-apimatic-cli)
## Transformer Configuration Settings
You can even customize your transformation by adding metadata and additional settings provided by APIMatic. For more detail on these settings, learn how to [Configure Transformer](/api-transformer/configuring-transformer) to improve your output.
## Transform API via Web
:::warning The transformer is moving to our CLI
The web-based transformation flow is being retired. To transform API definitions going forward, use the [APIMatic CLI](#transform-api-via-apimatic-cli) or the [Transformer API](#transform-api-definition-via-api).
:::
1. On the [APIMatic Dashboard](https://app.apimatic.io/dashboard), click on **Transform API**.

2. You can either **Upload the API Specification** file (or .zip file for [API merging](/manage-apis/api-merging.md)) from your local system, or **Specify the URL** that points to the API specification file. In case of urls, make sure that the URL must be a publicly accessible link - that is, no localhost links or links hidden behind authentication. Select the desired **Export Format** from the dropdown menu and click on **Convert**.

3. APIMatic automatically performs validation on your specified file. The validation involves checks to ensure that the API definition is structurally correct and contains complete information to ensure comprehensiveness. There are 3 levels of validation messages that you may encounter:
- **Errors:** Any syntax/semantic issues found in the API definition; for example, if a reference (`$ref`) in a JSON/YAML file has an invalid path that can't be resolved, API transformation **can't proceed** in case of an error. You will be required to fix the issues listed for your definition if that happens.
- **Warnings:** Any unexpected behavior that may affect the output; for example, if the parameter example provided is invalid. Warnings won't **halt** API transformation, but it's recommended that you fix these issues so your API definition results in the best possible experience.
- **Messages:** Recommendations or suggestions that can help enhance your API definition and its completeness. For example, messages can point out that an endpoint description or a parameter example is missing. Messages won't **halt** API transformation.
Once the validation errors are resolved (if any), click **Proceed** to move to the next step.

4. Once transformation is successful, the transformed file is automatically downloaded to your default download location with naming convention `-`. If it doesn't download, you may click on the download link provided. If your subscription plan allows, you can also proceed to generate an interactive developer experience portal for your API or view portals of our customers. Otherwise, click **Close**.

## Transform API Definition via API
You can use [APIMatic's API](pathname:///platform-api) in any supported language to build API Transformer into your CI/CD pipeline to automatically execute transformations every time changes are pushed. The transformed file is stored on the server for future accessibility. You can transform through a file on the system or uploaded on the server. You can also perform various functions like deleting a transformation, downloading the input file and getting logs for existing transformations.
You can perform the following actions through the Transformer API endpoints:
- [Transform via File](pathname:///platform-api#/http/api-endpoints/transformation/transform-via-file)
- [Transform via URL](pathname:///platform-api#/http/api-endpoints/transformation/transform-via-url)
- [Download Transformed File](pathname:///platform-api#/http/api-endpoints/transformation/download-transformed-file)
## Transform API via APIMatic CLI
APIMatic CLI allows you to transform an API definition in [supported API specification formats](/api-transformer/overview-transformer/#supported-input-formats) through the terminal. To get a detailed insight, refer to our [Transform API via CLI Docs](/apimatic-cli/commands/#transform-api).
---
# Configuring Transformer
Source: https://docs.apimatic.io/api-transformer/configuring-transformer/
As explained [here](/api-transformer/overview-transformer/#how-does-transformer-work), an API specification transformation internally involves both import and export stages behind-the-scenes. Both these stages can be configured individually for which two major ways are described below:
1. [Using APIMatic Metadata Configuration Options](#using-apimatic-metadata-configuration-options).
2. [Using Format-Specific Vendor Extensions](#using-format-specific-vendor-extensions).
## Using APIMatic Metadata Configuration Options
You can transform your API definition/specification along with the [APIMatic's Metadata file](manage-apis/apimatic-metadata.md) that will allow you to do the following:
- [Configure the import stage](#configuring-import) of the transformation process.
- [Configure the export/conversion stage](#configuring-export) of the transformation process.
- [Merge API specifications together](#merge-and-transform) before transforming them.
- [Filter the API specification document](#filter-before-you-transform) before transformation.
- [Override parts of the API specification document](#override-parts-of-api-definition-before-you-transform) before transformation.
### Configuring Import
You can control and customize how your file is imported during the transformation process, for example, you can configure the import process to use the schema keys instead of schema titles during OpenAPI import.
#### Import Settings
The import level configuration is performed by using import settings that are provided inside the APIMatic Metadata file [Import Settings Object](#import-settings-object).
#### Import Settings Object
The available properties in this object and their respective types are listed [here](/web-dashboard-retired).
#### Example
```json
{
"ImportSettings": {
"PreferJsonSchemaNameOverTitle": true,
"AppendParentNameForClashes": true,
"AllowModelTypesWithNoFields": true
}
}
```
### Configuring Export
You can control and customize how your input file is exported during the transformation process, for example, you can enable/disable export of vendor extensions when exporting to OpenAPI.
#### Export Settings
The export level configuration is performed by using export settings that are provided inside the APIMatic Metadata file [Export Settings Object](#export-settings-object).
#### Export Settings Object
The available properties and their respective types are listed [here](/web-dashboard-retired).
#### Example
```json
{
"ExportSettings": {
"ExportExtensions": true,
"GenerateModelSamples": true
}
}
```
### Merge and Transform
If you have multiple API definitions that you wish to merge together and produce a single transformed file in a particular format, you can enable merging in the ZIP folder you upload.
:::note
Merging multiple definitions is different from handling multiple files of a single API definition, which is handled by the Transformer automatically.
:::
To enable and further configure merging, you need to add a [Merge Configuration Object](#api-merging-settings) in the Metadata file.
#### API Merging Settings
The available merging configurations are listed [here](/manage-apis/api-merging/#merge-configuration-object). These configurations further contain a [Merge Settings Object](#merge-settings-object) to configure how any two APIs are merged together.
#### Example
```json
{
"MergeConfiguration": {
"MergeApis": true,
"MergeOrderOfDirectories": ["SpecDirectory1", "SpecDirectory2"],
"MergedApiName": "Merged API",
"MergeSettings": {
"ConflictStrategy": "KeepLeft",
"SkipCodeGenValidation": true
}
}
}
```
#### Merge Settings Object
The Merge Settings Object allows configuration of the merge process. The settings available are listed [here](/manage-apis/api-merging/#merge-settings-object).
When merging multiple API definitions for purpose of transforming the output, we **recommend** that you turn off strict validation meant specifically for Code Generation use-cases. This can be done by enabling the merge setting `SkipCodeGenValidation` as shown in the example in the previous section.
### Filter Before You Transform
If you wish to remove certain endpoints (for privacy reasons or any other) and their related data from the API specification document without actually affecting the original document, you can enable filtering using filtering options in the Metadata file. For more details, please see relevant section [here](/manage-apis/apimatic-metadata/#filtering-out-parts-of-api-definition-with-metadata).
### Override Parts of API Definition Before You Transform
If you are looking to override certain parts of the API definition before transforming it, you can take a look at some of the overrides available in the Metadata file [here](/manage-apis/apimatic-metadata/#overriding-parts-of-api-definition-with-metadata).
## Using Format-Specific Vendor Extensions
We also support format-specific vendor extensions (for example, for OpenAPI/Swagger, RAML and API Blueprint) so you can fine-tune the transformation output from within your API specification file. For details, please refer to our detailed documentation on [Extensions](/specification-extensions/spec-extensions-overview/) specific to your API definition file.
---
# Transformer FAQs and Troubleshooting
Source: https://docs.apimatic.io/api-transformer/transformer-faqs/
## FAQs
### What do you do with my data?
Your data belongs entirely to you. We don't sell or otherwise do anything with your data to put your privacy at risk.
### I want to convert my API definition file to a more readable format. Which format is more suitable?
API Blueprint is a format that uses Markdown which is considered a readable format and is supported widely by GitHub and other documentation renderers.
### Can I convert my API definition file into an XML schema (XSD) file?
Transformer allows you to transform between API definition files and XSD isn't a valid API definition file. However, you can choose to convert your API definition file to WADL/WSDL which will contain XSD embedded inside it. You can extract XSD from it to accomplish your goal.
### Can I convert my API definition file into a JSON schema file?
Transformer allows you to transform between API definition files and JSON schema isn't a valid API definition file. However, you can choose to convert your API definition file to OpenAPI formats that contains model definitions using a subset of JSON schema which you can extract and utilize for your purposes.
### My Postman Collection file uses environment variables. Is there any support for Postman environment files?
Yes, simply upload a ZIP file that contains your Postman collection file as well as any relevant Postman environment files to get a better output for Postman Collections containing environment variables.
### I converted my API definition to WSDL in which XSD is embedded. Is there a way to get a multi-file output where XSD is separated from the actual WSDL files?
Currently we only support a single file output. However, we're looking into supporting this in the future.
### My API is described using a OpenAPI/Swagger file. Now I want to make test calls to the API and view responses. Which format is best suited for this?
You can convert your OpenAPI/Swagger file to a Postman Collection file which you can import directly into your Postman App. All your requests will already be populated. You can then simply make your API calls, change the inputs to vary the results and view all the responses in a friendly GUI.
### I want to be able to test my RESTful API using SoapUI. Which format should I be using?
For a RESTful API, SoapUI has support for WADL as well as Swagger. You can choose to convert to any of these.
### I have a SOAP based API that I intend to make RESTful. Which format is recommended?
We support conversion from WSDL that's designed to support SOAP based APIs. You have the option to bring in your WSDL API definition and convert it to any of the RESTful formats like Swagger, RAML, WADL. It all depends on what you intend to do with it.
### My OpenAPI/Swagger definition file contains extensive documentation for each of the components involved. Conversion to which format has minimal loss of documentation?
The conversion process goes through our internal format during which some documentation may be lost. We're working on improving our support for that. However, much of your documentation should be preserved if you convert to API Blueprint (which is a clean documentation format), RAML, Postman depending on your needs.
#### I have two OpenAPI definition files in my ZIP folder. When I import the ZIP file, I only see endpoints from the first OpenAPI file while the second OpenAPI file seems to have gotten ignored. What can I do to import both my OpenAPI documents?
A typical transformation only supports transforming a single API definition file at a time. In case of a ZIP file, the first main API definition file located in the ZIP folder is picked up and transformed. If you wish to transform multiple API definition files you can either transform them separately or [enable merging in the ZIP folder](/manage-apis/api-merging/) which will first merge the API definitions together and then transform the merged API definition into the format of your choice.
## Troubleshooting
### I'm getting the error "We couldn't identify the API definition format from the given file...." What am I doing wrong?
You may be seeing this error due to any of these common scenarios:
* Your file wasn't in any of the supported formats listed at our [API Transformer page](http://apimatic.io/transformer).
* You are trying to upload a **Blueprint Markdown file** but your file doesn't contain the required format and host information which helps our system distinguish your file from any normal Markdown file. Simply include these two lines at the start of your file and try converting again:
```markdown
FORMAT: 1A
HOST: http://hostname.com
```
You can see [Blueprint Metadata Section](https://github.com/apiaryio/api-blueprint/blob/master/API%20Blueprint%20Specification.md#def-metadata-section) for more details.
* You are trying to upload a **JSON response data file** or a **JSON schema file** or an **XML data file** which aren't valid API definition files. Please ensure your file is in one of the supported formats listed at our [API Transformer page](http://apimatic.io/transformer). If however, you don't possess an API definition file, define an API entity on your [Dashboard](http://apimatic.io/dashboard). You will need to provide details like API name, API definition, etc. for which you can learn more about in our [documentation](/web-dashboard-retired). Once the API entity is created, go to the _Types_ section and import your JSON/XML file to load the models information. Then export this API entity to get an API definition file which you can then use for your conversions.
* You are trying to upload an **XML schema file (XSD)** which isn't a valid API definition file. Please ensure your file is in one of the supported formats listed at our [API Transformer page](http://apimatic.io/transformer), for example, you can try embedding your XSD file into a WADL/WSDL file or upload a ZIP file that contains the WADL/WSDL file as well as any referenced XSD files. If however, you don't possess an API definition file, define an API entity on your [Dashboard](http://apimatic.io/dashboard). You will need to provide details like API name, API definition, etc for which you can learn more about in our [documentation](/web-dashboard-retired). Once the API entity is created, go to the _Types_ section and import your XSD file to load the models information. Then export this API entity to get an API definition file which you can then use for your conversions.
* You tried uploading a **WSDL/WADL** file but faced this error. This could be due to invalid XML content. Please ensure that the content of your file validates against any XML validators and then try converting again. Also ensure that the root namespace of the file is valid. For WSDL, it should be `http://schemas.xmlsoap.org/wsdl/` and for WADL it should be `http://wadl.dev.java.net/2009/02`.
:::note
Support for WADL 2006 format is limited. It's recommended to use the WADL 2009 format instead.
:::
* You tried uploading a **Swagger/OpenAPI file** without listing down the required swagger version. For `1.x` Swagger files, you need to use the `swaggerVersion` property, for version `2.0` use the `swagger` property and for `3.x.x` use `openapi`. Visit the respective specifications of these formats for more details.
* You tried uploading a **RAML fragment file**, for example, a RAML library file. A RAML fragment file isn't a valid API definition file. A RAML file must be a valid root document in accordance with [RAML 0.8 root section](https://github.com/raml-org/raml-spec/blob/master/versions/raml-08/raml-08.md#root-section) or [RAML 1.0 root section](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#the-root-of-the-document) depending on the version you are using.
* You tried uploading a valid **RAML main file** without specifying the RAML version. A RAML file must contain the required comment line indicating the version; for example, for RAML 0.8 the comment line should be `#%RAML 0.8` whereas for RAML 1.0 it should be `#%RAML 1.0`.
* You tried uploading an **API definition file that uses JSON format** (for example, Swagger, Postman, or Google Discovery) but faced this error. Please ensure that the content of the file contains valid JSON using any of the JSON validators available online and then try converting again.
* You are trying to use the **URL obtained from exporting an API from your [Dashboard](http://apimatic.io/dashboard)** for your conversions, for example, urls starting with `https://www.apimatic.io/apientity/export/……` are obtained that way. You can't use this URL as it's not a publicly accessible link. Please download the file and then try converting by uploading it to Transformer.
* The provided **URL requires some kind of authentication** and isn't a publicly accessible link. Please ensure this isn't the case and then try converting again.
* You tried uploading a **RAR/7Zip file** which aren't supported formats. Try converting again by using a ZIP file that contains a file in one of the supported formats listed at our [API Transformer page](http://apimatic.io/transformer).
### I'm getting the error "Unable to resolve reference ..." / "Unable to load RAML Reference…." What should I do?
The file you uploaded contains references using `$ref` or `!include` that couldn't be resolved. The common causes for this are:
* The references involved external files that weren't provided. In such a case, please upload a ZIP file that contains the main API definition file as well as any externally referenced files. Ensure that the relative paths provided in your API definition file are accurate with respect to the file structure in the ZIP file.
* The reference contains a URL that isn't publicly accessible. Please provide a valid URL that works.
* The reference is internal (within the same file) but couldn't be resolved as the entity wasn't found; for example, if you get error for a reference like `"$ref": "#/definitions/DefinitionName"` it means that a model definition with the name `DefinitionName` wasn't defined under the root `definitions` property in your file. Provide this missing definition to avoid such errors.
### I am getting errors like "Reference to an undefined type found." What should I do?
You can find documentation for this error [here](/rulesets/apimatic-preliminary-validation/only-predefined-type-as-type-reference/). Common causes of the error are:
* It seems like you tried using a type for your parameter/model fields which wasn't a supported primitive type of that particular API definition format. In such a case, you need to explicitly define that particular type in the relevant section of the API definition file. For Swagger 1.x, such types must be defined under `models` root property, for Swagger 2.0 use `definitions` root property, for OpenAPI 3.x use `schemas` root property in the Components section, for RAML 1.0 use `types` root property while for RAML 0.8, Google Discovery, IO Docs Mashery use `schemas` root property.
* API Blueprint doesn't complain if you use an undeclared type for a parameter or a request/response model. However, our tool requires you to declare these types under the [Data Structures section](https://apiblueprint.org/documentation/specification.html#def-data-structures) if they aren't [primitive types](https://apiblueprint.org/documentation/mson/specification.html#211-primitive-types) supported by API Blueprint itself. A common mistake is using `bool` instead of `boolean`.
* `$ref` in Swagger 1.x can't refer to a [primitive type](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/1.2.md#433-data-type-fields). It must point to a Model's id so `"$ref": "string"` is invalid since `string` is a primitive type. Use `type` instead.
* Be sure to take care of the case of the name. A type may be declared with a different case compared to how it's being referenced. Ensure they're both the same and then try again; for example, a type declared as `definitionName` can't be referenced as `DefinitionName`.
### I'm getting the error "We don't support importing from an API documentation/reference. Please ensure your file is a raw API definition file and then try importing again." What should I do?
It looks like you tried converting by uploading an HTML file or provided a URL that referred to a web page which was possibly some form of API documentation. This isn't supported as the URL/local file must point to a raw API definition file in the formats listed at our [API Transformer page](http://apimatic.io/transformer) and not its documentation/reference.
Note that we do have limited support for extracting API definition file from some of the API documentation pages; for example, if you have a URL to a public Apiary documentation of an API like `https://apimatic.docs.apiary.io/` we will be able to convert using this. Additionally, some urls from Swagger UI hosted documentation, MuleSoft Anypoint documentation and Postman docs may also be supported in some cases.
### Why am I getting errors/warnings for invalid YAML due to 'Mapping values aren't allowed in this context.'?
Swagger 2.0(YAML), OpenAPI(YAML) and RAML requires your files to contain valid YAML content. This error will occur if the YAML content in your file isn't valid. You can use tools like [YAML Lint](http://www.yamllint.com/) to validate your YAML files before transforming them. A few tips to avoid this error are:
* Every nested item must be indented with two spaces inside the parent one; for example, a property `property2` nested inside `property1` must be declared as follows:
```yaml
property1:
property2:
```
* There must be a space between every property name and property value, for example:
```yaml
# This is invalid
property1:propertyValue
# This is valid
property1: propertyValue
```
In some cases, YAML doesn't complain if there is no space between property name and value, for example, in case of flow mappings. However, our tool requires you to use space in all cases (even flow mappings).
```yaml
# This is invalid
type: { collectionsTypes.mutableResource:{}}
# This is valid
type: { collectionsTypes.mutableResource: {}}
```
### I'm getting the error "Error fetching API definition file from the URL provided....". What should I do?
Please ensure that the URL you provided is publicly accessible, doesn't require any kind of authentication and points to a raw API definition file in one of the supported formats listed at our [API Transformer page](http://apimatic.io/transformer), for example, urls like `localhost:XXXX` won't work as they're only accessible on your system.
### Getting the error for my RAML file "Unable to load external libraries. Please either upload a ZIP File containing all relevant files, or upload by URL." What does this mean?
Your main RAML file (or any fragment file) uses external libraries using the root `uses` property and these couldn't be loaded. The common causes for this is:
* The library file doesn't exist at the path provided. If you provided your files using a URL then it may be that the relative URL of the library file doesn't exist or isn't accessible. Else you uploaded a single file or a ZIP file with missing files. Ensure that you upload a ZIP file in this case which contains all relevant files.
* A RAML generally needs the `!include` tag for referencing external files. However, for referencing external libraries the `!include` tag must **NOT** be used.
### I converted by API definition to Postman and I seem to have lost any information on types and models. What should I do?
Postman doesn't store information for your types. If you need to preserve such information, you can try converting to formats like Swagger, RAML,etc. that support data types(primitive and complex).
### I see that there is loss of some information when converting my API file from one format to another; for example, some of my descriptions are lost when converting from RAML 1.0 to OpenAPI 3.x. Why is this so?
In the conversion process, there is generally some loss of information which could be due to the following reasons:
* The particular feature may not be supported by the format you are trying to export to. Please check with the format's official specification to confirm it's indeed supported.
* We map your file to our internal format during the conversion which is more geared towards our Code Generation engine. However, we're ever working on making it more generic and better suited for conversions. We try to accommodate as much information as possible to minimize this loss so if you feel that something is important but is getting missed out, you are welcome to [reach out](https://www.apimatic.io/contact) to us and let us know. We will try to add that as well.
### My API is described using WADL and contains multiple GET methods for the same route `/xyz`. When I convert this to Swagger, I can only see one of the methods in the output. The rest are lost. Is this a bug?
No, it's not a bug. Swagger and RAML supports only one GET method, one POST method, and similar per resource. In the future we're looking into giving you the option to choose the method you want in the converted output out of all the methods in your original file.
### Why am I getting this error? "We couldn't load your API declaration files. Please provide base path information at the root of your file using the 'basePath' property so we can load your API declaration files. Alternatively, import/convert again by providing your file via a URL where the API declaration files are relatively located to the given URL."
Unlike other Swagger formats, Swagger 1.x versions require your files to be structured into two different kind of files: A Resource Listing file and API declaration files. To avoid running into any issues you can do the following:
* Provide a ZIP file that contains the resource listing file (in the root directory) and the API declaration files in a separate directory relative to this resource listing file. Do ensure that the paths to the API declaration files in the resource listing file are valid with respect to the file structure in the ZIP file.
* At the time of transforming, provide a URL that points to the resource listing file. The API declaration files must exist relative to this URL. We will automatically try to load them from the paths listed in the resource listing file.
* Upload a resource listing file that contains the `basePath` property in the root object that provides the base URL which can be used to load the API declaration files from the relative paths listed in the same resource listing file.
* Convert by providing a single API declaration file (either by uploading it from your system or via URL).
For more details on the file structure, please visit the specification [here](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/1.2.md#42-file-structure).
### Why am I getting the error "Enumeration model has no fields which isn't allowed." for my API Blueprint file? The enum values are declared but the tool is still complaining.
You can find documentation for this error [here](/rulesets/apimatic-preliminary-validation/atleast-one-enum-field/). Common causes of the error are:
It looks like enums are used while defining URI parameters and that too without using the Members section. So for example the parameter definition may look like this:
```md
+ Parameters
+ id: 1 (enum[number]) - An unique identifier of the message.
+ 1
+ 2
+ 3
```
The above will appear in Apiary editor as a list of values:

However, the editor doesn't consider these values as enum values just yet. You need to define them under a Members section using the `Members` keyword for these to be treated as enum values. So for the above example, the markdown will now look like this:
```md
+ Parameters
+ id: 1 (enum[number]) - An unique identifier of the message.
+ Members
+ 1
+ 2
+ 3
```
This should take away the error you were facing while converting your files. Also if you now see the Apiary editor, the list of values will be shown as a list of _possible_ values:

You can visit [URI Parameters Section](https://apiblueprint.org/documentation/specification.html#def-uriparameters-section) for more details on how to declare URI parameters in API Blueprint.
### I see some extra models in the converted file which weren't present in the original file. Why is that?
Other than the models defined explicitly in the API definition by the user, we may create extra models in certain scenarios which are:
1. Any enum values declared inline for parameters/responses/model fields are loaded as models and may appear that way in case of certain conversions.
2. In certain cases where type information isn't provided but an example is included we infer models from the example; for example, we automatically generate a model from the Request Body example given for any API Blueprint action request if its schema isn't defined/indicated explicitly.
3. If error responses use any models we load them separately as exception models internally. You may see these models in the output if you convert to formats like APIMatic.
4. Any inline model declaration like the ones supported in RAML and OpenAPI are also loaded as explicit models.
In all of the above cases, the names of the models are generally derived from the component name (for example, parameter name). Due to this, there is a chance that this derived model name may clash with other derived model names or with names of user defined models. We try to handle such clashes by appending a number at the end of the derived model so names like Model1, Model2, Model3 may appear in the output. If you are using inline models, we recommend that you either move such definitions to the global level and assign them a unique name or in case of OpenAPI use the property `title` to assign unique names to the inline models. If inline models aren't the root cause or it's not possible to modify the original specification document, we recommend that you use our metadata file [import configuration setting](/api-transformer/configuring-transformer/#import-settings-object) `AppendParentNameForClashes` to assign parent name to clashing model names instead of numbers as this can improve the output quality to some extent. You can learn more about our API Metadata file [here](/manage-apis/apimatic-metadata/).
### I used your Transformer to convert my WSDL file to OpenAPI format. However, when I try using the OpenAPI file to make calls to my API, the calls fail. Why is that happening?
Our WSDL to OpenAPI conversion is designed to [facilitate migration of SOAP APIs to REST APIs](https://www.apimatic.io/blog/2018/12/api-transformer-recipes-facilitating-migration-from-soap-to-rest/). The conversion involves translating the SOAP API information into a REST API compatible information. In other words the converted output can't be used to work for your existing SOAP API. You will need structural changes on your API's end to make your API work as a REST API before you can make any API calls using the converted output.
### I converted my OpenAPI file to a Postman Collection and am seeing some dummy sample values for my responses that didn't exist in my OpenAPI file. Why is this happening?
You are seeing dummy sample values because we auto-generate sample values when exporting to Postman Collections and Insomnia if your original specification document doesn't contain any examples of its own. To disable this feature, you can upload an [APIMatic Metadata file](/manage-apis/apimatic-metadata/) and set the `GenerateModelSamples` [export setting](/api-transformer/configuring-transformer/#export-settings-object) to `false`.
---
# Context Plugins Overview
Source: https://docs.apimatic.io/context-plugins/overview/
import { SquareDashedMousePointer } from 'lucide-react';
AI coding agents are good at writing code. They struggle with API integrations. The problem isn't code generation; it's context. When an agent draws on stale training data or scraped docs, it produces code that calls endpoints that don't exist, uses wrong SDK versions, or mishandles authentication.
APIMatic context plugins solve this by giving AI coding agents deterministic, version-aware context grounded in your OpenAPI definition. The plugin delivers your current SDK, code samples, integration workflows, and documentation to the agent at the time it writes code, not from model memory. Developers get accurate, production-ready integrations without needing to read your docs or switch context.
The result: developers go from your portal to a working integration in minutes, not hours. In production use, teams have seen a 63% reduction in implementation time and a 78% decrease in rework.
## How context plugins work
APIMatic generates a context plugin alongside every API portal it builds. The plugin delivers:
- Your full API reference: endpoints, parameters, and request and response models
- Authentication requirements for every endpoint
- Versioned SDK code in the developer's language of choice
- Integration workflows and code samples drawn from your portal documentation
When a developer loads the plugin into their AI coding agent, such as Claude Code, Cursor, or any MCP-compatible tool, the agent gains task-aware, grounded context. It can suggest the correct endpoint, generate type-safe SDK calls, handle authentication properly, and surface real integration patterns, without the developer leaving their IDE.
## See it live
## Enable context plugins for your portal
Context plugins are generated automatically as part of APIMatic's Docs-as-Code workflow. To enable them on your portal, see the [context plugins enabling guide](https://docs.apimatic.io/platform-api/#/java/guides/generating-on-prem-api-portal/context-plugins-for-ides).
---
# SDK Generation Overview
Source: https://docs.apimatic.io/generate-sdks/overview-sdks/
Apart from a good developer experience, APIMatic offers SDK Generation for your APIs to help accelerate the API consumption process. You can seamlessly integrate code generation into your CI/CD pipelines so that every time your API is updated or versioned, the changes are reflected in an automatically generated SDK. This allows releasing APIs or microservices frequently without any breaking changes.
APIMatic CodeGen Engine offers SDK generation in the following languages:
- Python
- .NET
- Ruby
- Java
- PHP
- TypeScript
- Go
To aid quicker API consumption, APIMatic-generated SDKs come with utility classes, authentication helpers and configuration files. They have strict language bindings, so developers can directly use language objects and functions to interact with the API. Moreover, the SDKs are designed following the latest [coding standards](sdk-coding-standards.md), and support all latest language [versions and dependencies](supported-sdk-version-dependencies.md).
:::note
To get complete detail on all the features that SDKs provide, go to the [SDK Features Docs](generate-sdks/sdk-features.md).
:::
## Customize your SDK
APIMatic supports [custom code injection](/generate-sdks/customize-sdks/custom-code-injection), allowing you to add and maintain your own logic directly within generated SDK files. Your customizations are preserved across regenerations, so they aren't lost when you update your API specification and regenerate the SDK.
Additionally, API providers can customize code generation using code generation settings, like generic code styling settings, asynchronous/synchronous code generation and advanced documentation generation. These settings can be specified via [CodeGen Settings through API Definition](../customize-sdks/codegen-settings/codegen-settings-overview/)
## How Does SDK Generation Work?
The code generation process starts with an input API definition file. This file can be in any of the [supported API definition formats](api-transformer/overview-transformer.md#supported-input-formats) like OpenAPI, RAML or API Blueprint and more.

### Step 1: API Transformation
This step transforms the input API definition file into APIMatic's representation format (a.k.a. APIMatic format). Transformation only takes place if you are generating SDKs from an existing API or importing your API, and the API definition in either case **isn't** in APIMatic format. The APIMatic format contains useful information for SDK generation that's not available in other API definition formats.
### Step 2: API Validation
After the API definition is transformed into the APIMatic format, it's validated. Validation is a thorough process that involves checking for numerous discrepancies in the API definition like duplicate parameters or missing request body in GET endpoints, etc. This validation runs through basic API settings, server configurations, code generation settings, authentication settings, models, errors and endpoints.
The API Validator automatically rectifies minor issues like duplicate property names and throws warnings to reflect any changes made. Major issues like invalid test case input result in errors that must be fixed in the API definition. The validation errors are returned in a JSON response object, for example as shown:
```json
{
"reason": "API validation Failed for Voice",
"summary": {
"errors": [
{
"message": "The server template parameter base_url does not have a default value.",
"hints": [],
"filePath": null,
"startLineNumber": 150,
"linePositionStart": 23,
"endLineNumber": 151,
"linePositionEnd": 33
}
],
"warnings": []
}
}
```
### Step 3: SDK Generation: The SDK Layout
Once the API is validated and any issues are resolved, components of the API definition are looped over to generate code representations. While a basic SDK will cater to settings, endpoints and an abstraction layer, APIMatic goes an extra step by mapping your API completely into an SDK. Some important entity conversions from an API specification to an SDK are:
- **Settings -> Configuration files**
All API settings like environment configuration, server information, authentication parameters and more are consolidated in a configuration file in the SDK.
- **Endpoints -> Functions**
Each endpoint of your API maps onto an independent function in the SDK. Note that if you have configured the CodeGen setting for asynchronous code, the SDK will also contain an asynchronous method for each corresponding endpoint. The endpoints are logically grouped together in controller classes (explained below), and contain XML documentation for each parameter and method as provided in the endpoint description in the API definition.
- **Groups -> Controller class files**
If your API contains logically grouping for endpoints, the SDK will automatically group them accordingly into separate Controller classes. Each controller class will then contain all endpoints contained under the same logic as in your API.
- **Models -> Model class files**
The data input is converted into models. Most APIs accept data as either JSON or form-encoded strings. JSON keys are dynamic; once a new instance of the model is created, all values and types for each parameter are shown automatically, making it easier to just select what's required. So the user doesn't have to go through the documentation to find out about the parameters for each model. You can also configure the models to be immutable through the `EnableImmutableModels` CodeGen setting.
- **Errors -> Exception class files**
If there is an HTTP error, our SDKs raise an exception that can be handled via a unified exception class. Once a user calls a method, the SDK gives an option to handle `APIException` or `IOException`. Moreover, if there are any other custom exceptions in the API, they're also included in this Exception class (if you configure the `GenerateException` CodeGen setting). This means that the user doesn't have to explicitly go through the documentation to find all the ways the SDK will throw an error. Moreover, having the exceptions in a unified place means that exceptions will be handled for all languages in the same way.
Apart from these core files, the following are generated:
- **HTTP abstraction layer**: to wrap the HTTP client used by the SDK.
- **Helper class files**: to abstract common code from the SDK.
- **Client library interface**: to wrap the SDK and make it easier to use. This acts a single gateway for the library, and it holds the state of the SDK. The client acts as a factory for the controllers.
- **Language/platform-dependent files**: for Ruby SDKs, gemspec, Gemfile and Rakefile are generated. These files specify SDK dependencies, test commands and other information required to publish the SDK on hosting services like RubyGems.
### Step 4: Documentation Generation
Every generated SDK comes with a language-specific README.md file, as documentation goes hand-in-hand with the SDKs. Depending on your pricing plan, this README file might contain a very basic getting started guide, or comprehensive documentation for the entire SDK. In the latter case, dynamic screenshots specific to the provided API and platform are generated, and help walk a developer through getting started with the SDK. The README also contains complete class reference and code samples for the SDK and guide the user on:
- Setting up environment (using tool specific IDEs)
- Initializing the client
- Creating the controller
- Calling the endpoints and testing them
### Step 5: Packaging
Once the SDK files are generated, you can opt to proceed with the following:
- [Download the SDK](/generate-sdks/create-sdks/create-sdks-through-cli) as a Zip file
- Publish the SDK to [GitHub or a package registry](generate-sdks/sdk-publishing/sdk-publishing-overview.md)
- Generate an interactive [Developer Experience Portal](/cli-getting-started/portal-quickstart-dac)
## SDK Features
The SDKs generated by APIMatic aren't just a mapping of the API onto the SDK. The SDKs contain additional functionality that adheres to the best coding practices to make the SDKs as robust and fault-tolerant as possible. This includes features like:
- Immutable clients
- Timeout and automatic retries on API call errors
- Access to HTTP response data
- Logging events in the API lifecycle
- Support for sending and receiving XML in the API calls
- Cancellable API calls for asynchronous endpoints
- Multipart requests
- Logging
For complete detail on the latest SDK features, refer to our [SDK Features page](https://docs.apimatic.io/generate-sdks/sdk-features/).
---
# Create SDK through API
Source: https://docs.apimatic.io/generate-sdks/create-sdks/create-sdks-through-api/
You can generate SDKs in any language of your choice for your API definition file using [APIMatic's CodeGen API](pathname:///platform-api). This can be done either on files on your system (external), or API specifications imported into APIMatic as an API entity.
:::note
These endpoints require basic authentication. Make sure you have authenticated client credentials before calling these endpoints.
:::
## Generate SDKs via External Files
APIMatic allows you to generate SDKs by importing your API specification file. You can either upload this file from your system or share the URL where the specification file is hosted. There are two different API endpoints for these two methods. Let's look at them in detail.
### Endpoint to generate SDK via file
This endpoint executes code generation by specifying the path of your API specification file.
- Go to the [Generate SDK via File](pathname:///platform-api#/http/api-endpoints/code-generation-external-apis/generate-sdk-via-file) endpoint.

- Under *API Code Playground* -> *inputtedFile*, click on **Choose File**.
- Select your API specification file and click on **Open**.
- Select the desired code template from the **template** dropdown menu.
- Click on **TRY IT OUT** to generate an SDK through APIMatic API.
### Endpoint to generate SDK via URL
This endpoint executes code generation by specifying the URL of your API specification file.
- Go to the [Generate SDK via URL](pathname:///platform-api#/http/api-endpoints/code-generation-external-apis/generate-sdk-via-url) endpoint.

- Under *API Code Playground* -> *url*, enter the URL where your API specification file is hosted.
- Select the desired code template from the *template* dropdown menu.
- When done, click on the **TRY IT OUT** button to generate SDK of your API.
## Download SDK
To download your generated SDK:
- Go to the [Download SDK](pathname:///platform-api#/http/api-endpoints/code-generation-external-apis/download-sdk) endpoint.

- Enter the **codeGenID** under API Code Playground section. This codeGenId is the ID you received as a response of the generate endpoint.
- When done, click on the **TRY IT OUT** button to get your SDK as a zip file.
## Generate SDKs via Imported APIs
This endpoint generates SDK against a specific API using the API Entity Identifier.
- Go to the [Generate SDK](pathname:///platform-api#/http/api-endpoints/code-generation-imported-apis/generate-sdk) endpoint.

- Enter the unique API version identifier in the **apiEntityId** parameter.
- Select the required platform template from the **Template** dropdown menu.
- When done, click on the **TRY IT OUT** button to generate your SDK.
## Download SDK
To download this generated SDK, you can use the Download SDK endpoint.
- Go to the [Download SDK](pathname:///platform-api#/http/api-endpoints/code-generation-imported-apis/download-sdk) endpoint.

- Enter the unique API entity identifier in the **apiEntityId** parameter.
- Enter the unique code generation identifier in the **codeGenId**. This Id was sent as a response when you called the Generate SDK endpoint
- Click on the **TRY IT OUT** button to get a zip file of your SDK.
---
# Create SDK through APIMatic CLI
Source: https://docs.apimatic.io/generate-sdks/create-sdks/create-sdks-through-cli/
APIMatic CLI allows automatic SDK generation for your APIs in multiple popular languages. You can use the `apimatic sdk generate` command to create an SDK for your API.
```bash
$ apimatic sdk generate
```
The following command generates a *Python SDK* for an API defined in *filename.json*. It also downloads the SDK to your working directory as a .zip file.
```bash
$ apimatic sdk generate --language=python --zip
```
The output of this command on successful execution is:
```bash
┌ Generate SDK
│
◇ SDK generated successfully.
│
● Generated SDK can be found at 'C:\sdk\python'.
│
└ Succeeded
```
You can tweak this command as per your requirement. To find the list of languages supported by this command, run this command:
```bash
$ apimatic sdk generate --help
```
It will show you what languages you can opt for to generate SDK.
```bash
--language=