APIQuality Release Notes
Check out the latest changes and improvements to APIQuality. We make the tool more efficient every day
What are release notes?
The release notes or publication notes are a series of technical documents where the updates of a tool or platform are indicated.
APIQuality has this section where the release notes of our API Tools integrator will be published, improving it every day so you can develop your APIOps in the most efficient way. Check the latest news!
v2.23 (extended version in our blog)
The devportal has been modified to make it more configurable.
In addition, a custom stage (currently on demand) has been added for automatic deployment on the devportal.
More information has been added on how to run Newman without uploading the files, by uploading them directly to the repository. From now on, if we configure the source “Newman properties defined”.
And it’s not defined; it will give you the possibility of creating the property automatically as long as you have permissions.
From now on, the results of stress tests will be displayed directly on the API dashboard.
The result of the mocking will also be shown, and also more information in the functional tests.
From now on, APIs can be designed and modified online without having to re-run the sonar and linter stages, which made the operation quite slow.
If we go to the organization properties, we can activate Redocly Online and Spectral Online.
Now we can go and edit an API and we’ll see errors like “Spectral” appear.
This means it is not necessary to keep saving for the stages to be re-executed, as the application will check for errors in the spectral itself in real time.
When the API is being reviewed from now on, an email will be sent.
From now on, you can edit directly from APIQuality and create API templates using those loaded by the application by default. To do this, simply click on “create,” select the “Default” template, or “Leave it blank”.
And a new template will be created for the APIs.
From now on, the configuration saved in the repository will be loaded to ensure there are no discrepancies between git and the database in the Kong deployer configuration stage.
In addition, the initializer has been improved to map the tags and service names, so that nothing needs to be modified in the repositories and deployment is automatic.
A new feature has been added that allows you to lock the automatic Linter stage. To do this, simply go to Environments, select the environment where the stage is located, and right-click on “Linter.” Then, select “Lock Stage.”
From now on, a global configuration will be allowed when configuring the openapi2postman stage, and therefore it is not necessary to configure it for each API.
To create a new API manager configuration from an architecture perspective, it is no longer necessary to upload the file; it can be created directly by selecting the name and the API manager to configure.
APIs imported via WSO2 can be deployed automatically since not only is OpenAPI being imported, but also the entire API project configuration.
From now on, the deployment stages of the different API managers will display a warning and redirect to the initializer if the stage has not been configured/executed.
Other updates has been published on the Release Notes V. 2.23 in APIQuality’s blog. There are:
- Improvements to interaction with Github
- Improvements on Gitlab integration
- Improvements on Bitbucket integration
- Improvements on Azure DevOps integration
- Importing APIs from standards
- Default stages and branches
- Improvements on WSO2 life cycle
- Improvements on IBM life cycle
- Improvements on Apigee life cycle
- Bug and minor improvements
v2.22
From now on, you can easily create API proxies using templates and OpenAPI, which were previously incompatible. This will allow you to easily create new API proxies with corporate policies.
To run it, simply add the template stage to your Apiops cycle. Select your template as shown in the image:
Next, you run the stage. We see that the generated API proxy combines the OpenAPI workflows with the policies defined in the Apigee template:
The API rating dashboard has been redesigned to divide it into the areas to be analyzed in the APIs: design, quality, and security.
Clicking on each section will display each test included in the areas:
From now on, you can deprecate API manager templates as shown in the following image:
This will prevent it from appearing in the initialization stages of the different API managers.
The style guide should be a living thing, so from now on it will be possible to deprecate a style guide and create a new one that can be associated with the APIs domain.
This will allow new rules to be incorporated into new versions of the style guide.
With this configuration, all new APIs will be analyzed using the new style guide:
From now on, the templates for API records can be “deprecated” and therefore, new API records cannot be created with deprecated templates.
To do this, simply click on the new “deprecate” button.
And it will automatically no longer be usable for new APIs:
If we now go to create a record, we see that the deprecated template no longer appears.
The environment of the APIs that are related in the models has been added.
When deploying to Wso2, a comment is added.
To allow users to describe the deployment comment as a property.
Alls Apis will be display all calculated and uncalculated ratings in the global report
The API name and environment have been added to the notification.
A new documentation section has been added, allowing you to access the user manual, release notes, and FAQs directly from within the application. The new menu is shown below:
A screen has been added to easily configure Kong’s parameters. If you click on “Configuration” in the deployment stage:
You can now change the namespace, basepath, tags, and targets directly from the interface. If you later want to change something that isn’t reflected, you can always use the advanced configuration.
Minor improvements
- From now on, when you save the API manager template update screen, you will return to the API manager template list screen.
- From now on, the style guide cloning screen will be locked to prevent the button from being pressed multiple times.
- Validation has been added to the port and host fields in the openapi2postman configuration.
- The environment and lifecycle change displayed within the execution screen of an environment has been enlarged so that both data can be clearly seen.
- Scrolling has been removed from the API import screen.
- Error messages have been improved when uploading API manager templates.
- The resolved download options have been removed from the API editor when it has not been configured as an API with external references.
- The configuration data has been removed from the developer portal so that it can be configured by the support team.
- A functionality to test the connection when setting up the Kong has been added.
Bugs
- The security vulnerabilities of definition have been removed from the definition vulnerabilities that were being included until now.
v2.21
The edit button has been added to the API manager template so that you can edit the configuration file beforehand:
The editor has been revised to display its own errors and combine them with errors that may come from sonar/spectral or redocly:
Editing the kong configuration
From now on, it will be possible to change the kong configuration before deployment:
New configurable fields in deployment
The configuration of namespace, basepath, targets, and tags has been enabled directly from a deployment screen:
Environment-level credential configuration
Credential configuration has been moved to environments.
Template selection in init
A configuration has been implemented so that the Apigee template init can take multiple templates.
Apigee base path and target configuration
A screen has been enabled for configuring the base path and target from a form.
Improvements have been made to the IBM lifecycle.
The IBM vendor extension has been added to the API deployment.
The IBM extension is automatically added to openapi:
The properties are configured at the organisation level (whether to run by repository or by file).
Below are some images:
The style guide rules and stages are reviewed to ensure minimum API quality settings when creating the organisation. From now on, the stages will be as follows:
- Linter
- SonarQube
- Enricher
- OpenAPI Diffs
- Sonar2Spectral
- Microcks
- OpenApi2Postman
- Open API Generator
- Openapi2jmeter
- Newman
- jmeter
- Zap Proxy
A GitLab configuration is added to enable runners and permission to create projects in the group if it is not already enabled.
From now on, it will be possible to configure the openapi2postman settings globally in the environment.
The following usability improvements have been developed:
- The set of rules compatible with spectral sonar has been updated.
- Import validations have been improved so that files with spaces are not imported.
- Some translations have been improved.
- A correct connection check has been added when configuring Kong in the environment.
- The errors displayed when uploading an API manager template have been improved.
New stages in Azure
- Kong initialiser.
- Kong deployer.
- Kong validator.
Improvements:
- A check has been added so that openapi-diff does not fail the first time it is run.
- From now on, not only will the API be displayed within the model, but also the branch to which it refers.
- Redocly has been preconfigured as –extends=minimal so that security is not enforced in the APIs.
- An improvement has been added to the wso2 deployer configuration stage so that it collects from the repository and does not save the configuration in the database.
- A comments field has been added to the wso2 api manager configuration to add it to the deployment.
- The developer portal option has been commented on to create them on demand.
- The option to download the resolved json/yaml if said yaml or json does not have external references within the apiquality editor has been commented on.
- The ‘accounts’ section, which was only used to import APIs from repositories, has been commented on.
- A configuration has been added so that if the stage fails, the stage values in sonar are updated.
- The Github jmeter stage has been improved to upload reports to S3 storage.
- A link has been added to show an explanatory video when linking repositories.
- The wso2 importer configuration has been changed so that it imports not only the swagger but the entire apiproject.
- The ability to clone the file template has been added.
- The behaviour has been modified so that definition stages are not auto-executed when there is a save error in the API editor.
Fixes:
- A minor bug that displayed the linked repository and SaaS at the same time has been fixed.
- A minor bug that prevented the redocly online lines from being displayed has been fixed.
- A bug that prevented some kong settings from being changed once the data had been established has been fixed.
- The Apigee deployment editor has been fixed so that it takes the SA data to update.
v2.20 -Kong and WSO2 API life cycle and new postman tests generator (2025-11-25)
From now on, you can easily configure a lifecycle with Kong. To do this, you first need to activate the Kong stages. To do this, go to environments and create a new lifecycle:
Next, let’s add Kong’s stages:
Now let’s configure execution:
Here we must enter the OAuth credentials, the provisioner ID, the consumer key, and the consumer secret of a Kong user with permissions to access the administration API.
Next, we need to upload the API template:
Here we can preselect the plugins we think are necessary:
Once the template has been chosen and the stage configured, we create a new API with a Kong lifecycle.
Once the new API associated with Kong’s lifecycle has been created, we enter the API to configure and execute the stages. Here we click on initializer and then on configure. We must select the template:
After initialization, go to the repository to modify the service name and path.
A new feature has been created that allows mocks to be secured through the apiquality API gateway.
To activate it, go to Organization->General->Settings and activate it where it says.
To obtain the new URL, we must go to the API and see that the mock URL has changed and now a URL with api-gateway.XXX appears.
To invoke it, we must copy the apikey that appears at the top of the configuration screen and inject it into the “apikey” header to make the calls. Here is an example with Postman:
In order to reuse the same jmeter and only change the execution parameters, the ability to add typical execution parameters when importing jmx into APIQuality has been added.
This means we won’t have to generate the file multiple times; instead, we can reuse it, and ApiQuality will take care of replacing the port, host, threads, ramp-up, duration, and number of test cases.
A new field type has been created that allows files to be uploaded to opportunities. This will allow both documents and Excel spreadsheets that have been previously created by the organization to be uploaded.
To do this, go to templates and create a new field of type “file.”
Next, we must create a new opportunity by selecting the created file template, and we will see that 1 or n files can be uploaded, which can be viewed as follows when consulting the opportunity:
A new technology has been added to generate postman collections. With Portman, you can generate collections.
https://github.com/apideck-libraries/portman
To generate the collections, you must enable it in your lifecycle environment. It will appear in the execution cycle of your API environment. There, you must add the Postman configuration collections.
With this configuration, we could now introduce portman into the life cycle.
The Wso2 stage configuration has been improved to unify the two steps (tenant) and gateways into a single configuration step. In addition, the ability to modify the context from the simplified deployment form has been added.
Just click on “Configure” and the following screen will appear:
You can save these settings directly here.
Improvements:
- The option to filter by environment has been added.
Bugs:
- A bug that prevented the modification of any API Manager credentials has been fixed.
v2.19 -IBM Life of cycle and Gitlab, Github, Azure and bibucket complete compatibiliy (2025-08-12)
For Apigee’s CI/CD, it’s important to generate the apiproxies using a template. This template is created using a tool called Apigeetemplator.https://github.com/apigee/apigee-templaterCurrently, version v2 has been implemented, which uses a configuration file.
The configuration file is defined by the architecture team and uploaded
In the API Manager templates section, you’ll find these templates to configure API proxies. For example:
The list is as follows:
These deployment profiles will be the ones available for configuration:
That will configure it for deployment.
In this version, the HTML for the Zap proxy report has been added so that it can be viewed directly from the tool, as shown in the following screenshot:
In addition, the option to configure security rating values has been added. Simply go to the Zap Proxy step and click on “Configure Zap Proxy”; the following screen will then be displayed:
From now on, you will be able to see the types of APIs supported by each stage:
A new view has been developed showing the status of Apiquality components:
- Sonar2Spectral
- Quality tests – Newman
- Microservices – Apigen ASP.NET
- Definition – Sonarqube
- Definition – Microcks Enricher
- Mocking – Microcks
- Definition – Sonar2Spectral
- Microservices – OpenAPI Generator: JMeter
- Microservices – OpenAPI Generator
- Microservices – Apigen Java SpringBoot
- Definition – OpenAPI Diffs
- Quality tests – JMeter
- Zap proxy
- Apigee X: Init
- Apigee X: Lint
- Quality tests – JMeter
- Deployment in Api Manager – Apigee X
- Newman
- Apigen Java Springboot
- WSO2: Initializer
- WSO2: Deployer
- WSO2: Synchronizer
- Definition – Linter
- Quality tests – Newman
- Microservices – Apigen Java Springboot
- Contract tests – Openapi2Postman
- Mocking – Microcks
- Definition – Sonar2Spectral
- Definition – SonarQube
- OpenApiDiff
- Quality tests – JMeter
- Microservices – Apigen ASP.NET
- ZapProxy
A new download button has been enabled next to the Newman test history, allowing you to download the functional test report:
Provisioning has been modified so that users logged into their own systems can automatically log into the application within a specific domain and role. The new parameter can be found in the organization settings:
This will allow you to log in with the external system:
Automatically create the user assigned to the specified domain and role.
The ability to connect to ELK Dashboards has been added to display information directly from consumption metrics. To do this, a parameter must be enabled in the organization settings.
This enables the statistics tab within the APIs
It adds the ability to edit model names. An option has been enabled within the three-dot menu on the model editing screen.
And a screen appears where we can modify it:
From now on, you can download the Apigee API templates that you have previously uploaded or edited. On the API Manager Templates editing screen:
The property names have been changed to make them more readable. Clicking the three buttons on the openapi2postman stage will display the following:
The following improvements have been made:
- Azure webhook data collection has been improved to better display the different pipeline states.
- The URL has been added to the mulesoft configuration screens in the environment to facilitate integration.
- It is allowed to implement a management request to pass the OpenAPI branch by configuring it at the organization level instead of copying it and committing it directly.
- The functionality to “retry staging” has been added to Azure DevOps and Bitbucket.
- Intermediate state information is added to bitbucket executions.
- The ability to edit the openapi file in multiple tabs has been added.
- The option to change the repository name has been added.
- The option to change the default base path when changing the API name has been added.
- The ability to stop stage for Github has been added.
- An error message is added when saving an API from the editor and “resolved” is active at the organization level and there are references that cannot be resolved.
- Usability improvements are made to the API import process by better indicating import failures, such as when the API already exists.
The following bugs have been fixed:
- The error in the commit description of the models that were shown within the commit displayed in the repositories has been corrected.
- The application has been modified to be able to obtain the newman reports after renaming the openapi file
- A bug that prevented the downloading of the api template file has been fixed.
- A bug within the API editing interface that allows only one error has been fixed.
- The sorting within the API explorer by domains has been corrected.
v2.18 -APIHUb (2025-08-12)
The ability to import APIs directly from the API Hub has been added. The first thing we need to do is enable this option and configure apigee from the organization’s configuration screen:
Here we will configure some parameters to be able to import from Apigee:
Once enabled and configured, we can go to import API within the API catalog screen:
Select ApigHub and select one of the APIs that are there to import them into Apiquality:
From now on, you’ll be able to view your security test history and access any reports that have been generated at any given time.
You just have to run the stress test, and in the “view runs” button
Here, if we click on actions we can see all the information about the execution:
A new feature has been created in the functional testing step that calculates which operations are tested and which are untested:
Thus, we can know which endpoints are not tested correctly:
Microcks has been updated to version 1.12 and SonarQube to version 10.8 in the SaaS.
Minor improvements
The following have been implemented:
- Added url for mulesoft configuration for shellservice.
Bugs
- Fixed username in model commits
Newman’s stages are reviewed,Apigen.net, sonarqube, microcks para Azure DevOps
v2.17 -MCP (2025-08-04)
An MCP server has been created that allows apiquality to be used as an MCP.
Requirements
- Account created and activated inAPIQuality
- Generating a token from an accounthttps://mcp.apiquality.io/tokenwith the desired expiration date (current use of authorization, may change in the future).
- A client to use the MCP (RecommendationVisual Studio Code)
- The client must have a subscription to an LLM with agentic capabilities. (Google Gemini recommended)
Configuration and use
For this example we will use Visual Studio Code.
- We generate a token with the account, password and expiration date.
If we have Visual Studio Code installed on the device, we can press the buttonto install the generated configuration
- If manual editing is required, this setting is hosted in%appdata%\Code\User\mcp.json (Create if does not exist)
- or you can access by:
Open Visual Studio Code. Open the Command Palette by pressing Command + Shift + P. Type Developer: Open User Data Folder and select the command from the list. This will immediately open the User folder in a new Finder window. |
example of mcp.json file
{ “servers”: { “ApiQuality”: { “type”: “http”, “url”: “https://mcp.apiquality.io”, “headers”: { “token”: “apiq_123456” } } } } |
2.1.3. Features
GetUserInfoAndOrganizations | Get a user info and organizations |
GetAllUserByOrganizationId | Get all users of an organization |
GetTags | Get tags of an organization |
GetRoles | Get all roles of a user (org. optional) |
GetLoggedUserInfo | Get logged user info |
GetApisInfoByOrganizationId | Get apis info by organization |
CreateApi | Create a new API by uploading a specification file yml or json |
CreateCollection | Create a new Collection |
GetCollections | Get collections |
GetProfiles | Get profiles |
GetApiInfo | Get API info by id |
GetApiRawByBranchId | Get Raw document API by branch id |
UpdateApiDocument | Update API document uploading a specification file yml or json |
The listed tools may vary from those provided on the server. To list the operational tools, consult the MCP client’s communication responses and enable/disable the necessary ones.
Examples of use
v2.16 -zap proxy (2025-08-04)
From now on, you’ll be able to run API security tests using Zap Proxy. For now, they can only be run black-box against the URL exposed by the API.
To run it, we must activate the stage within the corresponding environment and lifecycle.
Once activated, we must press the right button:
In configuration we must indicate the url and the policy.
If we are not convinced, we can upload our own attack policy:
Once configured, we can run the stage and wait to see the results:
The rating is calculated based on the weighting of incidents and their risk. Thus, a new security rating has been added:
Minor improvements
The following have been implemented:
- The path length of the postman HOST_URL is extended because 100 might be too short.
- It is allowed to upload several models at the same time
- The api-design-collaborator role is also allowed in models.
- All openapi-generator server options are added (So far there were only the top 5)
- The node version of the stages is updated.
- Tags have been added to the deployment with wso2 that are added to the application, not the ones that come in the openapi.
- When logging out for organizations with their own login, the logout will be redirected to their own login screen.
- When requesting validation of opportunities for organizations that have implemented login, the email should redirect to the user’s login, not the normal login. For example:https://app.apiquality.io/<organization>
- Information on tyk stages is added.
- Performance improvement in the display screen of an API.
Bugs
- It is validated that the API name is not lost when changing from one step to another within the opportunities
v2.15 TyK, Github && API Change log (2025-07-29)
Finally, tyk has moved from custom stages (on demand) to the official APIquality lifecycle. The following three steps have been developed:
- Tyk: Initializer. Creates the project to be deployed in Tyk.
2) Tyk: Deployer. Deploys the project to Tyk.
As you can see in Tyk
3) TyK: Synchronizer. Synchronizes what is deployed within Tyk itself.
From now on, the backward compatibility step will visually display the API change log indicating why compatibility is broken, leaving a historical API change log.
To do this, you need to enable the “OpenAPI Diffs” step, which checks for backward compatibility.
On this screen, it will show the changes that have occurred in the API modifications:
And if we click on view we can see the api change log
The latest Sonar Rules plugin released by the APIAddicts Foundation is installed (https://github.com/apiaddicts/sonaropenapi-rules) with the following new rules:
- OAR103 – ResourcesByGetVerb – Get Operation not recommended for resource path
- OAR104 – ResourcesByPostVerb – Post Operation not recommended for resource path
- OAR105 – ResourcesByPutVerb – Put Operation not recommended for resource path
- OAR106 – ResourcesByPatchVerb – Patch Operation not recommended for resource path
- OAR107 – ResourcesByDeleteVerb – Delete Operation not recommended for resource
- OAR108 – SchemaValidator – Schema does not match the provided example
The schemas should match the provided examples
- OAR109 – ForbiddenInternalServerErrorCheckTest – Use default instead of directly specifying 5XX codes
- OAR110 – LicenseInformation – License information cannot be empty
- OAR111 – ContactInformation – Contact information cannot be empty
Until now, functional tests had to be run by uploading the file to the Newman step. From now on, they can be configured to run directly from a repository folder:
First, you will need to configure the repository path to be taken from the organization properties:
In these properties, we put the path of the files:
and we see that we must upload the postman and environments collections to this route:
We can see that it has been executed perfectly and gives us the following result:
and we can see how the execution was:
From now on, in addition to APIs and tokens, the models that have been uploaded to the platform will be displayed:
The option to generate stress tests with K6 has been added to the OpenAPI Generator stage. This will allow us to generate the foundation for running stress tests with this technology.
Improved/Fixed:
- The possibility of manually running stages is enabled.
- Reporting for redocly, Sonar2Spectral, Microcks, and Openapi2Postman has been enabled.
- Fixed a bug where enabling/disabling some organization settings would result in a 500 error.
- The step blocking feature has been enabled.
- A crash that occurred when editing the API definition has been fixed.
v2.13 - v2.14 Model release && Stress tests (2025-06-16)
From now on, the stress testing lifecycle has been developed from test generation to execution and history.
The first thing we do is add the step “openapi generator Jmeter” that uses the openapigenerator tool for generation.
Once the step is generated, we can either clone the repository or download it locally to configure the tests in jmeter.
Now, we have to import the jmeter file
Once you have configured the tests, you can upload them in another step called “Quality tests -JMeter” where we have to upload a file and the data csv:
After executing the step, we can see the execution history:
Here we can see the average latency, throughput, errors, and we can access the more detailed report:
To facilitate migrations, an option has been added that allows you to import APIs directly from Wso2. To do this, you must configure it at the organization level:
It is activated and the configuration must be added
From there, if we import an API in the catalog screen, it will appear under source “wso2.” If we select wso2:
The APIs will be displayed so we can choose which one we want to import. If we select it, we’ll see that it’s imported correctly:
A new screen has been generated that allows the models to be provided with more functionality.
We see that the new screen is very similar to the existing API screen. The list will show whether the model is already linked to an API:
When you click on view, we see that 3 screens appear: a general one, where the model information will be shown, another one for APIs (the APIs that link to the model), and another one for auditing (to know who has been modifying the model).
The following information will be displayed in the general section:
The APIs screen displays the APIs that are linked to the model:
The APIs screen displays the APIs that are linked to the model:
This screen allows you to view the modifications made to the models. To access it, click the audit button in the model list:
and will display the following information:
A new step has been added to generate code with the openapigenerator tool.
Once the step has been added to the environment, clicking on execute will display the following screen:
Here you can select the language to generate. The generation will be stored in the API repository, and you’ll also have the option to download it locally:
If we want to download it, a “download archetype” option will be enabled where we can download it to the local as can be seen in the following image:
Pipelines can sometimes take a while, and developers tend to “refresh” the screen to check whether the process has completed. A button has now been added to the right to refresh the step information:
Minor improvements:
- A check has been added to the AI generation screen to ensure the user saves the API first before generating the API.
- An explanatory video has been added showing how to configure GitHub with ApiQuality to facilitate integration.
- New “fixed instructions” field in opportunities that acts like “fixed” fields that can be added to the template and cannot be modified.
- New “editable text” field that allows you to separate field generators with “hyphens.”
- An improvement has been implemented to display API reports on branches other than develop.
- Email delivery has been implemented for the opportunity approval lifecycle.
- It has been improved stop to cancel the pipeline. Currently, it was only canceled if it could be canceled within the repository. In this case, it will be canceled regardless of whether it can be canceled within the repository.
- Added deployment profile name to the environment run screen.
- The apidesign-collaborator profile can create new branches, and the pattern was currently fixed. It has been improved to be configurable at the organization level:
- Added the newman step to the bitbucket server to make it work properly.
- Sort Newman’s executions so that they appear in reverse chronological order:
- Clear API steps when changing environments. A small usability improvement has been made that allows steps to be cleared when changing environments, so they won’t appear to be the same while the new ones load.
- The display of the tab has been improved to take into account calculated fields:
Fixes:
- Fixed a fix that prevented Redocly issues from being displayed correctly in the online editor or API report.
v2.12 Apigee release (2025-06-02)
Obtain more information about the Wso2 deployment
And it shows the tenant where it is deployed, some configuration and the applications that consume it.
The stages that will form the basis of Apigee automation within APiquality have been designed. For now, they will only be available on demand and will be enabled as custom stages.
The implemented stages are the following:
- Openapi2apigee: Allows you to generate the PRoxy API skeleton from the API.
- Apigee-templater: Allows you to generate the skeleton of the API Proxy including policies
- apigelint: Allows you to validate that the document is valid.
apigeecli: Allows deployment to Apigee
Currently, if you modified a general stage, an organizational stage was created, which meant you never knew if there had been any changes or improvements to that stage. From now on, you can see if that stage has been modified from the environments screen, as shown in the following figure:
From this window we can update the stage directly from the update button
Minor improvements:
- Auto-execution of steps after importing an API has been removed
- The ability to edit the API name has been enabled
- Pagination has been added to the models
- An improvement has been made to the custom stage generator that automatically inserts the stage name into the stage, making execution easier.
- The ability to send emails with the reason for approval or rejection of the API ticket has been added.
- The username has been added to the JAPI stage commit.
- The Apiquality plans screen has been modified to correctly display plans and how to delete the organization.
Fixes:
- Fixed a fix that prevented redocly errors from being drawn in the API designer.
- Fixed API rating to be the average of step ratings
- A fix has been fixed that caused a crash when generating the v2 branch during pipeline execution.
- Fixed a fix where a strange character was added to line 1 when downloading the yaml.
- Stage configuration needed icon. Fixed so it only appears if the stage hasn’t been configured for the first time.
- Fixed so that style guides can be created from scratch.
- Fixed a small fix that prevented APIs from running in Azure Devops
Release notes - Jun 2025 (version 2.11)
Integration with the Github repository has been enabled.
From now on, it will be possible to use Github as a base repository. For that, you will have to link in the repository part.
The data can be obtained by following the explanatory video: https://www.youtube.com/watch?v=ym44IpxTGZ0
After that, we can import an API as with any other repository.
A new functionality has been created that allows to approve or reject tokens from APIQuality. In the organization configuration screen, opportunity approval can be enabled.
In addition, you can also restrict that only APIs with approved tokens can be created.
Now, in the list of cards/opportunities we see that a symbol for submit approval of the card appears.
This will allow sending the approval request to the responsible person both by internal notifications and by email internal notifications:
And it will be shown in the table pending approval:
The approver must enter the file and approve or reject it. If he/she rejects it, he/she must indicate the reason for rejection:
The following new rules have been implemented:
- Regla OAR003 – DefinedWso2ScopesDescription
- Regla OAR002 – ValidWso2Scopes
- Regla OAR004 – ValidWso2ScopesRoles
- Regla OAR005 – UndefinedWso2ScopeUse
- Regla OAR040 – StandardWso2ScopesName
- Regla OAR041 – UndefinedAuthTypeForWso2Scope
- Regla OAR043 – ParsingError
- Regla OAR090 – RefResponse
- Regla OAR108 – SchemaValidator
A new per-organization parameter has been enabled that indicates that Newman picks up files from a repository folder. If enabled at the organization level:
and the properties are configured at API level:
You can run the environments and collections files without having to upload them by hand:
In the online editor, a markdown function has been activated that allows markdowns to be displayed in a “pretty” way.
The option of generating external stages with external functionality of organizations is created. In this case, the JAPI Mapping tool has been integrated for the generation of microservices that allows to visually map OpenAPI fields to database fields.
Implemented:
- Added the possibility of the openapi diffs stage for backward compatibility to be blocking.
- A new organizational parameter possibility to create new environments (for branches) has been created.
- A global parameter has been created to disable API autoversioning when editing in the online editor.
- The API designer collaborator is given permissions to have permission to create feature branches of an API
Release notes - May 2025 (version 2.10)
A simplified flow has now been developed for Mulesoft deployments. The following stages have been created:
Mulesoft: Syncronizer-DesignCenter
Allows to synchronize a modified api in the design center.
Mulesoft: Deployer-Exchange
Allows an API to be uploaded to the Exchange.
Importar API
If the Mulesoft configuration is enabled in the organization, an API can be imported.
It will be possible to mass import user via CSV. Just download the sample csv,
and complete it with the users that you want to register. If the file comes with an error, the following screen will appear:
When it is correct, invitations will be sent to the users:
New fields have been created:
Instructions:
Allows you to enter an instruction field.
Calculated field:
Allows to calculate fields that are the sum of two calculated fields.
Calculated text field
Allows you to combine form fields together with text.
Calculated editable field
Allows you to combine form fields together with editable text.
Fixed
Fixed field for opportunity.
Organization properties
A new field has been added to allow adding properties at the organization level.
The possibility of editing the style guides and assigning a new style guide has been enabled. In the domain menu, editing a domain will give us the possibility to change it:
Within the General menu, there is a properties option. By clicking on properties we can create and edit new property spaces.
By clicking inside the namespace we can manage its properties:
Properties can be created here.
These properties can be added in the tabs/opportunities of the APIs.
Improvements:
- The role of api designer collaborator has been modified so that they can edit and save apis.
- An information field has been added within the steps to let you know what each step does.
- The API screen is updated after doing an API promotion so that you can update the version.
- A warning icon has been added to the newman stage when it has no configuration.
- The wso2 easy deploy screen has been corrected to show only the gateways in the environment.
- Improvements have been made to the sorting of the opportunities/tokens view.
- The generation of the redocly report has been changed to allow its download in organizations with bitbucket.
- openapi2postman download has been changed for bitbucket repositories.
- The possibility of creating new domains in organizations with bitbucket has been enabled.
- The generation of openapi2postman collections has been modified so that the file name indicates the environment.
Fixes:
- Fixed manual execution errors
- Fixed the sonarqube retry button that was not working.
- Fixed an issue where deleting questions from one step would delete questions from the rest of the steps on a card.
- It has been corrected so that domain modification does not fail.
- It has been corrected so that it does not give a gray screen error when modifying the position stages in the environment screen.
Release notes - April 2025 (version 2.9)
We have just incorporated TyK into the APiquality lifecycle and soon you will be able to have
a complete lifecycle within the platform.
From now on it will be possible to configure the steps as sequential, manual or
both. This means that the ‘play’ button will execute all the steps
that are defined as sequential.
To configure it, we must go to the environment screen:
If we click on the configuration icon:
And here we can select the type of step.
It can then be run in the play button.
The following rules have been implemented in spectral:
– OAR002 Rule – ValidWso2Scopes
– OAR003 Rule – DefinedWso2ScopesDescription
– OAR004 Rule – ValidWso2ScopesRoles
– OAR005 Rule – UndefinedWso2ScopeUse
– OAR040 Rule – StandardWso2ScopesName
– OAR041 Rule – UndefinedAuthTypeForWso2Scope
– OAR043 Rule – ParsingError
– OAR090 Rule – RefResponse
– OAR108 Rule – SchemaValidator
The following minor changes have been made:
– Removed autorun on API import.
– API file selector. If due to a name or extension change,
was out of sync, it can now be changed directly from the
application.
– Added in the organisation configuration the ability to create new
environments directly from the API.
– An exclamation mark has been created to indicate that there are unconfigured stages
– Added online display of markdown within the online editor
– Added the ability to deploy to multiple gateways for wso2
– Changed configuration of sonar project so that the project id
does not come with the branch and comes as an environment variable.
Fixed issue where api categories were not syncing properly with
the api.yaml for wso2 type deployments.
– Fixed an issue where all gateways were displayed when deploying
in wso2 regardless of the environment.
– Fixed greyed out rating display in unrated environments.
– Fixed to run apigen.springboot stage.
– Fixed bug that prevented cloning styleguide.
– Added ability for newman to be a blocking stage.
Release notes - March 2025 (version 2.8)
A new screen has been created to sort the environments. To design it, go to Settings -> Environments and the following screen will appear:
Here the order of the environments can be designed according to the deployment profile.
This order shall be used for the environment steps. For that, the openapi can only be moved from one environment to a previous environment. For this, you can go to the display screen of an api.
In the promotions of each api manager, you must also select the previous environment.
Search filters have been added for the API tab/context listings. The new screen is shown below:
From now on, only the path and description of the operation will be shown by default. If we want to add an operation, it will remain as an addition.
The api display screen has been changed to have several tabs (general, properties and audit) so that the information can be seen in a cleaner way.
The api properties will be injected into the CI / CD of the steps.
Separated definition errors from definition-based security errors in the API rating screen:
API definition display screen:
Security definition error display screen:
New test generation functionalities have been added for postman:
The new options are as follows:
- Validate Schema: Validates the output of the API information complies with the openapi.
- Generate oneOf/anyOf: Creates a test for each oneOf/anyOf option that is designed in the openapi.
- Minimal Endpoints: Create a test for each response error code and not a test for each filter, required input parameter…
- Host server pattern: Gets the host parameter according to the pattern that has been designed in the parameter within the openapi servers option.
From now on, if you activate this parameter, it will show redocly errors in the online editor:
When activated, redocly validation errors appear in the online editor:
- Error when generating the openapi on IA. From now on if the output context is too large with IA a message will be sent to the user.
- After promoting the definition between environments the page is automatically updated so that no API information remains obsolete.
- Decimal overflow in the mocking index. Decimal places are adjusted to be displayed correctly.
- Allows API opportunities / context to be modified even if already linked to an API.
- Reordered the microcks enricher so that the openapi is not changed after running sonar to match lines with definition errors / warnings.
- Openapi is not being updated with external file resolution.
- Fixed a bug where the full style guide was downloaded and not the configured style guide.
Release notes - February 2025 (version 2.7)
When the API is linked to the tab a display screen has been added:
Clicking on the tab icon will display the tab on a single screen:
By default it is still validated with sonar, but from now on it will be possible to choose whether to validate with spectral or sonar in the online editor thanks to a new configuration parameter.
From now on, it will be possible to visualise the execution history of the functional tests.
If we run newman several times, we can see how it will be loaded.
Clicking on ‘View executions’ will display a history of the executions carried out in newman.
A button has been added to download the API from the API display screen.
A new quality testing step has been added to run after api manager deployments.
The step can be activated in the environment configuration screen:
And then we see how it runs after the deployments in Newman:
The following rules have been implemented in spectral:
– OAR101 – FirstPartBasePath – The first part of the path must be one of the allowed ones.
– OAR082 – BinaryOrByte – The string properties of the specified parameters must define a byte or binary format.
– OAR102 – SecondPartBasePath – The second part of the path must be one of the allowed ones.
– OAR035 – AuthorisationResponses – When defining security schemes, authorisation response codes must be defined.
– OAR069 – PathParamAndQuery – Any param in PATH or QUERY, must have bad request response (400).
Release notes - January 2025 (version 2.6)
The online editor has been changed to use spectral and redocly in real time to avoid waiting for the execution of APIOps tasks.
These errors would be the same as those displayed locally if we use an IDE with spectral:
From now on, the domain to which the API belongs will be displayed within the API display screen.
From now on, the apis display screen will be paginated.
From now on, you can update the api manager templates. Go to API Manager templates, click on edit:
The template editing screen will appear:
The following rules have been implemented with spectral:
– OAR101 – FirstPartBasePath – The first part of the path must be one of the allowed ones.
– OAR082 – BinaryOrByte – The string properties of the specified parameters must define a byte or binary format.
– OAR102 – SecondPartBasePath – The second part of the path must be one of the allowed ones.
OAR035 – AuthorisationResponses – When defining security schemes, authorisation response codes must be defined.
– OAR069 – PathParamAndQuery – Any param in PATH or QUERY, must have bad request response (400).
A new test section will be added with the newman step in order to be able to add functional test execution after deployments.
- Fixed an issue where the organisation setup tutorial had to be skipped several times.
- Fixed the issue where the screen was greyed out after adding users to an environment.
- Fixed the issue where notifications from all of the user’s organisations appeared in the notifications icon.
- Fixed the bug that prevented the display in several wso2 gateways and only displayed in the default one.
Release notes - December 2024 (version 2.5)
The algorithm has been improved to take the api-template, the spectral style guide and the input form to generate the API.
To generate the API with AI, we must create an opportunity with an attribute of type path, like the following:
In this screen, there is a new option to create APIS with AI, which allows you to select the api template to put inside the context:
Here you can see the new api generated by the AI:
APIQuality allows you to use your own repositories, sonarQube and microcks. To indicate it better, we have enabled some screens inside Config-> repositories where we can see what we have configured and what could be configured.
Here you can configure the rest of repositories. If we click on services, we can link our own microcks and our own sonarqube.
When configuring openapi2postman we can indicate which data values we want to generate automatically in the successful and error examples. Therefore, if we go to the API editing screen and click on the opeanpi2postman step and advance configuration, we can change these values:
These values are only used when we indicate that the values are not going to be put “inline” but are going to be put in the environments. Thus, an environment will be created with the following data:
A number of properties associated with the domains have been added to improve the configuration of the pipelines.
If we click on settings-> domains the following screen will be displayed:
Properties can be added:
Creating it:
In addition you can create properties associated to the api managers, in this case for wso2, you can define tenants, api categories and gateways:
This information will be used to display inside the api managers, in this case in WSO2.
For the configuration of the different api managers, an api manager templates screen has been created. If we click on settings -> api manager templates we can upload the configuration templates that can be used.
This information will be used for API Manager stages.
It then allows us to choose the template to use:
and from here we can run the stage to prepare the project.
The initializer takes the openapi and the project template and generates a custom project configuration.
For less advanced users we have created a quick deployment form that allows a quick deployment by selecting a few data. We only have to edit the api manager configuration of the “Wso2:deployer” stage.
and here we configure the steps. In step 1 we configure the tentant:
In step 2, we configure the gateways, api categories and endpoints:
With all this we are ready to deploy in our api manager.
The following Sonar rules have been implemented in spectral:
- OAR076 – NumericFormat – Numeric types requires a valid format
Release notes - December 2024 (version 2.4)
From now on, the redocly events will be available in the online linter just like the sonarAPI ones. To be able to see it, you only need to have the redocly linter stage activated and to have passed the linter to show you the events.
In order to access the online editor from the API display screen, you must click on the right button on the redocly or sonar stage and select edit API.
This option leads us to the online editor screen:
The occurrences that are indicated as “Redocly XXX” are linter occurrences.
As of now, 3 steps of Wso2 4.2 and 4.1 have been created to complete the life cycle.
WSO2: Initializer
It allows us to initialize the ap project that we will use to deploy. To be able to activate we go to the screen of environments, and you activate it. When we give it to configure we will see the following screen:
The user and password must be of a devops permission user. The url must be the url of /oauth/token of the api manager and the api manager version.
Then, we have to go to the API lifecycle window and run it, which will create an api.yaml with the initial configuration of the openapi.
WSO2: Syncronizer
This stage allows you to synchronize the information available from the API within Wso2. To activate it, go to environments, wso2:syncronizer and activate. Then, click on configure. The configuration screen will be preloaded:
Afterwards, you can run in the execution screen:
This screen will synchronize the deployment information that is currently in the api manager. To check it, we can go to the APi file, where we will see that some WSO2 own fields have been added, x-wso2-cors, x-wso2-production-endpoints,etc.
WSO2: Deployer
This stage allows to deploy in wso2 api manager both version 4.1 and 4.2. To deploy, it must be activated in the environment screen:
and then the stage must be configured:
To run, first we will have to configure the project configuration api.yaml. The first time we must execute the initializer, so that it loads a proposed api.yaml file.
By clicking on “Edit API Manager” the api manager configuration screen will appear where the deployment values can be modified.
WSO2: Environment promotion
This stage allows to promote Wso2 information between 2 environments. It must be executed in the target environment. To activate it, it must be activated from the environment configuration screen:
Then, it must be executed from the life cycle screen:
If we click on edit api manager in wso2 deployer we an see the configuration we have brought back from validation. Now we run the deployment in the production environment.
The usability of the report screen has been improved to make it easier to see all errors at once. Now, all closed sections will appear with a summary of warnings and errors.
From now on, the positive or negative result of each execution will be notified. It will be possible to notify what we want to be notified in the notification configuration screen.
Here you will see the configuration screen:
Where we can indicate whether we want to be notified of those that have gone well, those that have gone badly or all of them.
Below is an example of email notification:
From now on, stages that need to be configured after activation are displayed in yellow.
The table of new rules implemented in spectral is shown below:
Regla | Descripción |
OAR051 | DescriptionDiffersSummary – Operation description must differ from its summary. |
OAR031 | Examples – Responses, Request Body, Parameters and Properties must have an example defined |
OAR037 | StringFormat – String types requires a valid format |
OAR034 | StandardPagedResponse – Paged response schema must be compliant with the standard |
Release notes - November 2024 (version 2.3)
A new stage has been added that allows to check if the change is breaking the backward compatibility and block the deployment. To activate it you have to go to environments and activate it as another stage.
From that moment on, if the stage breaks the compatibility, a red cross will appear:
and if it does not break it will remain green.
To see why it has broken compatibility we can look at the logs:
From now on it will be possible to change the domain of an API. Be careful because in addition to the domain, the group to which it belongs within the repository is changed.
To move an API, go to the display screen of an api, click on the three dots on the display line and select Move To new domain:
A new window with the available domains will be displayed:
By clicking on the update button the api will automatically change domain.
In order to promote the API definition to another environment we must select the target environment, go to the API display screen and execute the “move definition to environment” operation.
Then a screen will be displayed for us to select the environment from which we want to collect the definition:
When selecting merge the definition of the new environment will be the definition that existed in the source environment (in this case, we have moved the development definition to production).
From now on, users will be able to subscribe to pipeline executions. They will be able to subscribe to the entire domain or to the API.
Configuration notifications: in the notifications bell you can configure whether you want to receive notifications via the web or via email. An image is shown below:
When you click on the configuration button, the following screen will appear:
Here you can activate or deactivate the notifications and indicate the channel through which you wish to receive them. In addition, you can see the items you are currently subscribed to.
- Domain notifications: to activate the domain notifications we must go to the domain display screen and hit follow, as shown in the following screen:
From then on all pipeline executions will be notified to the user.
- API Notifications: to activate notifications to an API you must go to the display screen of an API and click on the follow icon, as shown in the following screen:
The usability of the general screen where the subscription and the general parameters of the organization are displayed has been improved. From now on, there will be 2 tabs that will allow a better visualization of the information, being able to filter by the parameters of the system. The two screens are shown below:
In order to generate the API in an agile way, an operation generation screen has been developed where you only have to enter the name of the properties, and the AI will propose a design of the API. It is important that the style guide is correct and that there is an api_template within the organization, since it will be used as a context for the generation of the new API.
In order to complete this form, it must be designed within the opportunities section. With the API administrator or architect profile, you must generate a new template of opportunities.
You must create a question that is of type path and whose answer is of type form, as shown below:
By clicking on it we will have the operations tab to be able to create the API.
Profiles that can create APIs can also create opportunities, so in the opportunities screen they can click on create:
Clicking on create will display the following form:
When clicking on create, a new “Create API” button will appear, which will be the one we will use to create the API:
By clicking it
A new API will be created:
An example of a generated APi is shown below:
Release notes - November 2024 (version 2.2)
With APIQuality, you can easily deploy your APIs in different API Managers.
With environment profiles, you can define APIOPs for different life cycles and define your stages according to the API Manager in which you want to deploy.
From now on, when uploading testing collections, the % of endpoints being tested and a summary of the test result will be calculated.
The option to view the full report is still active.
A new option has been created to cancel the entire pipeline. Just go to the API display screen and click on the cancel button.
Sometimes you don’t know which examples have been loaded in Microcks, so we have added the possibility of being able to visualize directly in APIQuality the endpoints that have an example. To do this, just click on “view mock details” in the API information:
This allows us to visualize in which operations the examples have not been loaded and to check if the mocking is being performed correctly. If we click on one of the operations we can better see the information of the loaded request:
We can also see the information of each example by clicking on them.
From now on, within the environment screen, new environment profiles can be created to define different APIOps cycles for each environment.
Within the environment screen you can see a new button that allows you to create new environment profiles.
If we click on create we can create a new environment profile:
From there, we see that we can modify the same environment (development) but for each profile. For example, for APIs that are deployed in Azure we do not want to do neither mocking nor contract tests in the development environment. We edit it in the environment and now we can see that the environments are already different for each profile:
Then, we will only have to select the environment profile when creating the api and thus select the related APIOps cycle:
The new version allows to generate a spectral from the style guide developed in openapi. This spectral will be linked to the spectral stored in each repository and therefore can be used by any API design program being compatible with the configured sonar rules.
In order to see the spectral that is generated you can go to the style guide screen:
If we download the file and put it in a repository with an api and open it with Visual Studio Code, if we activate the spectral plugin and rename the file to .spectral.yml we can see how the APIQuality rules start to validate locally as shown in the following image:
If we visualize the API repository we can see that the spectral file has been automatically generated and that simply cloning the repository and opening it with Visual Studio Code or another definition ide can be used.
If the openapi2postman stage has been activated, an advanced configuration has been added that allows you to configure the different options that the tool allows. Some screens are shown below:
- Custom Oauth2: Allows to configure the oauth requests to obtain the tokens and use them in the rest of the requests. When the oauth is activated we must add the url where we will obtain the token.
- When executed, it creates a collection with a request to oauth2:
- Is inline: Defines the data in the body of the request if the value will be collected from the environments or put directly in the request. If the value is:
- True:
- False: Data are collected from the environment:
- Schema is inline: The output schema with which the request outputs are validated is checked.
- true: The scheme for validating the output is stored in the environment configuration.
- false: The schematic is shown in postman in the scripts section.
- Schema pretty print:It allows to visually display the schema used to validate the postman’s output in order to better configure it.
- true: I is shown as follows:
- true: I is shown as follows:
- Has scopes: Indicates whether or not it has scopes. If it has scopes, the number of scopes must be indicated. If it has scopes, a request is created for each scope as shown in the image:
- Application token: Allows to test the application with user token and application token.
- Microcks headers: It allows to test a mock created with microcks. In the following image you can see how it introduces a header with the name of the example to be returned.
The resolved bugs are listed below:
- Fixed the bug that did not allow the API Designer profile to save a comment.
- Fixed the redocly bug that kept showing the report information once the stage was removed from the environment.
- The message about the limit of users in an organization has been changed when a user tries to register within the organization. So far it only showed an “error” message.
- Fixed a bug where the microcks url displayed inside an api when a new version of the API was created was not updated correctly.
- Fixed a bug that did not allow to select the binding mode (Cloud / Server).
Release notes - October 2024 (version 2.1)
A linter has been added (in this case, Redocly) that allows you to linter the API before passing the organization’s style guide.
The linter is activated within the environment’s APIOps cycle:
This linter can be executed within the APIOps life cycle:
It is also possible to review the result within the overall API rating:
Opportunities are now able to have domains and permissions management is unified with domains.
From now on the opportunities must be specified within the domains and the permissions are the same as those applied to the APIs.
When creating the opportunity we must define in which domain it applies:
Until now, the documentation displayed was generated in Microcks. Now, the documentation is generated directly in the tool itself.
As you can see, within the API screen there is an option to view documentation:
This screen allows you to view the documentation within the tool itself.
When generating new files with all the external href links, it can be configured in 3 places:
- At the organization level.
- When importing an openapi
- In a Stage
Once activated, when we work with the file with references, a file delivered in both json and yaml will be created, for later use for other tools.
Currently there are a number of parameters that are necessary to set up the style guide and make it consistent. A form has been created to register them in order to create the style guide according to the organization:
YAML Style:
One of the first things to define in a corporate style guide is the parameter definition format, input body and output body.
The rules to be configured are the following:
- OAR011 – UrlNamingConvention – The base path and resource names with more than two words must be compliant with the standard naming convention
- OAR066 – SnakeCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the snake_case naming convention
- OAR067 – CamelCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the camelCase naming convention
- OAR068 – PascalCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the PascalCase naming convention
Headers request:
This section indicates which headers are allowed in the definition and which are mandatory. Some paths can be excluded from this validation. The rule to be configured is as follows:
- OAR033 – HttpHeaders – There are mandatory request headers and others that are not allowed
Format responses:
It is important to have a unique object definition for all apis and it is a parameter to be entered in the validation in the style guide. The format is added in json format. The rule to be configured is as follows:
- OAR029 – StandardResponse – Response schema must be compliant with the standard
Paging
Paging is important in every organization and the parameters to be introduced within the organization must be defined.
Status
Normally the /status is a health endpoint that is put in the apis and it is good to indicate it in the definition.
- OAR030 – StatusEndpoint – Status endpoint must be declared
href
In the more advanced style guides not only the formatting is validated but also how the openapi are created. This option allows you to validate that the examples, components, schemas are defined in the components section.
- OAR088 – RefParam – The $ref of a parameter must end with a corresponding suffix
- OAR089 – RefRequestBody – The $ref of a request body must end with a corresponding suffix
- OAR090 – RefResponse – The $ref of a response must end with a corresponding suffix
- OAR091 – ParamOnlyRef – Parameters must contain only references ($ref)
- OAR092 – RequestBodyOnlyRef – RequestBody must contain only references ($ref)
- OAR093 – ResponseOnlyRef – Responses must contain only references ($ref)
Special parameters
It is good praxis to add special parameters to make the api more flexible like $select, $expand… but not all companies have it. With this check you can enable all of them together. The following rules are enabled:
- OAR019 – SelectParameter – the chosen parameter must be defined in this operation
- OAR020 – ExpandParameter – the chosen parameter must be defined in this operation
- OAR021 – ExcludeParameter – the chosen parameter must be defined in this operation
- OAR022 – OrderbyParameter – the chosen parameter must be defined in this operation
- OAR023 – TotalParameter – the chosen parameter must be defined in this operation
- OAR024 – StartParameter – the chosen parameter must be defined in this operation
- OAR025 – LimitParameter – the chosen parameter must be defined in this operation
- OAR028 – FilterParameter – the chosen parameter must be defined in this operation
A new option has been added in the organization settings to secure mock calls through an apikey.
An option has been added to secure the call to the microcks mock endpoints.
Blocking stages have been enabled. For the moment, it is only available for the sonar style guide. In order to define a minimum letter, it must be set within the APIOPs cycle within the environment and the minimum letter must be selected:
A checkbox is added at the organization level to enable or disable the mocking server to be added automatically:
If we configure this option all the openapi will be generated with a new server with the microcks url:
The option to deploy in Wso2 has been enabled by configuring the api.yaml for the Wso2 version.
Once the stage is enabled, inside the stage itself we can configure this file.
The api.yaml file for the environment is shown below.
If we deploy the API, it can be seen in Wso2.
Removing sonar credentials from the repository
For security reasons, the sonar credentials are removed from the sonar.properties file.
- Fixed a bug where sonar rules were duplicated when creating a new style guide.
- Fixed a bug that generated failures when updating an api from the editor.
- Modified to show the test scoring.
- Fixed a bug that caused an error in the dates when uploading a new API or modifying an existing one. The update is no longer empty.
- Fixed a bug where the creation and modification date was displayed on February 16, 2023.
- Fixed a bug where two “undefined” were shown in commit messages. It is also solved that it is registered who has launched the execution.
- Fixed a bug that allowed to create branches with tilde in the name.
- Fixed a bug that didn’t allow to delete a local branch.
- Fixed a bug that didn’t allow to delete global branches.
- Fixed a bug that did not generate the resolved folder.
Release notes - August 2024 (version 2.0)
In the new version it is possible to obtain information directly from the execution of the CI/CD stages. This option will be available by clicking on the icon (cross or ok) available in each stage.
The information is shown below:
From now on, there is a new option to display the CI/CD execution history directly from APIQuality. This option will be available in the context menu available in the execution.
From now on it will be possible to change both the name of the api and the name of the repository file directly from the interface. All you have to do is click on edit in the API display screen:
And it will be changed automatically in the repository
The environments (branches) that are created at the organization level will be available for all APIs, being able to define personal branches in each API.
Only administrators and api architect will be able to define branches for all apis.
For openapi using external files, a new functionality has been created to generate the openapi with the external references. This functionality can be configured by the organization administrator in settings.
or it can be done only on the file we are importing:
or it can be created as another stage:
The user name has been added in the commits so that it is possible to see who has made the changes. Until now it was the generic APIQuality user that was displayed without specifying who the APIQuality user was.
For enterprise licenses a new front end has been enabled where they can login with SAML and connect their corporate login.
Below is a list of small improvements:
- Sort domain field when uploading a new API.
- Permissions have been given to the api design to be able to see the models.
The following is a list of bugs in the version:
- It is modified so that it does not show as editor the creator of the api.
- A bug is solved in which when creating a new branch it could take the name of the old file that had been previously deleted.
FAQs
Do you have any doubt about how APIQuality works? These are the most frequent questions and answers (FAQs) that our clients ask to us.
APIQuality is a platform that facilitates the development, testing and deployment of APIs. It is designed to help you implement the API-First methodology in an efficient and automated way. Basically, it makes working with APIs much easier and safer.
With APIQuality, you can:
- Create prototypes automatically: We generate models of your APIs from definitions.
- Perform continuous testing: We run automatic tests to make sure your APIs work correctly.
- Generate test data: We create dummy data to test your APIs in different scenarios.
- Simulate errors: We test how your APIs respond to failures to improve their robustness.
- Deploy and monitor: We manage your APIs and monitor their performance in real time.
Using APIQuality offers you multiple advantages:
- Automation: We reduce manual work in the development and testing of APIs.
- Security: We detect and fix vulnerabilities automatically.
- Integration: We work with popular tools such as Gitlab and Postman.
- Flexibility: We support technologies such as C# .net and Java Springboot.
In APIQuality we have several plans according to your needs:
- Free Plan: Free, allows you to manage up to 5 APIs.
- Business: from 29€ per month, to manage up to 30 APIs. Each extra developer costs 5€.
- Enterprise: price on request, with no limit on the number of APIs.
- Dev Portal: price and conditions on request.
Each plan is designed to suit different levels of use and business needs.
At APIQuality we perform real-time security scans to detect and fix vulnerabilities. It also provides detailed statistics and helps you define security standards for your APIs, ensuring that they comply with industry best practices.
To offer you the best, APIQuality integrates several open-source tools such as:
- OpenAPI2Postman: To generate tests and validations.
- doSonarAPI: To validate API definitions according to corporate standards.
- API Generator: To create archetypes of microservices connected to databases.
If you need help, you can contact our APIQuality support team by sending an email to contacta@apiquality.io or by calling +34 917 64 79 82. You can also use the contact form on their website for any inquiries.
In hybrid versions, sonarlint can be used to test directly locally.
If you put in the comment the name of the stages, the configured stages will be executed in APIQquality.
Yes, you can create a custom stage that uses the operations you have inside your CI/CD.
In this case the hybrid version uses a vpn to be able to connect to the local parts. For the hybrid version it can only be used in the enterprise license.
No, but we will soon have a version that will allow you to change the order.
Currently GitlabCI and Bibucket can be used and Github and AzureDevops are being worked on. If you use another system, it can be easily used using webhooks from your CI/CD system to GitlabCI.
You must understand that the system used is APIOps, which means that the processes are executed in the CI/CD and sometimes it may take some time to assign an execution job.
Currently there are only two versions, SaaS and Hybrid version. If you have other needs, do not hesitate to propose it to the product team.
In this case, you should talk to the APIs governance team or the people in charge of defining the style guide, to find out if they have any parameterization errors.
Yes, but Microcks comes by default inside the tool.
In the SaaS version this is not possible, but you can develop different configurations directly within openapi, depending on the openapi extensions.
This is not possible in the SaaS version, it can only be done in the hybrid version.
By now, API Quality can use Mulesoft, WSO2 3.2, WSO 4.1, Kong 2.X, Azure API Management, Apigee X, AWS API Gateway.
APIQuality is offering API Rating for both definition, quality, mocking and definition-based security. Work is in progress to add our metrics.
The default APIOPs concept is in GitlabCI in SaaS. But that doesn’t mean you can’t plug in your own CI/CD continuous integration system.
Not for the moment.
For the generation of microservices we use APIgen ASP.NET and APIgen Java Springboot, where do these generators come from?
These generators have been developed by different companies under the umbrella of the APIAddicts foundation. You can see the projects at:
APIQuality: plataforma de APIOps para empresas
Ahorra un 70% de tiempo y crea mejores productos
Aumenta la productividad de tu equipo en un 82%
Multiplica el consumo y uso de tus APIs
APIQuality: innovación y apoyo a tu alcance
Tu éxito con APIs comienza aquí. En APIQuality, combinamos tecnología avanzada, soporte dedicado y una comunidad activa para ayudarte a transformar tus procesos y alcanzar tus objetivos más rápido.
¿Listo para llevar tu gestión de APIs al siguiente nivel?