--- schema_version: "1" id: 897c3c86bb24a90b890f4199d26b4af26cc51ee2f52bf0828a440d65aa1d609e title: API Designer (Crowd) Release Notes collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/release-notes/design-center/design-center-release-notes-api_specs.md canonical_url: https://docs.mulesoft.com/release-notes/design-center/design-center-release-notes-api_specs source_site: docs.mulesoft.com content_type: documentation content_hash: 661d51ba02ce2f222d23284bc50bdbb2a0d592684d3c42369e676e6fd76e94da description: MuleSoft Documentation Site latest: true --- --- product: Release Notes version: master --- # API Designer (Crowd) Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt These release notes cover the following versions of API Designer (Crowd): ## 2.83.200 **August 21, 2026** ### What’s New ### User Interface Improvements - The Documentation pane in API Designer now correctly displays operation labels for AsyncAPI specifications. - The API Documentation pane now correctly displays all properties from schemas that use `allOf` composition, including properties from deeply nested schema extensions. - Navigating directly to an API Designer project URL without an active session no longer redirects you to the Design Center home page. API Designer now opens the requested project after a successful sign-in. ### Fixed Issues
Issue ResolutionID

Design Center no longer displays an Authentication Required error when GitHub integration returns a 403 error due to an expired or revoked token.

W-23448410

When a branch merge fails, API Designer now displays an error instead of a false success message.

W-21683785

The project lock is now correctly released when a user exits API Designer through the Anypoint Platform navbar, closes the browser tab, reloads the page, or navigates away using the address bar.

W-21980033

## 2.79.0 **April 4, 2026** ### What’s New - You can now use **Go to Definition** and **Rename Symbol** actions reliably in API Designer. These actions no longer fail when working with OAS specifications. - You can now see a clearer error message when publishing to Exchange fails due to a mismatch between the `exchange.json` configuration and the authenticated user. The message now indicates that the `groupId` must match your organization UUID. - You can now see correct rendering of `nullable: true` fields in OAS 3.0 specifications in the API Documentation pane. These fields are now displayed as **Array or null**, and the original description is preserved. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.10.0-0. ### Fixed Issues
Issue ResolutionID

Switching GitHub branches in Design Center no longer overwrites the local working copy when the authenticated user lacks the required repository permissions.

W-20037105

API Governance no longer sends error notifications when the API specification does not contain errors in API Designer.

W-19675036

The Governance validation progress bar in Design Center no longer remains stuck in the Validation in progress state after a validation failure.

W-20031294

Union types in RAML 1.0 DataType definitions that include arrays (for example, type: lib.user | nil) are now correctly rendered in the API Console documentation pane as Array or null instead of a generic union or single object.

W-19861175

## 2.76.0 **November 20, 2025** ### What’s New - API Designer now limits projects to a maximum of 100 dependencies. - API Designer now redirects users to the Design Center home page after deleting the current project. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.9.1-3. ### Fixed Issues
Issue ResolutionID

OAS specifications are now rendered correctly in Design Center and Exchange.

W-17403032

RAML annotationType definitions are now rendered correctly at the method level.

W-16582426

Design Center now displays an error message when a branch merge fails.

W-17324282

The Examples Required ruleset no longer shows errors for URI parameters that already include examples.

W-15844364, W-16070725

API Console documentation pages are now displayed correctly when libraries with empty examples are referenced within a RAML project.

W-17902371

OAS component fragments can now be published to Exchange without triggering an invalid root file error.

W-18987255

The Design Center project filter now works correctly when project names contain spaces.

W-19304737

Validation errors in OAS specifications are now displayed at the correct line number.

W-17026937

The Download / Mule 4 Connector feature in Exchange now works correctly for multi-fragment OAS assets published from API Designer.

W-17421488

Validation no longer fails with a “RangeError: Maximum call stack size exceeded” message for specific RAML specifications.

W-16879247

Validation now correctly raises an error when a path parameter is referenced in an endpoint URI but not defined in the parameters section.

W-18252679, W-17776609

Nested references in external OAS fragments are now resolved correctly.

W-18018893, W-18034660

Documentation overview in API Console no longer disappears when using oneOf and defaultContentType in an AsyncAPI specification.

W-18010141

OAuth 2.0 security definitions now include the required flow field when converting a RAML API to OAS.

W-17981210, W-17495471

Missing items fields in array types are now correctly generated when converting RAML specifications to OAS 2.0.

W-18062983

The Parameters referenced in the path string must be defined error no longer appears when using the Anypoint Best Practices ruleset (v1.6.4).

W-17756973

The OperationRef object now supports escaped characters in JSON Pointer syntax when referencing paths in OAS specifications.

W-18556488

Design Center now displays a preview for RAML project files when opening the “View code” option from Exchange while not logged in.

W-19897297, W-20002392, W-20189489, W-20198464, W-20174392, W-20220656

RAML examples defined with YAML notation are now displayed without unwanted escape characters in the UI.

W-17290968, W-18189939

The Syntax error in the following text validation message no longer appears for valid OAS components.

W-17106459

## 2.75.2 **March 25, 2025** ### What’s New - API Designer and Design Center now enforce file type validation when importing files, allowing only supported formats. ## 2.75.1 **November 19, 2024** ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.6.3-0. ### Fixed Issues
Issue ResolutionID

OAS 3 Component fragment references are now resolved correctly.

W-16971126

## 2.75.0 **November 9, 2024** ### Autocompletion Improvements - You now see `$ref` suggestions under user schemas on AsyncAPI 2.6 API Specifications. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.6.3. - You can now use a Solace server without triggering warnings in the AsyncAPI Best Practices ruleset. ### Fixed Issues
Issue ResolutionID

You can now use required properties inside conditional fields on JSON Schemas correctly.

W-16798864

You now see the Validate for Governance button once the API model has finished loading.

W-15674453

You now see the displayName of a property shown corretly in the API Console

W-16683090

## 2.74.0 **October 12, 2024** ### What’s New - You can now search only valid characters when filtering API Projects. ### New Features - This product has a refreshed UI. This new UI brings the product visually closer to the [new visual style of Salesforce](https://www.salesforce.com/blog/salesforce-cosmos-slds-2/) and enhances consistency, accessibility, and the user experience. Changes include a refreshed navigation, icons, and colors. Note: Some new features may not be available immediately as they are being activated progressively for clients. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.6.2. ### Autocompletion Improvements - You now see the `defaultContentType` field on the auto-complete suggestions on an AsyncAPI 2.6. ### Fixed Issues
Issue ResolutionID

API specifications published on Exchange through Studio now automatically get a git tag.

W-16808944

## 2.73.0 **September 28, 2024** ### What’s New - You can now see the dependencies and rulesets options button without having to expand the Dependencies panel. ## 2.72.1 **August 27, 2024** ### Fixed Issues
Issue ResolutionID

You can now share projects with a team without getting an Unable to update project permissions error.

W-16570967

## 2.72.0 **August 17, 2024** ### What’s New - Certain dependencies are updated to improve security when authorizing the GitHub Application. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.5.4. ### Fixed Issues
Issue ResolutionID

You now see payload properties in the documentation pane in AsyncAPI JSON Specifications.

W-16254309

You now see the examples in the documentation pane when including RAML library data types in API Specifications.

W-14798477

## 2.71.0 **July 20, 2024** ### What’s New - You now see a 500 status code error when the dependency resolver fails. - You no longer see an error when selecting a Github project if you’re not synced to GitHub. You can open the project in read-only mode instead. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.5.3. ### Fixed Issues
Issue ResolutionID

You no longer get a validation exception can’t resolve reference error message when validating a JSON schema fragment.

W-14796249

## 2.70.0 **June 24, 2024** ### What’s New - You now receive a notification if the project size is likely to affect performance. - You now see a login message when your session expires. Note: Some new features may not be available immediately as they are being activated progressively for clients. ### New Features - API Designer now supports AsyncAPI 2.6. To learn about the AsyncAPI journey, see [AsyncAPI Support to Implement Event-Driven Architecture](https://docs.mulesoft.com/release-notes/platform/event-driven-api). ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.5.2. ## 2.69.0 **May 25, 2024** ### What’s New - You can now successfully see the Design Center project list after navigating through settings. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.5.1. ### Fixed Issues
Issue ResolutionID

Exchange dependencies are now updated when you use / in a branch name.

W-15780320

## 2.68.1 **April 30, 2024** ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.5.0-0. ### Fixed Issues
Issue ResolutionID

You can now successfully publish API RAML fragments with multiple dependencies to Exchange.

W-14931067

## 2.68.0 **April 27, 2024** ### What’s New - You can now see text with links highlighted in the **Publish to Exchange** modal. - You can now click the version link on the **Publish to Exchange** modal to be successfully redirected to your asset. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.5.0. ## 2.67.0 **April 6, 2024** ### What’s New ### New Feature - You can now select the project’s branch before opening your projects in Design Center. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.4.9. ### Fixed Issues
Issue ResolutionID

You can now put spaces in the search bar of the Share project modal and get the correct results.

W-15191959

You now see the correct error message when referencing a non-existent response object in an API fragment.

W-15570769

## 2.66.0 **March 2, 2024** ### What’s New - Media types now show in alphabetical order in API Designer Visual mode. - The horizontal scroll bar is now hidden when there are no errors to show on the **Project Errors** panel. - You now need to enter a valid asset ID to publish an API specification to Exchange. ### New Features - Validation of Governance rulesets is improved. If you enable manual validation mode, you now see a `No conformance issues to show after validation` message on the **Project Errors** panel after successful validation.+ If the validation fails, you can copy the details of the error to your clipboard to see the non-validating ruleset. ### Fixed Issues
Issue ResolutionID

You can now see examples in the API Console when defining nullable properties as true.

W-14855586

Now only the exchange_module folder and the exchange.json file re-fetch when importing a .zip file with dependencies to improve performance.

W-14616485 / W-14234271

Now only the exchange_module folder and the exchange.json file now re-fetch when adding, deleting, or changing a version with dependencies to improve performance.

W-14616485 / W-14234271

Files are now re-fetched after publishing specifications to Exchange to improve performance.

W-14616485 / W-14234271

## 2.65.0 **February 3, 2024** ### What’s New - You can now see the correct language badge tag on the `Rulesets` and `Import from Exchange` modals. - You can now use paste options on API Designer. - You can now scroll to see all your files on the `Replace file` modal. - The Filter by project name field now resets when switching organizations. ### Fixed Issues
Issue ResolutionID

You can now see examples in the API Console when defining nullable properties as true.

W-14249741

You can now see examples in the API Console when providing them under properties with XML attributes.

W-14615657

You can now see examples in the API console when defining payload properties on AsyncAPI specifications.

W-14572757

You now see an authentication required message when you don’t have permission to access a project or your session has expired.

W-14674994

Performance is improved on API specifications.

W-14557131 / W-14236380

## 2.64.0 **January 6, 2024** ### What’s New - Now, when switching between the **API Projects** and the **Shared with me** tabs on the Design Center home page, the project name input field resets. ## 2.63.0 **December 9, 2023** ### What’s New - You can now filter files by `.` or `+` characters. ### New Features - Project owners and organization administrators can now transfer their ownership to a different organization member. For more information, see [Design Center Permissions.](https://docs.mulesoft.com/design-center/design-assigning-permissions) ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.4.5. - You can now narrow `int64` base types to `int62` base types without getting an `invalid type inheritance base type` error message. ### Fixed Issues
Issue ResolutionID

Your API now shows the correct header name when defining header parameters.

W-14438988

You can now see examples in the correct format when defining XSD schema examples.

W-12623953

You can now convert your API from OAS YAML to JSON without having some query parameters under the x-amf-queryParameters tag instead of under the parameters tag.

W-13976753

You can now see validation issues in the Publishing to Exchange modal when trying to publish an API.

W-14399162

You can now reference existing components in API Fragments without getting a cannot find parameter or payload reference error message.

W-14380118

You can now reference response types in Open API specifications without getting a cannot find response reference error message.

W-13759080

You can successfully access synced with Github projects with more than 30 branches.

W-14408711

You can successfully open RAML specifications without getting error messages.

W-14445080

## 2.62.0 **November 11, 2023** ### What’s New - You can now change the version of your dependencies without removing them from your project. - You can now delete one version of your dependency to remove all versions from your project. - The `project limit reached` dialog is improved to facilitate the use of assistant technologies such as screen readers. - You can now delete a project directly from the Design Center home page. ### New Features - You can now disable auto-validation of Governance rulesets to run a single validation for each ruleset rather than triggering multiple automatic validations that can exhaust your resources. For more information, see [Improving Ruleset Validation](https://docs.mulesoft.com/design-center/design-add-api-dependency#fix-gov-issues). ### Autocompletion Improvements - You now get suggestions for `!include` tags in RAML specifications and `$ref` properties in Async APIs. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.4.4. - You now get a message specifying we don’t support XML 1.1 when referencing a XML 1.1 file. ### Fixed Issues
Issue ResolutionID

You can now publish complex API specifications without getting an error message.

W-14251387 / W-14216791

You can now successfully see the conformance issues of your projects.

W-14210545

You can now include XSD files as data-type for a request in an API specification without getting a schema document xsd cannot include itself error message.

W-14202641

You can now successfully publish to Exchange without delays.

W-14094069

## 2.61.0 **October 13, 2023** ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.4.3-0. ### Fixed Issues
Issue ResolutionID

The Security section of the API Console is not updated between endpoints.

W-14008660

## 2.60.0 **September 30, 2023** ### What’s New - API project `exchange.json` files are now displayed in pretty print format when you create new projects. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.4.2-4. - You can now parse a union of three or more members that are not nested under a different union. ### Fixed Issues
Issue ResolutionID

You can now define child properties without having them display the mandatory fields of the parent property in the API Console.

W-13770031

You can now define reference a RAML library without getting a Resolution error: incompatible types [shape,shape] error message.

W-14109695

You can now publish RAML libraries without getting a should be integer should match some schema in anyOf error message.

W-14074325

You can now publish a RAML specification without getting a cyclic inheritance: id? → id? error message

W-14105863

You now see a Resolution error: invalid scalar inheritance base type error message when having an invalid RAML specification.

W-13217899

## 2.59.3 **September 1, 2023** ### Fixed Issues
Issue ResolutionID

You can now create connectors to use with Flow Designer and Anypoint Studio, and publish those to exchange, without getting an email with the Invalid scalar inheritance base type any cant override error message.

W-13794149

You can now define examples with union type properties without getting a Should NOT have additional properties…​ error message.

W-13820034

### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.4.1-4. ## 2.59.0 **August 19, 2023** ### Fixed Issues
Issue ResolutionID

You can now use multiple Oauth 2.0 properties when parsing OAS 3.0 APIs without getting a scope not found error message.

W-13723448

You can now see the examples in the API console when defining multiple response examples.

W-13609146

You can now see query parameters defined as a union correctly listed in the API console.

W-13580768

You can now properly see error messages in the API console.

W-13260699

## 2.58.0 **July 22, 2023** ### Fixed Issues
Issue ResolutionID

You can now see XSD schema content types in the API Console.

W-13195361

You can now use oneOf properties without getting a specify the data model error message.

W-13062033

Performance improvements are implemented when validating large APIs before publishing to Exchange.

W-13280705

## 2.57.0 **June 24, 2023** ### Fixed Issues
Issue ResolutionID

You can now see a list of errors as soon as you add a new ruleset, or open a project with existent rulesets.

W-12707967

## 2.56.0 **May 29, 2023** ### What’s New - API Designer now supports new audit logs. For more information, see [Audit Logging](https://docs.mulesoft.com/access-management/audit-logging). ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.3.0. - You now see the correct error message when using different formats for two examples of the same type. ### Fixed Issues
Issue ResolutionID

When the OAS API spec schema is not defined, it now defaults to HTTPS.

W-12592278

You now see the information typed in kafka bindings displayed on the API Console for AsyncAPI specifications.

W-12528269

## 2.55.0 **April 29, 2023** ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.2.6. - You now see an error message when using a JSON schema with `type inheritance` properties. ### Fixed Issues
Issue ResolutionID

You can now successfully generate an access token from the API Console.

W-12065711

## 2.54.0 **April 1, 2023** ### What’s New - You can now select API fragments with the same name when selecting API fragments in the Dependencies modal. - You are now redirected to the documentation page when clicking **Help with Sharing API projects** on the share dialog. ### New Feature - You can now disable the API Designer GitHub Integration. For more information, see [Disabling the GitHub Integration](https://docs.mulesoft.com/design-center/design-ghs-install-authorize#disabling-the-github-integration). ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.2.5. - You now see an error message when a RAML type is invalid. (For example, in `properties: products []` you now see `[] is not a valid type`) - Design Center now validates that the property type and the `discriminatorValue` field are the same. ### Fixed Issues
Issue resolutionID

You can now see exactly where the error is when validating union types with an empty array in a RAML 1.0 specification.

W-12513290

You can now see an error message in the API Console when building a request with a question mark as a header.

W-12371572

You can now properly publish a new version of an existing asset to exchange.

W-12359794

## 2.53.2 **March 20, 2023** ### What’s New - API Designer and Design Center fonts are updated to improve legibility, localization, and site performance. ## 2.53.0 **March 4, 2023** ### What’s New - You now get a confirmation message when removing a fragment from the Exchange Dependencies panel. - When you open an API specification created in Visual mode through the Exchange portal, it opens in the Visual editor as Read only mode. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.2.4. ### Fixed Issues
Issue resolutionID

You no longer get an incorrect error when defining examples in parameters and headers. Note that the Required Examples version must be updated to 1.0.3.

W-12205009

You can now see where exactly the error is when defining examples in parameters and headers.

W-12059358

You can now see the correct information in the API Console when defining AnyOf properties.

W-12163469

You can now see all properties in the console when defining AllOf properties.

W-12138301

You can now see the correct information in the API Console when defining OneOf properties.

W-12080342

The API console now shows the endpoint details when opening an API fragment project.

W-12266057

## 2.52.0 **February 4, 2023** ### What’s New - You can now set the API version directly from the code when publishing API specifications in OAS 2 or OAS 3. - You can now edit the example area in Visual API Designer mode without losing your place on the page. - You can now use the **Chance access** button with the keyboard. ### Autocompletion Improvements - When defining an `ExternalFragments` property in a OAS specification, it now links to the referenced node properly. ### New Features - You can now create API Fragments in RAML, OAS 3.0, and JSON Schema format. For more information, see [Create and Publish an API Fragment in the Text Editor in API Designer](https://docs.mulesoft.com/design-center/design-create-publish-api-fragment) > [!NOTE] Studio does not support OAS 3.0 fragments. ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.2.3. ### Fixed Issues
Issue resolutionID

You no longer get incorrect API conformance errors when defining the 204 status code in the response. Note that the Anypoint Best Practices version must be updated to 1.5.1

W-12447219

## 2.51.0 **January 21, 2023** ### What’s New ### User Interface Improvements - API Designer displays an error message when you publish an asset with invalid values in the `Business Group ID`, `Asset ID`, or `Asset name` fields in the Publishing to Exchange dialog. - You can now see the correct information when clicking the **Exchange** tab on the sidebar in the read-only asset page. - You can now use `control + F` to search for strings in a project with errors without crashing the browser. - The exchange tab is no longer visible when viewing code from Exchange. - The Design Center User Interface is updated for better accessibility. ### New Features - New Design Center Business Group and Project Level permissions are added for more granularity when sharing projects. For more information see [Design Center Permissions.](https://docs.mulesoft.com/design-center/design-assigning-permissions) ### Improved Specification Validation in the Text Editor - API Designer now supports the AML Modeling Framework (AMF) 5.2.2. ### Fixed Issues
Issue resolutionID

The example data field is now null in the API Designer documentation when a string property is defined with the nullable field set to true for an OAS 3.0 specification.

W-11323805

You can now use the < and > characters when defining an enum property without them being validated as XML characters for a RAML 1.0 specification.

W-12019663

The API console now shows the correct data when using the discriminator field in the definition of a JSON schema.

W-12039245

You can now convert a RAML 1.0 API specification to OAS 3.0 when defining a union type with null values.

W-12099989

## 2.50.1 **December 15, 2022** ### Fixed Issues
Fixed resolutionID

You can now open a published project from the Exchange portal with API Designer without getting an error message.

W-12040250, W-12218977, W-12284772

## 2.50.0 **December 10, 2022** ### What’s New ### User Interface Improvements - The user interface navigation is updated for better accessibility - You now get an error message when publishing an invalid asset in exchange. - You can now see a visual indicator of the keyboard focus when navigating through the visual editor mode. ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 5.2.1. ### Fixed Issues
Fixed resolutionID

You can now define a scope callback URL and have its value displayed in the Security tab of the Summary.

W-12003404

## 2.49.0 **November 12, 2022** ### What’s New ### User Interface Improvements - When creating an API Spec in the **Visual editor mode**, you can now successfully delete and add new content in the **Example** area of a data type. - You can now navigate through the **Filter** menu of a project with your keyboard. - You can now properly see the values defined for `enum` types in the **Query parameters** section in the summary page of the API documentation. - You can now successfully generate a request URL with a defined path parameter. ### Autocompletion Improvements - When defining `AnnotationType` and `properties` in RAML, you no longer get incorrect suggestions. - When suggesting boolean fields in OAS2, you no longer get incorrect suggestions that add double quotes. ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 5.2.0. - You no longer get validation errors when defining additional properties. ### Fixed Issues
Fixed resolutionID

You can now succesfully preview DataType documentation when using minItems and maxItems properties in the Summary page of the API documentation.

W-11848788

You can now use a root $id on JSON schema documents without getting an error message.

W-11689045

Now, in the summary page of the API documentation, you see the object name as label instead of the properties value added in the request panel.

W-11866516

## 2.48.5 **October 29, 2022** ### New Features - Added a security layer to the API console, so that only registered domains are reachable. For more information, see the [Allowlisting Trusted Domains documentation.](https://docs.mulesoft.com/access-management/allowlisting-trusted-domains) - You now get an email notification when your API fails conformance to rulesets your organizations validates. For more information, see the [Adding Dependencies to an API-Specification Project documentation.](https://docs.mulesoft.com/design-center/design-add-api-dependency) ### Fixed Issues
IssueID

When publishing an API specification from API Designer to Exchange, the version field is now pre-populated according to what you define in the API spec. For more information, see the Publishing API Specifications documentation.

W-11705888

## 2.48.0 **October 15, 2022** ### What’s New ### User Interface Improvements - You can now edit the **API Version** field when publishing a project to exchange. - The Publish button is updated for better accessibility, and a new **Exchange** tab is added to the sidebar. - You can now use special characters when renaming branches on projects synced to GitHub. - You can now have multiple response status codes on API Visual Designer. ### Improved Specification Validation in the Text Editor - API Designer now supports AML Modeling Framework (AMF) version 5.1.0. ### Fixed Issues
IssueID

You can now successfully preview documentation for DataType fragment files.

W-11649355

You no longer get incorrect API Governance conformance errors when adding an API fragment as a dependency.

W-11587420

You can now successfully refer to API fragments without getting conformance errors.

W-11460246

You can now properly use the oneOf property to define two different messages for AsyncAPIs documentation.

W-11091661

## 2.47.0 **September 13, 2022** ### What’s New ### User Interface Improvements - When defining multiple keys in an OAS 3 spec, they now show the correct documentation and labels associated with those fields. - When entering the Try It panel, the Client ID field no longer shows an error message, and the warning messages are fully and correctly displayed - You can now click on **Clone**, **Edit**, and **Delete** using assistant technologies. - You can now see a visual indicator of the keyboard focus when navigating through API Specification fragments. - You can now enter values for query parameters without losing focus. - You can now extract the body of your project to a new data type without getting an error message. - You can now navigate through UI elements with the keyboard. ### Autocompletion Improvements - When using the `securedBy` and `SecuredByCompletionPlugin` fields with RAML files, you no longer get incorrect suggestions. - When using API annotations that generate a YAML Map, you will now be suggested to include a break line at the end instead of an empty space. ### Fixed Issues
IssueID

The customer header is now displayed correctly when enabled.

W-11407528

You now get an error message when creating invalid RAML (union types with enums) definitions.

W-11381880

When designing an API specification using OAS 3.0, you no longer get a duplicated resource path error message.

W-11295643

## 2.46.0 **August 20, 2022** ### What’s New ### User Interface Improvements - You can now navigate through the Exchange Dependencies panel using assistant technologies such as screen readers. - When clicking **View Code** on a published exchange asset related to a no longer existing branch, you no longer receive an error message. - When clicking **View Code** on a published exchange asset, you no longer receive an error message. - When renaming your branches with a `$` character, you no longer receive an error message. - When renaming or cloning a project, you now need to enter a name before confirming. - Design Center now includes links to our Github Synchronization documentation page. - You now have more granularity in API Designer permissions. ### New Features - All user interface components have been updated to APID Components v3. ### Fixed Issues
IssueID

You can now click Authorize to successfully connect your Github account with Design Center.

W-11585264

You can now use API Governance rules without getting an error message.

W-11225118

Namespaces and tags are now successfully displayed when added on examples for content-type application/XML schema.

W-11077505

The Datagraph Admin permission can’t be used to download Design Center projects anymore.

W-11253041

## 2.45.0 **July 23, 2022** ### What’s New ### User Interface Improvements - The user interface navigation is updated for better accessibility. ### Autocompletion Improvements - You can now see suggestions under the `uses` property in a library fragment when defining data type properties in RAML Data Type fragments files. ### Improved Specification Validation in the Text Editor - API Designer now supports AML Modeling Framework (AMF) version 5.0.10. - When you use `$ref` in OAS Parameter Specifications, you no longer receive an error message. ### Fixed Issues
IssueID

You can now edit a branch from exchange without having its content overwritten with other branches.

W-11378789

You can now successfully filter by Project Type.

W-11429747

You can now define the root file for Async projects imported from Github.

W-11279542

API designer now successfully deletes a branch after a merge.

W-11253255

API designer now creates the correct documentation for an AsyncAPI when using multiple messages.

W-11091661

Governance conformance issues are no longer shown in the Functional tab.

W-11316515

When you view code from Exchange in the text editor, you no longer receive a 'No zip file for gav' error.

W-11316441

## 2.44.0 **June 25, 2022** ### What’s New ### User Interface Improvements - When using the expander toggle (`>`) on the Errors panel, you now expand the item you selected instead of multiple items. - When you click **Cancel** on a create dialog, you no longer receive an error message. - You can now navigate through create menus without losing focus. ### New Features - GitHub Synchronization is a version control tool that maintains API specifications existing in several locations. Use GitHub Synchronization to enable two-way synchronization between API Designer and your GitHub repository. For more information, see the [Github Synchronization documentation](https://docs.mulesoft.com/design-center/design-ghs-about-github-sync). - You can now re-name the main branch in adherence to our Inclusive Product Language Program. ### Autocompletion Improvements - You can now see suggestions when defining data type properties in RAML Data Type fragments files. ### Improved Specification Validation in the Text Editor - API Designer now supports AML Modeling Framework (AMF) version 5.0.9. - All AML Dialect JSON Schema `integer` types are now converted into `long` types to support larger numbers. ### Fixed Issues
IssueID

You can now add a new response on a resource instead of replacing the existing one while using the visual editor.

W-11262351

## 2.43.0 **May 28, 2022** ### What’s New ### User Interface Improvements - User interface terminology and navigation have been updated for better accessibility. - The text editor sidebar and editor shelf expander toggles (`>` and `<`) are no longer overlapped with other elements. - When you view code from Exchange in the text editor, you no longer receive a 'No zip file for gav' error. - The visual editor UI now validates the resource name field and disallows entry of invalid characters such as double quotes ("), carat (^), and percent (%). - You can now successfully import an example from the visual editor. ### Improved Specification Validation in the Text Editor - API Designer now supports AML Modeling Framework (AMF) version 5.0.8. - In OAS3 APIs with references to endpoints that have references to schemas, second-level references with valid paths are resolved properly. - When you convert a RAML API to OAS 2.0 and `mediaType` is defined for an endpoint, the text editor uses the endpoint’s `mediaType` rather than the default. ### Fixed Issues
IssueID

API Designer now properly renders markdown files in the documentation view.

W-10647692

The mocking service now properly renders examples and schemas in OAS 3.0 APIs when you use allOf or oneOf properties.

W-10888940

The error that the schema must not import, include, or redefine itself no longer occurs when you import RAML API specifications.

W-10685149

## 2.42.0 **April 30, 2022** ### What’s New ### API Governance Support - A new ruleset dependency type is introduced in this release to enable you to validate your API specifications against rulesets cataloged in Exchange. For more information, see the [API Governance documentation](https://docs.mulesoft.com/api-governance/). ### User Interface Improvements - The visual editor UI refresh rate has been improved. ### Improved Specification Validation in the Text Editor - API Designer now supports AML Modeling Framework (AMF) version 5.0.6. - When you declare a security scheme in a RAML library, use it in an API specification, and then convert the RAML specification to OAS, the OAS specification is now generated with valid security scheme information. - When you define both date and pattern formats for OAS types, API Designer shows a warning that the pattern property might be ignored if the date format already defines a standard pattern. ### Fixed Issues
IssueID

The property of data type datetime-only now shows properly as DateTime in the API specification documentation in API Designer and in Exchange.

W-10899011

### Known Limitations and Workarounds Due to an enhancement in the way absolute paths are parsed, if you apply a governance ruleset dependency to a project in API Designer, absolute file paths are no longer allowed in fragment dependencies for that project. If this enhancement impacts your project, you can either update and republish the fragments or switch back to the prior behavior and opt not to apply rulesets to that project. ## 2.41.0 **April 2, 2022** ### What’s New ### Improved Specification Validation in the Text Editor - Boolean schemas are now parsed for JSON schema draft-06. - Security scheme fragments with media type defined at the global level are now validated properly. ### Autocompletion Improvements - Code suggestions are now properly shown for OAS 3.0 specifications that use `externalDocs` regardless of the position of the cursor. - The hover text is now properly shown for OAS 3.0 specifications that use `externalDocs`. ### Fixed Issues
IssueID

The file import now properly validates file names regardless of how the files are imported.

SE-24042

## 2.40.0 **March 5, 2022** ### What’s New You can now select lifecycle states when publishing API specifications to Exchange. For more information, see [Publish an API Specification](https://docs.mulesoft.com/design-center/design-publish). ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 5.0.4. - AMF parser validations no longer show duplicate examples for error codes. ## 2.39.0 **February 5, 2022** ### Fixed Issues
IssueID

Tests of OAS v3 endpoints can now be executed.

SE-23274

When errors are found in included files, the editor now indicates errors in the root file as well as in the included files.

DESIGNER-7123

## 2.38.0 **January 8, 2022** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 5.0.2. - OAS 3.0 specification properties with nullable fields set to `true` are now correctly validated when sent in payloads. ### Fixed Issues
IssueID

The exclusiveMinimum and exclusiveMaximum properties are now numeric values in JSON schema versions draft-06 and draft-07.

SE-23167

In the visual editor, selecting an Array data type now shows two separate sections: Array Fields and Items.

The Items section displays fields corresponding to the selected Items type, for example: Object, Boolean, or DataType.

DESIGNER-2821

In the visual editor, a union data type is now correctly rendered after saving changes and then reloading a project.

DESIGNER-4705

### Autocompletion Improvements - In OAS 3.0 specifications, 'responses' node autocomplete suggestions no longer include the `New Response` option. - In RAML 1.0 specifications, autocomplete suggestions now correctly show for objects inside `array` types. - In RAML 1.0 specifications, autocomplete now correctly shows prefix suggestions. - In RAML 1.0 specifications, autocomplete no longer suggests duplicates for `resourceTypes` and `traits`. ## 2.37.0 **December 11, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 5.0.1. - AMF parser validations no longer incorrectly highlight the origin of the document. Validations now highlight the correct line of the validated shape or fragment. ### Fixed Issues
IssueID

External schemas referenced in an API specification no longer introduce unexpected <schema> tags in generated XML.

SE-22292

Selected resources and methods now correctly show in the Description field in the visual editor.

SE-22991

URI parameter data types imported from libraries no longer return validation errors.

SE-23076

When using Mozilla Firefox, the client_id and client_secret headers now correctly display in API Console.

SE-23195

## 2.36.0 **November 13, 2021** ### User Interface Improvements - When you initiate the import of a ZIP file but do not choose a file, the **Import** button is no longer enabled. - The tooltip for a deprecated dependency is now displayed correctly. ### Improved Specification Validation in the Text Editor API Designer now provides support for AML Modeling Framework (AMF) 5.0.0. ### Fixed Issues
IssueID

When a branch is changed externally and you click Discard and Use New Changes, the window no longer remains open with the Updating message.

DESIGNER-6835

API Designer now supports relative references from one XSD schema to another. If you create an API specification that contains an XSD schema that references another XSD schema, the import no longer fails with the warning Could not validate XSD schema: Resource /{anotherSchema}.xsd not found.

For example, you can now include an import line such as <xs:import namespace="http://www.wincor-nixdorf.com" schemaLocation="WNExtensions.xsd"/> in another XSD schema, such as POSLog.xsd.

SE-22684

## 2.35.0 **October 16, 2021** ### New Feature - You can now create, import, and edit AsyncAPI specifications in API Designer. See [Event-Driven API (AsyncAPI) Support Release Notes](https://docs.mulesoft.com/release-notes/platform/event-driven-api). ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.8. - Inheriting from array types no longer results in an `Incompatible types [array, array]` validation error. - Including a disjoint `UnionShape` within the `examples` node of a schema no longer results in an `expected type: X, found: Y` error. ### Fixed Issues
IssueID

The Publish to Exchange dialog now prevents publishing a project with an invalid root file name.

DESIGNER-6885

API Designer now enforces a 50MB limit when performing an Import from File.

DESIGNER-6900

AMF now correctly validates arrays of types in JSON schemas.

SE-22204

## 2.34.2 **September 30, 2021** ### Fixed Issues
IssueID

Publishing to Exchange while the root file resides in a folder no longer results in the following error:

Cannot publish with invalid root file name

SE-22876

## 2.34.1 **September 27, 2021** ### Fixed Issues
IssueID

API Designer no longer repeatedly displays the following when creating or switching branches:

This branch has changed externally

SE-22744

## 2.34.0 **September 18, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.7. - The `union` and `nil` types are now parsed with equivalence. - Validation no longer fails for required facets in properties containing the `nillable` shorthand type. For example, the following code no longer results in `Error: Property 'required' not supported in a RAML 1.0 string node`: #%RAML 1.0 title: APIMF-2975 types: Test: properties: name: required: false type: string? - AMF now saves properties declared in `required` but not present in `properties`. For example, the following code no longer results in an ignored `address` property: { "$schema": "http://json-schema.org/draft-04/schema#", "type" : "object", "properties": { "name": {"type": "string"}, "age": {"type": "integer"} }, "additionalProperties": false, "required": \[ "address" \] } ### Autocompletion Improvements - Inner document path suggestions no longer contain a trailing slash. ### Fixed Issues
IssueID

API Designer no longer incorrectly validates empty oneOf schemas that contain the required keyword.

SE-21827, SE-21981, SE-22242

Content is no longer deleted after changing a file extension (via the Rename option) within the text editor.

DESIGNER-6664

Importing files with names containing invalid characters (such as ,) is now correctly allowed.

DESIGNER-6667

## 2.33.0 **August 21, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.6. - RAML 1.0 definitions containing duplicate property names were incorrectly validated. For example, the following definition did not result in an error: #%RAML 1.0 title: test-example version: v1 types: failing: type: object properties: duplicate: string duplicate?: string example: duplicate: "hello error" An error is now displayed: ```none Error: Duplicated property names: duplicate ``` ### Autocompletion Improvements - Autocompletion in OAS specifications containing `parameters` tags now suggests "info" (instead of "in") for root nodes. - Autocompletion in OAS specifications is now correct for `version` tags when subsequent text exists. ### Fixed Issues - The time to open the **Publish to Exchange** dialog is improved for projects containing several files and dependencies. - The XML 'name' property was ignored in the example XML payload generated via API Console. - Opening a project occasionally resulted in a non-completing `Loading…​` message. The browser console displayed the following error: ```none Uncaught DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope' ``` - When publishing assets to Exchange takes more than 1 minute, the following message is now displayed: ```none Error publishing to Exchange: Request timed out due to project size. Asset may have been successfully published. Please verify in Exchange. ``` Previously, `unknown error` was returned. - Options were not rendered in API Console for schema properties containing the `oneOf` keyword. - RAML 1.0 inline unions in extensions now parse correctly. For example, given the following specification and extension: #%RAML 1.0 title: example API to be extended types: TestObject: type: object /test: get: responses: 200: body: application/json: type: TestObject #%RAML 1.0 Extension extends: /api.raml types: TestObject: properties: unionDate: datetime-only|nil example: unionDate: null /test: get: responses: 200: body: application/json: type: TestObject The `unionDate` property parsed as the first declared type (in this case a `datetime-only`). However, given the inverse union, only nil values were validated. This resulted in an error: ```none Error: 'unionDate' should be string 'unionDate' should match some schema in anyOf ``` - Adding an enum property to an extension resulted in duplicate values in API Console. - When trying to use the same library defined in an API specification more than once, the following error was returned: ```none Error: Libraries must be applied by using 'uses' ``` ## 2.32.0 **July 24, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.5. - OAS 2.0 security scheme definitions that do not contain `name` and `in` required fields now result in warnings: ```none Warning: Property 'in' is required in a OAS 2.0 apiKey node Warning: Property 'name' is required in a OAS 2.0 apiKey node ``` ### Autocompletion Improvements - Autocompletion now displays correct options for `example` nodes that include example fragment files. - Autocompletion now displays correct RAML method names for endpoint name nodes. ### Fixed Issues - Enum values declared in an array type were not displayed in the **Documentation** panel. - When publishing to Exchange, API projects with a large number of files intermittently resulted in the following HTTP 502 timeout error response: ```none Error publishing to Exchange: Unknown error ``` - In API Console, selecting a body content type of `application/xml` created an invalid payload. The following error was displayed: ```none 400 Bad Request ``` - It was not possible to scroll through large amounts of Exchange dependencies. - API Console displayed a validation error when entering fractional numbers as query parameters. ## 2.31.0 **June 26, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.4. - The RAML datetime-only validator now returns an error for years with over four digits. For example, previously `"effectiveDate": "22021-06-05T00:00:00"` would not return an error. It now returns a `400 Bad Request` error. ### Autocompletion Improvements Autocompletion now: - Does not suggest incorrect options within a type definition when defining facets. - Does not suggest in-use options. - Suggests only `description` for the description field of a parameter. - Provides suggestions if a colon is after your cursor. ### Fixed Issues - API Language Server (ALS) would not return an error payload for a Serialization request while a workspace was still initializing. ALS now returns an error payload if the Serialization request can’t be validated. - API server descriptions are now present in the **Documentation** pane with their servers. ## 2.30.0 **June 8, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.3-1. - Invalid discriminator mapping values now result in a warning. For example, the `invalid` value in the last line of the following snippet results in `Warning: Unresolved reference 'null'`. openapi: "3.0.0" info: version: 1.0.0 title: 1-api paths: {} components: schemas: Dog: type: string Cat: type: string Animal: oneOf: - $ref: '#/components/schemas/Dog' - $ref: '#/components/schemas/Cat' discriminator: propertyName: petType mapping: invalid: 'null' - In RAML 0.8, specifying a relative reference (for example, `!include common/400.example`) instead of the intended absolute reference (for example, `!include /common/400.example`) results in an error: ```none Error: Resource common/400.example not found ``` - The parser now resolves spaces in values with `!include` tags, such as the following: title: !include /title file.yaml ### Fixed Issues - Schemas with `schemaLocation` values containing `.xsd` files resulted in the following incorrect warnings: ```none Unreferenced file: This file is not referenced by the root file ``` - Incorrect strings replaced the response section title in the **Responses** section. The title text is now displayed as **Example** in all cases. - OAS specification 'description' and 'example' values did not display in the **Documentation** section. - Mocking service requests did not successfully complete due to certain missing JSON headers. - API Console did not display the correct property type for arrays declared with the `[]` qualifier (for example, `string[]`). - API Console did not display the correct information for schema definitions containing the `anyOf` keyword, such as in the following snippet: "companyType": { "anyOf": \[ { "type": "string", "maxLength": 10, "description": "The legal name of the given company.", "enum": \[ "EU" \] }, { "type": "string", "description": "Any future added type", "maxLength": 10 } \] } }, The **Documentation** section incorrectly displayed the following: ```none item.companyType Any ``` ## 2.29.0 **May 1, 2021** ### Improved Specification Validation in the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.2. - RAML nillable shorthand `string?` types were not recognized in `uriParameters`, `queryParameters`, or `headers` maps. The following error was displayed: ```none Cannot declare unresolved parameter ``` ### Fixed Issues - Previously published Exchange dependencies failed to load in API Designer when importing an API specification or fragment and creating branches containing `/` (for example, `features/mybranch`). - For some projects in the project list, the `Created By` field displayed UUIDs instead of names. - The mocking service returned an `Invalid Schema` error after correcting `ref` paths in an `.xsd` schema file. ## 2.28.0 **April 3, 2021** ### Improvements in the Validation of Specifications by the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) 4.7.1., which improves validation of object payloads inside enums. For example, the following RAML defines two types (`AnimalWithPaws` and `AnimalWithHoofs`), and a union of these two types called `Animal`: #%RAML 1.0 title: Some API types: AnimalWithPaws: properties: name: string pawsCount: number AnimalWithHoofs: properties: name: string hoofsCount: number Animal: type: AnimalWithPaws | AnimalWithHoofs enum: - name: Cat pawsCount: 4 - name: Horse hoofsCount: 4 The type `Animal` is now considered valid. ### Fixed Issues - By design, the visual editor will not add the URI parameter (for example, `bookId`) to the resource name (for example, `/book`). The following message now displays, advising you to add the parameter: Please add it to the resource name input as needed, e.g /book{bookId} - From the visual editor, the following error was returned after selecting the **Access token (browser flow)** grant type and attempting to authorize an OAuth access token: Cannot GET /node\_modules/@advanced-rest-client/oauth-authorization/oauth-popup.html - In the text editor, renaming an array type with the **Rename Symbol** action resulted in a non-array type name. For example, renaming `person[]` to `user` in the following RAML resulted in a new symbol named `user` instead of `user[]`. #%RAML 1.0 title: My API with Types "person" types: person: description: this is person's description properties: firstname: string manager: type: string Alertable: manager | person /person: get: responses: 200: body: application/json: type: person\[\] example: | \[{ "firstname": "person" }\] /person/{manager}: post: body: application/json: - In the text editor, autocomplete incorrectly suggested the `responses` tag after entering "r". The error occurred when typing under the `queryParameters:` node. ## 2.27.0 **March 6, 2021** ### New Features - The API Designer text editor now supports the following actions: - Find locations where a definition is referenced. - Select code ranges. - Navigate to a symbol. - Extract an element to a declaration. For more information, see [Helpful Features in the Text Editor](https://docs.mulesoft.com/design-center/design-helpful-features-text-editor). - The AML Modeling Framework (AMF) parser is now version 4.7.0. ### Fixed Issues - OAS 3.0 code generated when switching from the visual editor to the text editor was invalid and could not be published to Exchange. For example, under **API Summary** in the visual editor, specifying `application/json` and switching to the text editor resulted in the following invalid code: "produces": \[ "application/json" \], The following error was reported: Error: Property 'produces' not supported in a OAS 3.0 webApi node - Publishing an asset to Exchange and then deleting the project resulted in the option to edit the specification from Exchange. Selecting **Edit spec** resulted in the following error: Project not found The **Edit spec** option no longer displays in **READ ONLY VIEW** if the project was previously deleted in Design Center. - Previously you could create a file with the reserved name, `exchange.json`. - Importing a ZIP file with a file named `exchange.json` located in a folder other than the reserved `exchange_modules` folder resulted in two added files named `exchange.json`. Now, the duplicate file is ignored and not imported. ### Known Issues - The **Documentation** panel displays an incorrect `type: number` value if the value is 16 digits or larger. For example, the following snippet contains a `type: number` value that is 16 digits: 16digits: type: number maximum: 9999999999999999 Design Center incorrectly displays `Max value: 10000000000000000`. The current type system does not support the required precision. ## 2.26.0 **February 6, 2021** ### Fixed Issues - OAS 3.0 specifications with `nullable` fields generated unexpected `anyOf` keys when converted to RAML 1.0 specifications. - When using the **Import from File** option, importing a Mac-compressed ZIP file incorrectly added a reserved folder `__MACOSX` to the project. - When using the **Import from File** option with a ZIP file containing a single folder at root level (with the API specification content inside), the root level folder was not removed and was incorrectly imported into the created project. Now the root level folder is removed and its content is imported into the root folder of the new project. - When sorting projects by **Name**, **Project Type** or **Last Update**, the projects disappeared from the view. - After publishing a project via **Publish to Exchange**, the code suggestions were not displayed in the text editor. ## 2.25.0 **January 7, 2021** ### Improvements in the Validation of Specifications by the Text Editor - API Designer now provides support for AML Modeling Framework (AMF) version 4.5.1. Version 4.5.1 enables JSON parsing recovery, which better validates JSON files with syntax errors. These errors are now more isolated, and more JSON content is now validated. For example, the following demonstrates JSON with syntax errors: { "name": "john", "surname": "doe "age": "33" } Prior to AMF version 4.5.1, the following was displayed: Error: Syntax error : Expecting ',' but 'age'" found Error: Syntax error : Expecting '"' but 'age'" found In AMF version 4.5.1, additional information is now displayed: Error: Syntax error : Expecting ',' but ' ' found Error: Syntax error in the following text: 'doe' Error: Syntax error : Unexpected '"' but ' ' found Error: Syntax error : Missing ',' ### Fixed Issues - Errors were not being reported when publishing malformed OAS assets to Anypoint Exchange. - Moving files into renamed directories caused the following error: is not a valid directory - The **Documentation** panel’s **Operation ID** URL did not match the selected server after loading an OAS 3.0 specification. - Specifications that did not define `baseUri` resulted in no endpoint URL documentation. ## 2.24.0 **December 12, 2020** ### Improvements in the Validation of Specifications by the Text Editor - Support for boolean facet properties using JSON Specification Draft 4 or later. This release of API Designer provides support for AML Modeling Framework (AMF) version 4.5.0. In this version of AMF the severity of validation for required boolean facet properties was downgraded from violation to warning. Although it throws a warning, in any JSON Schema specification draft this field is still parsed and set correctly in the model. The following example shows an incorrect usage: { "$schema": "http://json-schema.org/draft-07/schema#", "additionalProperties": false, "properties": { "property1": { "type": "string", "required": true } } } This example returns the error: `Required property boolean value is only supported in JSON Schema draft-3.` MuleSoft recommends not using this approach. ### Fixed Issues - Fixed an issue where nested resources where incorrectly displayed under the parent resource. - Fixed an issue with periods in the name of a forked branch. - Added warning message when loading a RAML specification containing OAS security schema types. - Fixed an issue where clicking the **Edit spec** button in Exchange caused an error. - Fixed a minor display issue. ### Known Issues - When selecting a server to use for the mocking service, the URL displayed does not match the selection. - In some cases the endpoint URL may not display in the API specification’s documentation panel. ## 2.23.0 **November 14, 2020** ### New Features - Added new dialogs for creating an API specifications and fragments. You can more easily create new API specifications and fragments from an existing file or project. Supported file types are JSON, RAML and YAML. You can also use an existing project saved as a ZIP file. This feature also enables you to create a new Mule application from a JAR file. - For assets published to Anypoint Exchange, you can view the source code directly from Exchange by selecting **View code in API Designer**. By default the project opens in API Designer in read-only mode. If you have edit permissions and the project exists in Exchange, API Designer give you the option to edit the project. - Added hover tooltips that provides additional information about the nodes in an API specification or fragment. ### Fixed Issues - Fixed an issue where data fragment was not shown in API Designer when imported into a library fragment. - Fixed an error in the AMF parser where maximum call stack was exceeded. - Fixed an issue where 404 errors were returns if a branch name contained a slash. - Fixed a YAML error when using the @type in a JSON example. - Fixed an issue where duplicating fragments resulted in a 400 error. - Fixed an issue where API Designer did not complete loading when opening a branch with no files in its root. - Fixed an issue where the branches dialog was not visible when no preview existed for the current selected file. - Fixed an issue where changing the extension of a file required a user interface refresh. - Fixed an issue in the visual editor where values in query parameters could not be set. - In the visual editor, fixed an issue with query parameters after creating an enum type. ## 2.22.0 **October 29, 2020** ### Improvements in the Validation of Specifications by the Text Editor - RAML Unions Fixed issue where incorrect validations were occuring under specific conditions using unions. For example, the following API is now valid: #%RAML 1.0 title: Secrets Provider version: v1 baseUri: https://test.com/provider/ types: EncryptedResponse: type: object properties: encryptedKey: type: string sharedSecretUsernamePassword: type: object properties: username: type: string sharedSecretSymmetricKey: type: object properties: key: type: string SharedSecret: sharedSecretUsernamePassword | sharedSecretSymmetricKey /path: get: responses: 200: body: application/json: type: SharedSecret | EncryptedResponse examples: encrypted: | { "encryptedKey": "encryptedKey", "cipherText": "cipherText" } - RAML Version Base URI Parameter Added validation for missing version definitions for the baseUri. For example, the following API is now valid: #%RAML 1.0 title: Brown Google Admin Directory API baseUri: https://localhost/services/cis/brown-google-admin-directory-api/v{version} ### Fixed Issues - Fixed an issue where JSON schemas in RAML specifications were not displayed properly in the Design Center API Console. - Arrays defined in a RAML specification in Design Center were being treated as objects within Studio. - Importing resources failed if they contained invalid file names. API Designer now checks the validity of resources in a ZIP file and alters the filenames if necessary. - Fixed a bug where a file inside a folder did not suggest the correct module when using an !include tag. ## 2.21.0 **September 19, 2020** ### New Features - You can have multiple files open simultaneously in API Designer’s text editor. Each file can be open in its own tab. For details, see [Edit in Multiple Tabs in the Text Editor](https://docs.mulesoft.com/design-center/design-edit-multiple-tabs). - Using only one action, you can rename declarable objects everywhere they are used in a project that is open in the text editor. For details, see [Helpful Features in the Text Editor](https://docs.mulesoft.com/design-center/design-helpful-features-text-editor). ### Fixed Issues - When multiple media types were declared in a response body, the documentation pane sometimes did not list them all. - When multiple responses were declared for an API specification written in OAS 2.0, the documentation pane sometimes did not display all of the example responses. - The properties `accessTokenUri` and `authorizationTokenUri` in `settings` nodes were not validated in OAuth 2.0 security schemes. - The properties `requestTokenUri`, `authorizationTokenUri`, and `tokenCredentialsUri` in `settings` nodes were not validated in OAuth 1.0 security schemes. - Examples defined for `queryString` nodes were not appearing in the documentation pane. - The text editor incorrectly allowed the YAML multi-document tag `---`. Now, the editor flags this tag as a syntax error. Here is an example of this tag used in an API specification, and that the text editor flags as a syntax error: #%RAML 1.0 title: api --- /test: - The text editor did not correctly validate the use of security schemes that were defined in RAML SecurityScheme fragments. For example, in this API specification, the scope used is `USER`: #%RAML 1.0 title: API securitySchemes: oauth\_2\_0: !include securitySchemes/oauth\_2\_0.raml /users: get: securedBy: \[ oauth\_2\_0: { scopes: \[ USER \] } \] However, in this SecurityScheme fragment, the scheme is defined with the scope `ADMIN`: #%RAML 1.0 SecurityScheme description: | This API supports OAuth 2.0 for authenticating all API requests. type: OAuth 2.0 settings: accessTokenUri: https:/host/path/oauth2/access\_token authorizationGrants: \[ client\_credentials \] scopes: \[ ADMIN \] In previous releases, the text editor would have allowed the use of the `USER` scope in the API specification. ## 2.20.1 **September 1, 2020** This release fixes this issue: The text editor prevented users from typing in invalid characters when naming a new branch. However, in previous releases it was possible for users to paste names that contained invalid characters into the **Create branch** field and create branches with those names. Now, the text editor automatically removes invalid characters that are pasted into the **Create branch** field. ## 2.20.0 **August 22, 2020** This release includes a new feature and an enhancement. It also fixes one issue and includes improvements to how API specifications are validated by the text editor. ### New Feature - You can highlight the names of declarable objects where they are used in a file. To see all of the locations in a file where an object is used, click the cursor in the name of the object where that object is declared. For example, the type `person` is declared on line 5 at the first callout in the following example API specification. That type is subsequently used on line 16 at the second callout. If you click `person` on line 5, the text editor highlights `person` on line 16. #%RAML 1.0 title: Test Highlighting types: person: **(1)** type: object properties: name: string /test: get: responses: 200: body: application/json: type: person **(2)** This highlighting works for all declarable objects, such as types, security schemes, resource types, and traits. Highlighting appears only where the object is used, not every location where its name appears. For example, in the following example API specification, `person` is declared as a type on line 5 at callout 1, mentioned on line 14 at callout 2, and used on line 17 at callout 3. When you click in `person` at callout 1, `person` is highlighted only at callout 3. #%RAML 1.0 title: Test Highlighting types: person: **(1)** type: object properties: name: string /test: get: responses: 200: description: person **(2)** body: application/json: type: person **(3)** ### Enhancement The button highlighted by default in the **Replace File?** dialog is now **Keep Both** rather than **Replace**. ### Fixed Issue When validation of any XML instance against any type declaration cannot be performed, the following warning message is now displayed: Warning: Could not validate XML. ### Improvements in the Validation of Specifications by the Text Editor Two improvements were made in the validation of API specifications written in OAS. One improvement was made in the validation of API specifications written in RAML 1.0. #### OAS - Cyclic references between files are now supported for API specifications that are written in OAS. For example, the following API specification is now considered valid: swagger: '2.0' info: title: pet api version: 1.0 definitions: pet: type: object properties: animalRef: $ref: 'ref.yaml#/definitions/animal' paths: {} definitions: animal: type: object properties: petRef: $ref: 'api.yaml#/definitions/pet' - Unresolved Reference error messages no longer appear for valid specifications. For example, in releases prior to version 2.20.0, the text editor returned the error message ``Unresolved reference `TestSchema`` for an API specification like the following: swagger: "2.0" info: title: 'test' version: "1.2" paths: /pets: get: produces: - application/json responses: '403': $ref: 'ref.yaml#/responses/response1' definitions: TestSchema: type: string responses: response1: description: 'test' schema: $ref: '#/definitions/TestSchema' #### RAML 1.0 Error messages no longer appear for valid examples inside of overlays. For example, the following API specification is now considered valid: #%RAML 1.0 title: Test types: TestEntity: type: object properties: id: string #%RAML 1.0 Overlay title: Overlay extends: ./api.raml types: TestEntity: example: | { "id": "t123" } ## 2.19.0 **July 25, 2020** ### New Feature You can duplicate projects in API Designer. You might want to duplicate a project if you need to make extensive changes to the project without losing the original on which the duplicate project is based. For more information, see [Duplicate a Project](https://docs.mulesoft.com/design-center/design-duplicate-project). ### Enhancements - When you move a file into a folder that already contains a file that has the same name and extension, a new confirmation dialog asks whether you would like to cancel the move, keep both files, or replace the file that is already in the folder. - The text editor no longer validates projects that are in read-only mode. In previous releases, the text editor reported dependencies as missing when projects entered read-only mode. ### Fixed Issues - In the text editor, the order of the data types presented in the documentation pane could differ from their order in a currently open API specification written in RAML. - In some cases, a header could be duplicated on the **Try It** page and, when an API specification was published to Anypoint Exchange, endpoints might display headers that were not defined for those endpoints. - A recursive shape was created from the merge of an endpoint and a resource type when both referenced the same type but in different ways: one referencing it from a library, the other referencing it through a type declaration. - The text editor reported an error if, in the `settings` attribute used by OAuth2, the `scopes` property was not set. - The text editor could fail to make suggestions if the root file of a project was being edited. - If the root file was selected in the text editor, it was possible for the documentation for referenced types not to appear in the documentation pane, although the type definitions in the referenced files did contain documentation. - If any parameter was defined as an enum and the default value was not the first value in the array, the mocking service replaced the first value with the default value. - In the text editor, the Import feature accepted files for which the names included back slashes. Such files were imported, but they could not be accessed in the text editor. ### Improvements in the Validation of Specifications by the Text Editor #### OAS 3.0 Invalid recursive references are not detected. For example, the following OAS 3.0 API specification is now invalid: { "openapi": "3.0.0", "info": { "version": "0.0.1", "title": "test" }, "paths": { "/path": { "post": { "responses": { "400": { "description": "desc", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/mytype" } } } } } } } }, "components": { "schemas": { "mytype": { "$ref": "#/components/schemas/mytype" } } } } #### RAML 1.0 If you do not define scopes in an OAuth 2.0 security schema, you can use any scope in the implementation of your API. For example, the following specification is now valid: #%RAML 1.0 title: GitHub API securitySchemes: oauth\_2\_0: description: This API supports OAuth 2.0 for authenticating all API requests. type: OAuth 2.0 settings: accessTokenUri: https://someurl/oauth2/access\_token authorizationGrants: \[ client\_credentials \] /users: get: securedBy: \[ oauth\_2\_0: { scopes: \[ USER \] } \] ## 2.18.0 **June 27, 2020** This release includes new features and fixes issues. ### New Features - Limited support for OAS 3.0 For details, see [OpenAPI Specification 3.0 Support](https://docs.mulesoft.com/release-notes/platform/oas3). - Changes to the documentation panel in API Designer: The right panel in the text editor of API Designer, which displays the documentation that is written into API specifications and enables you to make requests to the mocking service, includes these changes: - Support for features that are specific to OAS 3.0 For details, see [Differences for OAS 3.0 in Rendered Documentation](https://docs.mulesoft.com/design-center/design-documentation). - Support for OAS flows for OAuth 2.0 For information about OAS flows, see the page "OAuth 2.0" on swagger.io at [https://swagger.io/docs/specification/v3\_0/authentication/oauth2/](https://swagger.io/docs/specification/v3_0/authentication/oauth2/). - Support for applying multiple security definitions simultaneously in requests made to the mocking service - Support for disabling automatic encoding of URI parameters in requests to the mocking service Use the new `no-auto-encoding` annotation, as in this example: paramName: (no-auto-encoding): type: string - New "go to" actions in the text editor In RAML API specifications, you can: - Right-click the name of a type and select **Go to Definition** in the pop-up menu to navigate to the declaration of the type. - Right-click the name of a resource type or trait and then select one of these options in the pop-up menu: - Select **Go to Definition** to navigate to the declaration for the resource type or trait. - Select **Go to Type Definition** to navigate to the definition of the resource type or trait. - Right-click a `resourceTypes` or `traits` node and select **Go to Implementations** to see where the resource types or traits that are defined in the node are implemented. - Right-click the declaration of a Type and Annotation Type that uses a library, and then select one of these options from the pop-up menu: - Select **Go to Definition** to navigate to the corresponding definition. - Select **Go to Type Definition** to navigate to the corresponding type definition. In OAS API specifications, you can: - Right-click an example of a reference object and select **Go to Definition** in the pop-up menu to navigate to the definition of that object. - Right-click a reference to a schema file (for example, `schema.yaml` in `$ref:"schema.yaml"`) and select **Go to Definition** to navigate to the file. - Right-click the name of an embedded schema in a reference to a schema file (for example, `Contact` in `$ref:"schema.yaml#/definitions/Contact"`) and select **Go to Definition** to navigate to that portion of the schema. ### Fixed Issues - The text editor could not open an API specification that was written in RAML. The error message was `Missing header x-user-id`. - Enum values in a RAML API specification that was published to Anypoint Exchange from the text editor did not appear in the documentation of the specification in Anypoint Exchange. - The text editor did not detect duplicate keys if one of the two keys was surrounded by quotation marks. - In the documentation pane of the text editor, the table view of the Response body did not correctly translate the source view. - The text editor displayed the error message `Internal error during validation` for an API specification that was written in RAML. - In the text editor, when objects that contain arrays or collections were shown in XML in the documentation pane, the names of child elements were generated incorrectly. - For API specifications written in OAS 2.0, the **Response** section in the documentation pane showed the same response example for all response codes. - Examples defined at the property level of types were not included in examples at the resource level in the documentation pane of the text editor if a RAML API specification defined more than one endpoint. - The warning message `Unable to load schema from 'http://schema.hropenstandards.org/4_0/common/json/meta/hros.json'. No schema request service available.` appeared erroneously in the text editor for a particular JSON schema. ### Improvement in the Validation of API Specifications - Fixed the "Unresolved reference" error for references to `.yaml` files in OAS API specifications. For example, the following API is now valid: swagger: '2.0' info: title: Sample API version: '' paths: /resource: get: responses: '200': description: '' schema: $ref: 'f/complexType.yaml' /resource2: get: responses: '200': description: '' schema: $ref: 'f/baseType.yaml' type: object properties: ref: $ref: baseType.yaml type: object properties: name: type: string ## 2.17.2 **June 2, 2020** This release fixes these issues: - Suggestions and errors were not displayed for an API specification written in RAML 1.0 and that should have generated the error message "Error recursive shape". - The text editor allowed an API specification written in RAML 1.0 to be published to Anypoint Exchange, even though the specification contained an error. - The search field in the text editor lost focus whenever a character was typed in it. - At times, the **Documentation** panel did not display any content. - At times, clicking a link to an unreferenced file from within the **Project Errors** view caused the browser window to become blank. ## 2.17.0 **May 30, 2020** This release includes new features and fixes several issues. ### New Feature - The text editor now displays error messages and warnings in a new view that you can open by clicking a tab in the editor’s bottom-right corner. You can view the errors and warnings for all files in a project, or the errors and warnings for the file that is currently displayed in the editor. This new view also lists all unreferenced files in the current project. When you first open the text editor in this release, a dialog appears that describes the features of the new view and displays screenshots. - The new status bar at the bottom of the text editor shows the name of the currently open file, the position of the cursor in the file, whether the file is the root file of the project, the language (RAML or OAS) that the current file is written in, and the type of project that you are working in. ### Fixed Issues - API Designer did not publish a project to Exchange if the project contained a filename that included a space. - Attempting to update an Exchange dependency sometimes resulted in the error message `502 Bad Gateway`. - Neither the **Documentation** pane nor the **Try It** panel were generating the correct XML example for element names that contained periods, such as `[abc.xyz]`. - For API specifications written in OAS 2.0, the **Documentation** panel could display **API Key** twice in the **Authorization method** field if two security definitions were both defined as the `apiKey` type. - When the client ID or secret for a RAML API specification that included `authorizationGrants: [client_credentials]` was not visible in the **Documentation** pane, the **Client ID** or **Secret** field was also not visible. - The text editor sometimes failed to render methods and endpoints in imported OAS 2.0 API specifications. ### Improvement in the Validation of API Specifications The text editor now validates recursive shapes correctly. For example, the following OAS 2.0 API specification is considered valid: { "swagger": "2.0", "info": { "title": "test", "version": "1.1" }, "definitions": { "Causes": { "$ref": "#/definitions/Test" }, "Test": { "properties": { "subsenses": { "items": { "$ref": "#/definitions/Test" }, "minItems": 1, "type": "array" } }, "type": "object" } }, "paths": {} } However, the following RAML 1.0 API specification is considered invalid: #%RAML 1.0 title: Recursive types: Recursive: type: object properties: myP: type: Recursive /recursiveType: post: responses: 201: body: application/json: type: Recursive ### Known Issue The URL for the mocking service might remain visible even after the mocking service is switched off. To hide the URL, switch to another page in the **Documentation** pane. ## 2.16.0 **May 2, 2020** This release includes three enhancements and four fixes. It also includes an improvement in how the text editor validates API specifications that are written in OAS 2.0. ### Enhancements - Beginning with Anypoint Studio 7.5.0, users can edit API-Designer projects directly in Studio. If you are working in a project in the text editor in API Designer at the same time that someone using Anypoint Studio 7.5.0 or later is working in the same project, there could be save conflicts. As you work in the text editor in API Designer, the editor saves your project frequently if you have made changes since the last automatic save. However, if a user in Studio is working in the same project and saves changes before the next automatic save in the text editor in API Designer, the editor displays this message: This branch has changed externally A new commit has been made to this branch since your last save. We will use the changes from your repository and discard your latest updates. The message shows a **Discard and Use New Changes** button. You must click the button to accept the changes. Because the text editor automatically saves often, you will usually lose only a few changes. - The **Exchange Dependencies** pane lists RAML API fragments that have been added as dependencies in a project directly from Anypoint Exchange. Now, when a new version of a fragment listed in the **Exchange Dependencies** pane is published on Exchange, an icon appears next to the name of the dependency to notify you that the version you are using is deprecated. As in previous releases, follow these steps to use the new version in your project: 1. Click the name of the dependency. 2. Select **Change version**. 3. Select the current version in the **Change version** dialog. - If an error occurs when you publish a project to Anypoint Exchange, the error message now appears in the publish dialog. - In the `exchange_modules` folder in projects in the text editor, there are two changes: - An icon of a lock now appears next to the `exchange.json` file to indicate that this file is read-only. - The names of all of the files in this folder are now in gray to indicate that they should not be edited. ### Fixed Issues - In some cases, the text editor reported that RAML trait fragments in an API-specification project included unresolved file references, even when the file references were correct. - The text editor displayed the error message "Error recursive shape" when a RAML API specification referenced an Exchange Library type. - The use of `$ref` caused the text editor to display error messages about unresolved file references when referenced files were in project subfolders and when they were in the top level folder. - In the visual editor, if a search in the filter field found results in the **DATATYPES** section, the **RESOURCE** section, or both, those sections were not automatically expanded if they were closed. ### Improvement in the Validation of Specifications by the Text Editor In API specifications written in OAS 2.0, references to YAML files are now supported. For example, the following API specification is now considered valid: `root.yaml` swagger: "2.0" info: version: 1.0.0 title: Swagger Petstore paths: /pets: get: responses: "200": description: unexpected error schema: $ref: 'ref.yaml' `ref.yaml` type: object required: - code - message properties: code: type: integer format: int32 message: type: string ## 2.15.0 **April 4, 2020** This release includes several new features, two enhancements, several fixes, and several improvements to how the text editor validates specifications. ### New Features - The new **Filter** field in the **Files** pane of the text editor can help you locate files in your project faster. The equivalent field on the left side of the visual editor can help you locate security schemes, resources, and data types faster. - You can now import API specifications from Anypoint Exchange into the visual editor. An imported specification completely replaces the specification that is currently open in the visual editor. You can import a specification only if it does not contain any fragments. - In the visual editor, you can proxy a request to a REST service by deselecting the shield in the top-right corner: - If the shield is selected, the request won’t be proxied. For example, request URLs that the mocking service provides look like this: `https://anypoint.mulesoft.com/mocking/api/v1/links//` ![Selected](/mulesoft/current/en-us/release-notes/_images/design-center/apid-firewall-checkbox-visual-editor.png) Figure 1. The shield is selected. - If the shield is not selected, the request will be proxied. For example, request URLs that the mocking service provides look like this: `https://anypoint.mulesoft.com/apiconsoleproxy/api/v1/proxy/https:///mocking/api/v1/links//` ![Not selected](/mulesoft/current/en-us/release-notes/_images/design-center/apid-firewall-checkbox-visual-editor-off.png) Figure 2. The shield is not selected. ### Enhancements - When you are working in the text editor on files written in RAML, you can now hold the command key and click on the file name in an `!include` tag to open that file. - When a line of text in a file in the text editor is underlined red, indicating that there are one or more errors in the line you can click in the line to see the error message or messages. ### Fixed Issues - In the visual editor, changing a data type’s minimum and maximum lengths could result in these lengths being changed for other data types, too. - If you view the asset page for an API specification in Anypoint Exchange, you can click **View Code** to open the specification in read-only mode in the text editor of API Designer. The issue was that, if you tried to view different files in an API specification after entering read-only mode this way, the text editor displayed the error message "The requested resource could not be found." - API Designer did not flag as invalid cases in which a property was defined as a numeric or object type, but then overridden with type "any", which is less restrictive. - The text editor displayed the error message `Should NOT be longer than _n_ characters at …​` because it incorrectly invalidated inheritance in examples. - Some properties defined in API specifications written in RAML appeared in the **Types** section in the left pane of the asset page in Anypoint Exchange. - Endpoints were sometimes not grouped and listed correctly in the **Documentation** pane. - Microsoft Internet Explorer 11 closed unexpectedly when opening API Designer projects. ### Improvements in the Validation of Specifications by the Text Editor One improvement was made for the validation of specifications written in RAML. Three were made for the validation of specifications written in OAS 2.0. #### RAML Declarations of status codes as optional are now flagged as invalid. For example, the definition of the response `201` in the following specification causes the text editor to display the error message `Status code for a response must be a value between 100 and 599 at (x, y)`: #%RAML 1.0 title: test types: x-ratelimit-limit: type: number description: The rate limit ceiling for this endpoint. traits: rateLimited: responses: 201?: headers: x-ratelimit-limit: x-ratelimit-limit /test: get: is: \[rateLimited\] responses: 200: #### OAS 2.0 - Duplicate `body` parameters are now parsed as invalid. For example, the following specification causes the text editor to display the error message `Cannot declare more than one 'body' parameter for a request or a resource at (x, y)`. { "swagger": "2.0", "info": { "title": "Test", "version": "1.0.0" }, "paths": { "/": { "parameters": \[ { "name": "body parameter 1", "in": "body", "schema": {} }, { "name": "body parameter 2", "in": "body", "schema": {} } \], "get": { "responses": { "200": { "description": "ok" } } } } } } - The value of a security requirement object now must be an array. For example, the text editor flags this specification as invalid because the value of `Bearer` is set to a string: { "swagger" : "2.0", "info" : { "title" : "Registry", "version" : "1" }, "paths" : { }, "security" : \[ { "Bearer" : "" } \], "securityDefinitions" : { "Bearer" : { "in" : "header", "name" : "Authorization", "type" : "apiKey" } } } To correct the problem, set the value to an array: { "swagger" : "2.0", "info" : { "title" : "Registry", "version" : "2" }, "paths" : { }, "security" : \[ { "Bearer" : \[\] } \], "securityDefinitions" : { "Bearer" : { "in" : "header", "name" : "Authorization", "type" : "apiKey" } } } - The `name` facet is now required. For example, the following specification causes the text editor to display the message `Name is mandatory in License object at (x, y)`: { "swagger": "2.0", "info": { "title": "Testing API", "version": "1.0.0", "license": {} }, "paths": {} } ## 2.14.2 **March 11, 2020** This release includes the following two fixes: \* The visual editor displayed the **Publish with unreferenced files?** confirmation dialog during the publish process. This dialog is relevant only for projects created in the text editor. \* The text editor displayed the error message `Not found` when a file for which the name contained invalid characters was selected. ## 2.14.1 **March 7, 2020** This release includes one enhancement, seven fixes, and four improvements to how API specifications are validated. ### Enhancement - By default, files in a project that are not directly or indirectly referenced by the project’s root file are not published to Anypoint Exchange along with the rest of the project. However, you can select an option to override this default and to include unreferenced files in a published project. ![The dialog with the option](/mulesoft/current/en-us/release-notes/_images/design-center/apid-unreferenced-files.png) Figure 3. This is the dialog that provides the option to override the default or to cancel publication so that you can remove unreferenced files. ### Fixed Issues - The text editor no longer suggests the `usage` facet for any types of RAML fragment other than ResourceType, Trait, Library, Overlay, and Extension. - In the text editor, files were allowed to be renamed to include characters that broke the process for publishing to Anypoint Exchange. - In the text editor, API specifications written in OAS 2.0 generated errors if their first line was composed of three dashes or if a line of three dashes followed directives. Example of the first case \--- swagger: "2.0" info: description: This API is written in OAS 2.0. version: "1.0" title: api-in-oas Example of the second case %YAML 2.0 %TAG !/directive/ --- swagger: "2.0" info: description: This API is written in OAS 2.0. version: "1.0" title: configuration-exp-api-consul - In certain cases, starting a project from an existing example generated an error. - It was possible to create an OAS 2.0 (JSON) project named "exchange", which led to a malformed initial file because of the conflict with the metadata file "exchange.json". Now, if you try to name such a project "exchange", the name given to the project is "1-exchange". - In the **Asset name** field of the dialog for publishing projects to Anypoint Exchange, spaces were replaced by dashes. - The navigation icon in the **Documentation** pane appeared for all types of RAML fragment, rather than only for Library, Overlay, and Extension fragments. The firewall icon also appeared for all types of RAML fragment, rather than only for Overlay and Extension fragments. ### Improvements in the Validation of Specifications by the Text Editor ### Improved Validation of the required Field in JSON Schemas If you are using JSON Schema 4 or later (the text editor uses version 4 if you do not specify a version), the `required` field takes an array as its value. In previous versions of JSON Schema, this facet took a boolean value. In previous releases of API Designer, the text editor did not display an error message if you were using JSON Schema 4 or later and you used a boolean value for the `required` field. Now, the text editor displays this error message: `'required' field has to be an array at (,)` For example, the text editor no longer considers valid the use of the `required` field in this specification: #%RAML 0.8 title: amf-validations /jobs: displayName: Jobs post: description: Create a Job body: application/json: schema: | { "$schema": "http://json-schema.org/draft-04/schema", "properties": { "input": { "type": "string" } }, "required": "true", "type": "object" } ### Validation of the type Field in Parameters in OAS 2.0 API Specifications In previous releases, the text editor did not display an error message when the list of parameters for an endpoint in an OAS 2.0 API specification lacked a `type` field. Now, the text editor displays this message: `Cannot find valid schema for parameter at (,)` For example, the text editor no longer considers valid the lack of the `type` field in this specification: { "swagger": "2.0", "info": { "title": "amf-validations", "version": "v1" }, "host": "api.github.com", "schemes": \[ "https" \], "paths": { "/users": { "get": { "description": "Get a list of users", "parameters": \[ { "name": "page", "description": "Specify the page that you want to retrieve", "required": true, "in": "query" } \] } } } } ### Validation of the Definitions of Properties in JSON Schemas In previous releases, the definitions of properties in JSON schemas were not validated. For example, the text editor no longer considers valid the definition of the property in this specification, which contains an array instead of an object: #%RAML 0.8 title: amf-validations /media: displayName: Most Popular Media get: description: Get a list of what media is most popular at the moment. responses: 200: body: application/json: schema: | { "$schema": "http://json-schema.org/draft-03/schema", "type": "object", "properties": \[ { "date": "date" }, { "amount": "integer" } \] } ### Validation of JSON Schemas That Do Not Define Types In previous releases, if an example of a property for which no type was defined used any type other than `object`, the text editor incorrectly displayed this error message: should be object at (,) For example, the text editor would display the error message for this specification because the definition of the property `from` does not include a definition of the property’s type. The example, however, shows that the type is `string`: #%RAML 1.0 title: amf-validations types: Client: type: | { "$schema": "http://json-schema.org/draft-03/schema", "type": "object", "properties": { "from": { "required": true } } } example: { "from": "test" } ## 2.13.3 **February 13, 2020** This release fixes two issues. - Clicking the **Upgrade** button in the notice about upgrading the mocking service resulted in the error message `Connection lost`. - The browser window in which the text editor in API Designer was being used would sometimes go blank. ## 2.13.0 **February 6, 2020** ### New Features - A new filter dialog enables you to filter the list of projects in Design Center, in addition to filtering the list of projects in the existing search box at the top of the list. ![The filter dialog](/mulesoft/current/en-us/release-notes/_images/design-center/apid-dc-filter.png) Figure 4. You can filter on project type and range of time during which projects were last updated. You can also view only those projects that you created.
1The button for opening the filter dialog.
2The filter for specifying or selecting the type of project to list.
3The filter for selecting the range of time during which projects that you want to list were last updated.
4The checkbox for selecting only the projects that you created.
- You can now sort the list of projects in Design Center by clicking the column headings. - Options for importing files into a project and downloading a project are now in a new menu that you open by clicking an button on which a gear appears. Two new project-level options also appear on that menu: **Rename** and **Delete**. ![The new project menu](/mulesoft/current/en-us/release-notes/_images/design-center/apid-project-menu.png) Figure 5. The button for opening this menu is in the top-right corner of API Designer, next to the **Publish** button.
1The menu includes two sections. This section includes the options for importing files and downloading the project.
2This section includes the options for renaming the project and deleting it.
3This is the button that you click to open the menu.
- Import files from your computer or from Exchange into folders that are listed in the **Files** pane of the text editor. Click the three dots to the right of the name of a folder and select either **Import** or **Import from Exchange**. ### Enhancements - The dialog for publishing API specifications has been simplified. ![A comparison of the previous publish dialog with the new one.](/mulesoft/current/en-us/release-notes/_images/design-center/apid-publish-dialogs.png) Figure 6. The new dialog for publishing API specifications is more simple and more helpful.
1The name of the API specification appears as the title of the dialog.
2There are now only two fields that require values.
3An option to add the API specification to API Manager is included in the More options section.
4Help for deciding on an asset version number appears within the dialog.
5Links to additional help are provided.

To learn more about publishing an API specification, see Publish an API Specification.

- The dialog for publishing API fragments has also been simplified. ![A comparison of the previous publish dialog with the new one.](/mulesoft/current/en-us/release-notes/_images/design-center/apid-publish-dialogs-api-fragments.png) Figure 7. The new dialog for publishing API fragments is also more simple and more helpful.
1The name of the API specification appears as the title of the dialog.
2There is now only one field that requires a value.
3Help for deciding on an asset version number appears within the dialog.
4A link to additional help is provided.

To learn more about publishing an API specification, see Create and Publish an API Fragment.

- Within the text editor, you can now set the root file for an API-specification project and for an API-fragment project. In the previous release, you set the root file in the **Main file** field of the publishing dialog. ![The controls related to root files](/mulesoft/current/en-us/release-notes/_images/design-center/apid-set-root-file.png) Figure 8. The controls that are related to root files are in the **Files** pane. This image shows the controls in an API-specification project.
1The menu opened by clicking the three dots to the right of a specification includes the option Set as root file.
2An indicator shows which specification is currently set as the root file.
3Click the question mark in the menu to learn more about root files. The question mark opens this topic in the online documentation: Root Files in Projects in the Text Editor in API Designer.
### Fixed Issues - The **Import from Exchange** dialog is not opened when the option **Import from Exchange** is selected in an empty API-fragment project. - Fixed a problem that caused the parser to return `Unresolved reference` error messages in a particular situation. - When a user accessed an API specification that had dependencies that were published in a business group other than the one that the user belonged to, those dependencies were deleted from the specification. Now, when the user opens a project, if the specification any has dependencies that were removed from Exchange or if the project was published in a different business group, API Designer takes the following actions: - Displays a message in the Dependencies pane to warn of the missing dependencies. - Disables the options "Show in files," "Change version," and "Open in Exchange" for each missing dependency. - Disallows publishing the API specification to Anypoint Exchange. - The code examples generated for RAML API specifications in the **Documentation** pane in the text editor contained errors. - Custom annotations were ignored both in the **Documentation** pane in the text editor and in Anypoint Exchange. - The **Documentation** pane in the text editor was showing under the 200 status code the responses for the other status codes for an HTTP method. ### Improvement in the Validation of Specifications by the Text Editor In previous releases, the text editor displayed an error message similar to this one when a specification included a `repeat` facet in an API specification written in RAML 0.8: `Property 'repeat' not supported in a RAML 1.0 string node at (13, 13)`. The parser incorrectly validated the facet against the RAML 1.0 specification, which does not define this facet. Now, the parser correctly validates RAML 0.8 API specifications that use the `repeat` facet, such as this specification, and does not display an error message: ```none #%RAML 0.8 title: Test API securitySchemes: - oauth_2_0: description: | Supports OAuth 2.0 for authenticating all API requests. type: OAuth 2.0 describedBy: headers: Authorization: type: string repeat: true /users: get: securedBy: [ oauth_2_0 ] ``` ## 2.12.0 **January 11, 2020** This release includes seven enhancements, twenty fixes, and three improvements to how API specifications are validated. ### Enhancements - The **Documentation** pane now renders RAML fragments of the types DataTypes, DocumentationItem, and SecurityScheme; complies with Web Content Accessibility Guidelines (WCAG) 2.1; includes new console elements for rendering XML schemas and examples; includes a simpler request panel; renders complex API specifications faster; and includes fixes for several issues reported by customers. - The **Filter** field in the visual editor did not accept input. - If you are using the text editor to write an API specification in RAML, and you try to edit a file that is a dependency, the message "This file is read-only." appears at the top of the editor. For information about dependencies, see [Add a RAML API Fragment to an API-Specification Project as a Dependency](https://docs.mulesoft.com/design-center/design-add-api-dependency). - A number of fixes and styling changes were made to the **Documentation** pane, which displays the documentation for API specifications and supported RAML fragments, and to the **Try It** feature, which lets you use the mocking service to simulate calls to resource methods in your specifications. - In the visual editor, errors are now easier to find due to red indicators placed in various locations. For example, an error in a response body for a resource method is indicated in red in four locations: ![apid vapid resource error 1](/mulesoft/current/en-us/release-notes/_images/design-center/apid-vapid-resource-error-1.png) Figure 9. Annotations 1 through 4 show four locations of red indicators that signal the presence of one or more errors. Annotation 5 shows that you can expand the resource body to see the error. Annotation 1 points to the first red indicator: the name of the type of resource method. Annotation 2 points to the second red indicator: the name of the resource method. Annotation 3 points to the third red indicator: the response code. Annotation 4 points to the fourth red indicator: the border of the **Bodies (1)** section. Annotation 5 points to the arrow you can click to expand the **Bodies (1)** section to see the error. When you click it, the border expands (as shown by Annotation 1 in the next image) and red borders appear on the left and right of the field where the error is located. ![apid vapid resource error 2](/mulesoft/current/en-us/release-notes/_images/design-center/apid-vapid-resource-error-2.png) Figure 10. Annotation 1 shows the red border of the section that the error appears in. Annotation 2 points to the field where the error is located. Hover over the field for a message that explains the error. The same types of indicator appear for errors in other parts of a specification. In this next example, the error is in the definition of the definition of a property of a data type. The name of the data type appears in red, the left border of the **Property Name** section is red, and you can click the arrow icon to expand this section and see the error. ![apid datatype error 1](/mulesoft/current/en-us/release-notes/_images/design-center/apid-datatype-error-1.png) - When you import a specification in a `.zip` file or import an asset from Exchange into an existing project, the **Replace** dialog appears when files with the same filename appear in both the `.zip` file or asset and the project. In this dialog, you can select the files that you want to replace in the project. With the 2.10.0 release, this dialog includes the new option **Select all**, which lets you select all of the listed files. - The **Import** dialog now displays a spinner to indicate that the import action is taking place. - It is now easier to include files in a specification. Open the action menu on any file that you want to include and select either the **Copy Name** or **Copy Path** options. You can then paste the name or the path into your `include` statement. - You can clone any file in a project in the text editor. In the **Files** pane, open a file’s action menu by clicking the three dots to the right of its name. Then, select **Clone File**. A copy of the file appears in the file list for the project. By default, each copy is named `n-name.extension`, where `n` is the next available number, starting from 1. To rename a clone, click the action menu and select **Rename**. ### Fixed Issues - Users without the Design Center Developer permission could open projects. Now, if a user does not have this permission, the user cannot view the list of projects in Design Center or open a project by visiting the URL. - The Experience API responded with a 403 in a particular case, but a project was still created. - The visual editor displayed an error when a data type was defined as nil and the example used a null value. Several fixes were made to the Undo/Redo feature in the visual editor. - Using the `$schema` keyword with a custom URI caused the following error: `Warning: Unable to load schema from . No schema request service available.` - The `schemaLocation` attribute now loads the location of a referenced XML schema. - The locations of XML schemas to import were not being resolved. - For the fragment types Data Type, Documentation, Extension, Library, Overlay, and Security Scheme, the message `Base URI not defined in the API file` no longer appears in API Console. - Code samples generated in API Console for resource methods sometimes included errors. - Boolean properties were rendered by API Console as strings in payloads before being passed to the mocking service in method bodies. - Spaces in URI parameters were encoded by API Console as `+` rather than as `%20` in URIs generated by the mocking service. - Large API specifications would not appear in API Console in some cases. - XML-wrapped examples in specifications written in RAML were not parsed correctly in API Console. - A specification written in OAS caused the mocking service to fail with the error \`org.json.JSONException: Duplicate key "” at…​'. - The content of the `summary` field in specifications written in OAS did not appear in API Console. - API Console was rendering integers as strings. - When a specification written in OAS had internal references to schema definitions, this message appeared in API Console in the body of the responses for a method: `The API file specifies body for this request but it does not specify the data model.` - When the mocking service was used for a GET request for which the authorization method was x-clientIDSecret, the message `Fill in required parameters` appeared even when the **Client-id** and **Client-Secret** fields in API Console were filled in. - API Console added tags to XML examples that contained arrays. ### Improvements in the Validation of Specifications by the Text Editor - The text editor now accepts as valid non-Boolean values for the `additionalItems` keyword, which is part of JSON Schema. > [!NOTE] According to JSON Schema > ([https://json-schema.org/understanding-json-schema/reference/array](https://json-schema.org/understanding-json-schema/reference/array)), > the `additionalItems` keyword "controls whether it’s valid to have additional items in the array > beyond what is defined in `items`." For example, the text editor no longer displays an error message that says the use non-Boolean values for the instance of `additionalItems` in this schema is invalid: #%RAML 1.0 title: AMF-VALIDATIONS types: contact: | { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "description": "Allows the insertion of a Contact Us request into Unilever backend systems", "properties": { "consumer": { "type": "array", "items": \[ { "type": "number" }, { "type": "string" }, { "type": "string", "enum": \["Street", "Avenue", "Boulevard"\] }, { "type": "string", "enum": \["NW", "NE", "SW", "SE"\] } \], "additionalItems": {"type": "integer"} } } } /contact: post: body: application/json: type: contact example: | { "consumer": \[1600, "Pennsylvania", "Avenue", "NW", 2050\] } - Fields used in shape merging are now being validated. For example, the following lines will be no longer valid in a RAML specification: #%RAML 1.0 title: test API resourceTypes: rt: post: body: application/json: type: object properties: a1: number /endpoint: type: rt post: body: application/json: type: string In this example, an attempt is being made to merge an object, defined as `rt` under `resourceTypes` and that has a `number` property, into a scalar. The definition of the endpoint defines its payload type as an `rt` object. However, the definition of the endpoint then tries to set the type of the payload to `string`, which is incompatible with the definition of the `rt` object as being of type `number`. - Incorrect values specified for enums are now flagged as invalid. For example, the value for this enum would be flagged as invalid because it is a map with a key and a value, rather than just a value: ```none { "swagger": "2.0", "info": { "title": "My API with Types", "version": "1.0" }, "paths": { "/orgs": { "get": { "responses": { "200": { "description": "", "schema": { "type": "string", "enum": [{ "key": "value" }] } } }, "security": [] } } } } ``` The correct declaration would be this: ```none { "swagger": "2.0", "info": { "title": "My API with Types", "version": "1.0" }, "paths": { "/orgs": { "get": { "responses": { "200": { "description": "", "schema": { "type": "string", "enum": [ "value", "value1" ] } } }, "security": [] } } } } ``` - The validation of `!include` tags is improved. For example, the following example is now parsed as valid because it is considered to be a string payload: ```none #%RAML 1.0 title: test API /resource: get: responses: 200: body: application/json: example: !includedexample ``` ## 2.9.0 **October 4, 2019** This release includes two new features, an enhancement, and several fixes. Also, four more types of errors are flagged as invalid by the parser that was released on January 10 of this year. The parser that API Designer used before that date did not flag these errors as invalid. ### New Features - You can now add custom headers when using the mocking service to test endpoints in API specifications that you are developing in the visual editor. ### Enhancement - You might experience a delay of a few seconds When you switch between branches of a project in the text editor. Now, a message appears that shows the progress in switching to the selected branch. ### Fixed Issues - In Google Chrome, the text editor displayed no error messages for a project. However, the text editor displayed many error messages for the same project in Mozilla Firefox. - A test request for a file made to the mocking service from a browser correctly resulted in the downloading of the file. However, test requests for the same file made to the mocking service from within API Designer and Exchange did not result in the downloading of the file, even though a status code of 200 was returned. - The error message `Error publishing to Exchange: Nout found` appeared in the following scenario: 1. Create an API-specification project in the text editor. 2. Go to the Dependencies panel and consume one or more Exchange assets. 3. Close the project. 4. Go to Exchange and delete one of the two consumed assets. 5. Return to API Designer and reopen the project. 6. Try to publish the API specification to Exchange. ### Errors Now Flagged As Invalid - Types defined as `nil` in payloads are no longer valid. **Example 1** In this example, the value of `type` must be `string`, not `nil`: ```none #%RAML 1.0 title: test types: MyType: type: nil example: “test” ``` **Example 2** In this example, the JSON schema must define `MyType` as a `string` type. However, the schema is empty. ```none #%RAML 1.0 title: test types: MyType: type: !include schema.json # schema.json is an empty file example: “test” ``` The error message in cases like this is `should be null at …​`. - A subtype defining a weaker constraint than one defined by its parent is no longer valid. In this example, the subtype MyType2 has the optional property `name`, defined as a string, even though the parent type MyType1 already defines its `name` property as required. ```none #%RAML 1.0 title: test types: MyType1: properties: name: string MyType2: type: MyType1 properties: name?: string #invalid ``` The error message in cases like this is `Resolution error: sub type has a weaker constraint for minItems than base type for minItems.` - A URI parameter that contains a forward slash (/) is no longer valid. In this example, the `example` for the URI parameter `transaction-Date` would cause the parser to display an error message. ```none #%RAML 1.0 title: test /endpoint: uriParameters: transaction-Date: example: 01/02/2018 ``` The error message in cases like this is `Value '01/02/2018' of uri parameter must not contain '/' character.` - Formats for `datetime` types that do not use "rfc3339" or "rfc2616" are now invalid. The following example would cause the parser to display an error message. ```none #%RAML 1.0 title: test types: MyType: type: datetime format: "rfc3338" ``` The error message in cases like this is `Invalid format value for datetime, must be ‘rfc3339’ or ‘rfc2616’.` ## 2.8.3 **September 19, 2019** This release fixes the following issue: In the 2.8.0 release, an `Unresolved reference` error was reported for a resource type that was in fact free of errors. ## 2.8.0 **September 7, 2019** ### Announcement Version 2 of the mocking service is replacing Version 1. You must migrate any API-specification project that meets _both_ of these conditions: - The mocking service was switched on for the project before January 10, 2019. - The mocking service has been running continuously since it was switched on. #### Dates for the Deprecation and End of Life of Version 1 - **On November 29, 2019**, Version 1 of the mocking service will be deprecated. Starting on that date, third-party tools must include this header in requests that they send to the mocking service to test endpoints in API specifications being developed in API Designer: `x-deprecation-acknowledgement` The header must have this value: `I understand that version 1 of the mocking service is deprecated and that I need to upgrade before February 1, 2020.` - **Starting February 1, 2020**, Version 1 of the mocking service will no longer send responses to requests. If you have not migrated your projects to use Version 2 of the mocking service by this date, the mocking service will return the HTTP status code 301 and provide a link to this document. ### New Feature The new behavioral header `MS2-Status-Code-Selection` gives you two options for controlling how the mocking service selects a status code for responses to requests. See [Add Behavioral Headers to Simulated API Calls](https://docs.mulesoft.com/design-center/apid-behavioral-headers) for details. ### Enhancements - The button **Publish to Exchange** is now **Publish**. It opens a small message that contains the button **Publish to Exchange**. The message explains why you might want to publish a specification or fragment to Exchange. If a spec or fragment has already been published, the message contains a link to it on Exchange. - In the visual editor, the top of the **Documentation** pane now shows the path of the selected resource. - In the **Publish to Exchange** dialog in previous releases, the version number in the **Version** field was generated automatically if a specification lacked a `version` node. Now, if a specification lacks this node, the field remains blank and you must specify a value. ### Fixed Issues - Uploading a library into an API-specification project when using Google Chrome caused Chrome to crash. - The text editor did not recognize the date form "yyy-mm-dd" in JSON example schemas. - Importing a particular API specification into the text editor caused Design Center to become unresponsive in Google Chrome. - The text editor was reporting an internal error during validation, but the reference in the error message was unrelated to the line at which the message stated that the error occurred. - The text editor was incorrectly reporting an unresolved reference for a library type in a resource type. - Very long project names could not be read in various locations. - The text editor displayed random warnings that XSD schemas were invalid in an API specification that had numerous, complex schemas. ## 2.7.0 **August 10, 2019** This release introduces two new features and fixes several issues. ### New Features - You can now see a list of API-specification projects and API-fragment projects that you recently opened or created. In the top-left corner of your browser window, click the three lines to the left of the Design Center logo. - **For projects created before January 10, 2019:** If no errors appear in your project when the switch that is labeled **Show Strict Errors** is toggled off, and if errors do appear in your project when that switch is toggled on, a countdown timer appears to the left of the **Publish** button to remind you of how many days you have left to resolve the errors. If the timer for such a project expires before you have resolved the errors, you will not be able to publish the specification to Exchange until you have done so. ### Fixed Issues - Published copies of complex API specifications in RAML on Exchange were truncated by 20 characters. - API specifications in RAML that included Arabic characters could not be published to Exchange. - JSON examples that included umlauts could not be uploaded to API Designer by means of the Save API. - In some cases, publishing an API specification in RAML to Exchange resulted in the last few characters of the specification not appearing in Exchange. - Importing an asset from Exchange that included dependencies could result in an error message similar to this one: `Unexpected token o in JSON at position 1`. - An `!include` in a `type` definition was incorrectly causing the error message `Error while parsing file. at (1,0)` to appear. - The API Designer xAPI was truncating the last line from specifications that were uploaded to projects by means of Anypoint CLI. - During attempts to publish an API specification in RAML, the **Main file** field in the **Publish API Specification** dialog was blank and the specification could not be published. However, if the specification was imported into a new project, then publishing it to Exchange was possible. - The validation process was erroneously generating the message `Recursive type at (0,1)` for a particular API specification in RAML. - The fractional-seconds (`ff`) part of the date-time format `yyyy-mm-ddThh:mm:ss[.ff…​]` was not supported by the mocking service, which expected the format `yyyy-MM-dd’T’HH:mm:ss`. - The validation process would erroneously display an `Unresolved reference` error message for JSON schemas that referenced other JSON schemas by using relative paths. ## 2.6.0 **July 13, 2019** This release introduces two enhancements and fixes several issues. ### Enhancements - When you republish a project to Exchange, you now can edit the name only in Exchange. This enhancement prevents naming conflicts. Due to this change, three fields are disabled in the **Publish to Exchange** dialog when you republish a project: **Name**, **Group ID**, and **Asset ID**. - The **Publish to Exchange** button is now disabled if your user ID does not have the role either of Exchange Contributor or Exchange Administrator. Disabling the button prevents you from filling in the **Publish to Exchange** dialog only to receive an error message if your user ID does not have a required role. ### Fixed Issues - Design Center presented a false positive Warning message of different values for the `discriminator` value. - AMF showed a Warning message of an unused parameter when using the declared `uriParameter` in a resource type. - In an AMF implementation, using `NamedExample` inside a NamedExample did not work with Exchange and API Designer. - Design Center allowed the first line in a RAML API definition document to be blank. - The \[object Object\] error shows up when typing a path to a filename and referencing a directory. ## 2.5.0 **June 15, 2019** This release introduces several new features in the visual editor. ### New Features in the Text Editor - You can now import binary files, such as PDF and PNG files, into your projects. Such files are not parsed and no preview for them is available. - Use behavioral headers with the mocking service to modify in various ways how the mocking service behaves. See [Add Behavioral Headers to Simulated API Calls](https://docs.mulesoft.com/design-center/apid-behavioral-headers). ### New Features in the Visual Editor - Create security schemes for your API specifications. The different supported types are OAuth 1.0, OAuth 2.0, Basic Authentication, Digest Authentication, and Pass Through. - Define union types for elements. In previous releases, you could select only one data type at a time for properties, bodies, payloads, headers, and any other kind of element. Now, you can choose multiple data types to create _union_ data types for any of those elements. When creating a union type, you won’t be able to edit any custom properties of the union type itself. An instance of the data type should meet all restrictions of at least one of the super types. - Define enums for strings and numbers. - Specify display names for methods. - Add groups to help you organize assets in the left pane. ### Enhancements - When you are using Microsoft Internet Explorer or Microsoft Edge as your browser and you click **Design Center** or the hamburger menu in the top-left corner as you are using the text editor, there is no longer a browser pop-up asking whether you want to leave the page. - It is now possible to view inline documentation for errors if you are using Microsoft Internet Explorer, Microsoft Edge, or Mozilla Firefox as your browser. Click the information icon that appears next to error messages. ### Fixed Issues - Changes made in the text editor might take up to six minutes to be parsed. - In the text editor, creating a fragment in an API-specification project, leaving the fragment without content, and then adding a reference to it from the main file before adding content to the fragment, caused the reference to be parsed as an error. - Underscores, spaces, and hyphen were not parsed as separator characters in variables in resourceTypes. - It was possible to create API specifications without the appropriate entitlement. - Very long names of API-specification projects are now better supported. If the name of a branch does not appear because the name of a project is too long, you can move your mouse over the path of the branch to see the full path. If the name of a project is too long to be seen all at once in the **Publish API Specification to Exchange** dialog, you can scroll though the field in which the name appears. - When an API specification included the definition of a type with an `!include` tag and the example of the type was also included with an `!include` tag, then the following message appeared: `should have required property '' at .raml` Here are examples of an API specification, a data type, and an example that would produce this error: API specification #%RAML 1.0 title: ac-dgt-xcpr types: DigitalProfileCreateRequest: type: !include dataType.raml examples: DigitalProfileCreateRequest\_Example: !include example.raml /profiles: post: body: application/json: DigitalProfileCreateRequest Data type #%RAML 1.0 DataType type: object properties: customerProfile: type: object properties: password: type: string Example #%RAML 1.0 NamedExample "customerProfile": { "password": "abc123" } - For certain API specifications, the API console was not appearing. - Not all types were being displayed in the list of types in the API console. - When a specification defines a boolean value but does not provide a default value, the API console now provides a default value. Doing so prevents problems from arising with the mocking service. - In some cases, an API-specification project might never finish loading when an attempt was made to open it. - API specifications that included binary files were not displayed properly in Exchange after being published. To ensure that binary files appear properly for API specifications that were created in previous releases of API Designer, follow these steps: 1. Delete the binary file from your API-specification project. 2. Import the binary file again into your project. 3. Publish the specification to Exchange again, making sure to increment the version number. - In some cases, references could not be resolved when examples were included. The error message was confusing and gave little information about the cause. ## 2.4.8 **May 18, 2019** This release introduces three new features and an enhancement, and it fixes several issues. There is also one known issue. ### New Features - The visual API editor now supports union datatypes and enums. - An information icon now appears after error messages that are related to problems with named examples. Click the icon for a description of such errors and of ways to resolve them. - There is a new dialog that asks you to confirm whether you want to delete a branch. ### Enhancement The dialog for creating projects in API Designer has been redesigned for a simpler experience. ### Fixed Issues - When a datatype was declared as the union of an object type with an array type, the API editor returned an incorrect parsing error. - When a datatype was declared as a union in the last `type` entry of a `types` declaration, the API console did not display the datatype. For example, the datatype `unionType` that is declared in the specification `Test types` below would not appear in the API console because it is the last `type` declared in the list of `types`. #%RAML 1.0 DataType # This file is located at DataTypeA.raml type: object additionalProperties: false properties: a: type: string #%RAML 1.0 DataType # This file is located at DataTypeB.raml type: object properties: a: type: number b: type: string #%RAML 1.0 title: Test types types: A: type: !include DataTypeA.raml B: type: !include DataTypeB.raml unionType: type: A | B /events: /device: get: body: application/json: type: unionType However, if you moved the declaration of `unionType` (as in the example below), then `unionType` would appear in the API console. #%RAML 1.0 title: Test types types: A: type: !include DataTypeA.raml unionType: type: A | B B: type: !include DataTypeB.raml /events: /device: get: body: application/json: type: unionType - The `title` facet was allowed in RAML Library fragments, even though this facet is invalid in fragments of that type. - The Javascript exception `Maximum call stack size exceeded` was thrown when an API specification contained a recursive datatype reference. - The error message `Syntax error, generating empty array at…​` appeared when an array type was included in the declaration of a union type by means of a type expression, as in this example: #%RAML 1.0 title: Example types: a1: type: string\[\] /samples: post: responses: 200: body: application/json: type: string | a1 - Importing an API specification from Exchange would overwrite newer versions of existing assets in a project. These steps reproduced the problem: 1. Create a RAML fragment and publish it as version 1.0.0 to Exchange. 2. Create a RAML API specification, import the fragment, and publish the API specification to Exchange. 3. Open the RAML fragment created in step 1, edit it, and publish it as version 1.0.1. 4. Create a new project and RAML API specification, import version 1.0.1 of the fragment. 5. In the project, import from Exchange the RAML API specification created in step 2. The version of the RAML fragment that is being used in the project is now 1.0.0, rather than 1.0.1. - In the visual API editor, it was not possible to drag resources and data types into groups in the left pane of the editor if you were using Microsoft Internet Explorer. ### Known Issue If you are not using Google Chrome or Mozilla Firefox as your web browser when using the API editor, clicking an information icon that appears next to an error message does not open a window to display information about the error. ## 2.4.6 **April 20, 2019** This release includes two new features and several fixes. There is also one known issue. ### New Features - You can now import projects directly from Exchange. You no longer have to download a project from Exchange to your computer or other location, and then import it into a new project in API Designer. See [Import Files into an API Project](https://docs.mulesoft.com/design-center/design-import-files) for the steps. - If you define a global media type in a specification in the visual API editor, you no longer are required to select a media type when you define the body of a response for a method. Instead, you can now leave the option `default` specified. This option is available only if a global media type is defined. ### Fixed Issues - Specifications that were several MB in size could not be published to Exchange. Now, for both the importing of projects from Exchange and the publishing projects to Exchange, the .zip files are reduced in size, preventing such errors. - Resource types and traits in API specifications that were written in RAML 1.0 were not being validated. - A project might never finish loading if you created the project in the visual API editor, created a data type in that project, closed the project, and then attempted to reopen the project. - The API editor returned the error message `Recursive type at (_x_, _y_)` for recursive DataType definitions. - The mocking service would fail if an API specification used the `example` facet, rather than the `examples` facet, to include a NamedExample fragment. - The API console might display all examples for all methods that were in a specification, not just the examples for the selected method. ### Known Issue Because of a bug in a third-party library that is used for the validation of XML against an XSD schema, the API editor can be inconsistent in displaying the error message `Could not validate XSD schema`. For example, you might or might not see the error message whenever you open a particular file that contains XML. ## 2.4.5 **April 6, 2019** This release includes a new feature, two enhancements, and two fixes. ### New Feature The editor now caches validations that are made by the AMF parser. (This parser was released on January 10 this year in the 2.4.0 release. See the release notes for 2.4.0 for more details about it.) Every time a file was opened in previous releases, the AMF parser would validate the file; during the validation, the API console would not appear in the right-hand pane of the editor. Now, opening a file does not cause the AMF parser to validate it. Therefore, the API console appears immediately whenever you switch to another file in a project. Any change to a project — typing, importing a file, or other actions — clears the project’s cache and triggers the AMF parser to validate the project again. ### Enhancements - The usability of the feature for forking projects is improved. - The navigation bar at the top of API Designer is now consistent with the navigation bars in other tools within Design Center. ### Fixed Issues - The option **API is behind a firewall**, which you can toggle on and off by clicking the shield that is on the left side of the toggle for the mocking service, was not functional. - The validation of headers was not occurring when the headers were defined in RAML files that were included as dependencies from Anypoint Exchange. - API Designer did not release a user’s lock on a project branch if the user left the project in the API editor by clicking the hamburger icon (the stack of three horizontal bars) in the top-left corner of the screen. Subsequently, no other user could edit the project branch until the previous user opened the project, opened the branch, and then left the project by clicking **Design Center** to the right of the hamburger icon. ## 2.4.4 **March 23, 2019** This release fixes six issues. ### Fixed Issues - When you are working on an API fragment, the editor now no longer displays the switch to turn on the mocking service. - When the documentation displayed in the **Documentation** pane contains more lines than the pane can accommodate, the pane does not display a scrollbar. Therefore, it is not possible to see all of the documentation. - Properties that are defined as numbers in the body of an API appear as strings in the API console. - The mocking service might return a response in JSON, even though the specification defined responses to be in XML. - The mocking service responded with a `400 Bad Request` error if a RAML API specification defined a JSON type for an HTTP header. - The editor did not display an error message when a NamedExample fragment contained properties that the RAML specification does not allow. ## 2.4.3 **February 23, 2019** This release fixes two issues. ### Fixed Issues - The behavior of the **Import API Example** dialog was faulty, making a selection difficult. You can open this dialog when you first create an API-specification project by clicking the word "example" in the sentence "Start project from an existing example," which appears in the left pane of the editor - The mocking service created invalid OAuth redirect URLs. ## 2.4.2 **February 9, 2019** This release fixes a number of issues. ### Fixed Issues - When the Mocking Service was on, the right pane of the editor was not displaying examples of JSON types for request bodies. - The editor did not show errors when the facet `properties` was declared twice for a type. - The editor displayed the error message `Expecting !!str and !!int provided` when numbers were used as keys in type definitions and in named examples. - For type declarations such as the one in this example, the editor displayed an error message that said the example value should be a multiple of the value of the `multipleOf` key: #%RAML 1.0 DataType displayName: exampleType type: number multipleOf: 0.01 example: 19.99 - The editor displayed the following error message after parsing a RAML project that included an XSD schema: `The schema document '.xsd' cannot include itself` - MIME types are now validated as strings, not as regular expressions. - Auto-completion after elements such as `uses` and `!include` was not working, and suggestions for content to place after such elements were not being offered. ## 2.4.1 **January 25, 2019** This release includes enhancements and fixes a number of issues. ### Enhancements - **For projects created before January 10, 2019:** You can turn on or off the stricter validation that began with the 2.4.0 release on January 10, 2019. You might want to do so to work with in an API-specification project that was created before this date, but don’t yet have plans for resolving the messages that this validation displays. To turn this validation off, toggle the switch that is labeled **Show Strict Errors** in the top-right corner of the editor. The default is On. + Even if you toggle this validation off, the grace period in which you must resolve the messages is still in effect. The grace period lasts at least until January 10, 2020. - The documentation describes additional RAML problems that generate violation and warning messages since the 2.4.0 release. ### Fixed Issues - When a RAML specification uses an `example` facet was being used, rather than an `examples` facet, the API editor displays a message. In the previous release, the message was not clear. - Design Center was not using the latest version of the API Console. Therefore, the JSON type for request bodies was not appearing in the right-hand pane of the API editor. - In Firefox, the body of POST and PUT requests was not appearing when the mocking service was being used, preventing requests from being sent correctly. ## 2.4.0 **January 10, 2019** This release includes several enhancements and fixes a number of issues. ### Enhancement - The API editor (one of the two editors in Design Center’s API Designer) is now using the AMF parser. This parser checks for full conformance with the RAML specification (either 0.8 or 1.0) that is being used for an API specification. If you reopen in the API editor any RAML API specifications that have already been published, you might find that there are instances of stricter validation. The AMF parser is at version 2.0.0. - The Design Center now provides native support for OAS 2.0. To learn more, [see the documentation](https://docs.mulesoft.com/design-center/design-create-publish-api-specs). - The names of projects for API specifications and API fragments can now be as long as 64 characters. - The option to download a project in YAML is now replaced with the following options, which you can access by clicking the three dots next to the name of a specification in the left pane: - **Download as**: Downloads a RAML specification as an OAS specification, or an OAS specification as a RAML specification. > [!WARNING] The downloaded file is not guaranteed to be a correct specification. - **Convert**: Converts a RAML specification to an OAS specification, or an OAS specification to a RAML specification. > [!WARNING] The converted file is not guaranteed to be a correct specification. ### Fixed Issues - A problem occurred in which an API specification could not be tested with the mocking service when OAuth 2.0 was used for security. Clicking **Authorize and Send** after filling in all of the required authentication information merely resulted in the message "Fill in the authorization form first". - The API editor did not detect that an incorrect JSON schema was being referenced. - The API console pane of the API editor was sometimes not being refreshed as different types were being selected. The same problem could occur as different responses were selected. - There were a few formatting problems in the information displayed in the API console pane. - Swedish characters were not supported in the Crowd release (November 2017). - If a RAML API specification contained a DataType that extended another DataType, the information shown in the API console pane about the extending DataType could sometimes be incorrect. - The API editor could take too long to resolve one or more DataType resources. During that time, the API console pane was blank. - When a RAML extension extended a file that used a library that was itself defined in a fragment, and the library included a trait with the `!include` tag, the API editor was unable to locate the trait. - If a RAML API fragment defined multiple properties as `: string | nil`, the API console pane did not display any information, or did so only after a long delay, after the API specification that referenced the fragment was opened. - If a project included a JSON schema, and that file itself included another JSON schema, Design Center failed to load the second schema. - The API editor was requiring the media type to be declared for message bodies, even though the RAML specifications state that `mediaType` is optional for `body` nodes. - If you tried to import a Swagger 2.0 JSON file that contained an array of objects, Design Center threw a parsing error. - The mocking service was not presenting a choice of authentication methods when a basic `securityScheme` was being referenced from a library RAML fragment. - It was possible for projects imported into Anypoint Studio from the API editor in Design Studio to contain RAML errors that were not pointed out by the API editor. - RAML errors not reported by the API editor could cause problems in the API console pane, such as failures to display various pieces of information. - If a `uses` node specified an invalid path to a library, the API editor displayed this unhelpful message: Cannot read property 'ast' of null at (1, 0) The message has been improved. - The API editor was allowing a blank line as the first line in RAML files. - For very large API specifications, validation and the appearance of the API Console in the API editor could require much more time than usual. - If an endpoint were simply `/`, the API editor would throw a parsing error. - In the API console of the API editor, query parameters did not appear after you clicked the **Try It** button. - In the API editor, changing the version number of an API specification that you were publishing to Exchange would change the value of all instances of the "version" keyword in the specification. Only the value for the root instance should have been changed. - When a custom datatype was declared as Int64, the range declared for the datatype was not validated. For example, the mistake in this definition — declaring a maximum value that is too high for Int64 values — was not caught: my\_int64: type: integer format: int64 minimum: 1000000000000000000 maximum: 9999999999999999999 - Using double angle brackets (double chevrons) enclose a parameter name in resource type and trait definitions was not supported in the API editor. - Some valid regular expressions in the RAML "pattern" element were unsupported in the API editor. - In some cases, publishing an API specification to Exchange from the API editor would result in the content of the API specification being reordered incorrectly in the editor. ## 2.2.9 **August 9, 2018** This release contains an enhancement. ### Enhancement If your organization contains more than one group ID, you can now select the group ID to associate an API specification with when you publish that specification to Anypoint Exchange. ## 2.2.8 **July 26, 2018** This release introduces a change and fixes for several issues. ### Enhancement The text editor now supports the following structure for the declaration of a `baseUri` in specifications that are written in RAML 1.0: ```raml baseUri: value: http://www.example.com/api ``` ### Fixed Issues - OAS files with identical names were allowed to be imported. There was no check to find out whether existing OAS 2.0 files in a project already had the same name as an OAS 2.0 file being imported. - The `protocols` node was not being validated either in the text editor or in the visual editor. - Error messages were not appearing for invalid `examples` nodes. Here is an example of an invalid `examples` node: ```raml title: New API types: ids: type: object properties: identification: type: string examples: - MuleSoft - Salesforce ``` The correct way to define this `examples` node would be as follows: ```raml title: New API types: ids: type: object properties: identification: type: string examples: id1: MuleSoft id2: Salesforce ``` The symbol `-`, which is used incorrectly in the invalid `examples` node is used for defining elements in arrays, as in this example: ```raml title: New API types: ids: type: object properties: identification: type: array examples: id1: - MuleSoft - Salesforce id2: - Mule - CRM ``` - Uploading an API-specification project by using `anypoint-cli` resulted in the following message if the project contained a large number of files: `Error: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: Could not open connection` - Importing an OAS 2.0 file that used parentheses in its name resulted in an error, but the error message did not explain the problem well. - The conversion of an OAS 2.0 file to RAML, which takes place when an OAS file is imported, resulted in the `required` field in the properties of response objects being set to `false` even when the value in the OAS file was `true`. - Attempts to import either RAML files or OAS 2.0 files via URL failed. If you tried to import a RAML file via URL, the file appeared empty in the text editor. If you tried to import an OAS 2.0 file via URL, the **Import** dialog would display the error message `Invalid OAS document`. - When switched on, the mocking service could incorrectly insert the URI to the mocking server. - It was possible to import an example into an API-specification project that was in read-only mode. - If in the text editor you clicked the plus sign in the left sidebar, selected **Other** in the **Add New File** dialog, and then clicked **Create** without specifying a name for the file, a new file with the name `*/` appeared in the file list. It was not possible to delete that file. ## 2.2.7 **May 16, 2018** This release fixes these issues: - Supplying a base URI parameter in the visual editor, using the parameter in a base URI, closing the visual editor, and then reopening the project resulted in an error message and a blank middle panel. - Selecting the type Number for a new Data Type in the visual editor, specifying a format, and changing the type to Integer resulted in the RAML viewer still including the specified number format. - In the visual editor, changing the type for a base URI parameter caused the RAML viewer to show the new type, but the **Type** field continued to show the previously selected type. ## 2.2.6 **April 20, 2018** This release fixes these issues: - Attempts to import OAS JSON files would result in this error message being displayed: `Cannot read property 'hasOwnProperty' of null` Such files could also fail to be converted by the JSON-to-RAML online conversion tool. - Some warning and error messages were not being displayed. ## 2.2.5 **April 6, 2018** This release includes two enhancements and fixes an issue. ### Enhancements - The left sidebar of the editor now lists groups, their resources, and their datatypes. - An example API to use in the visual editor is now available from a link in the left sidebar. ### Fixed Issue The word "type" could not be used as the name of a property in a RAML API specification. ## See Also - [Troubleshooting](https://docs.mulesoft.com/design-center/design-troubleshooting) - [Known Issues](https://help.salesforce.com/s/issues)