7 posts tagged with "OpenAPI"

Until now, our custom validation rules supported Pattern, Order, and Length verification methods. This allowed us to enforce specific patterns for property values, restrict property lengths, and validate alphabetical ordering within OpenAPI definitions.

We're excited to introduce a new verification method: "Required."

With this update, you can now mark a property as required - even if OpenAPI standards don't enforce it. This means greater flexibility in defining custom validation rules, including support for vendor extensions.

We have introduced the acceptance of unlisted enum values in the API response in SDKs for all languages.

We are pleased to announce that we have added the support for password schema format in API Transformer so that you can now transform between OpenAPI specification versions (v2.0 and above) without losing this information.

APIMatic now exports any data available for a schema that also uses $ref to reference another schema definition, by placing the reference and the sibling data within the allOf construct.

We are pleased to announce support for read-only and write-only properties in API Transformer which is one of the commonly used features of OpenAPI specification documents (v2.0 and above).

The Discriminator object in OpenAPI v3 supports a set of mapping values that helps determine which schema to map to based on the discriminator property's value in the payload. We have now added support for this set of mapping values in our OpenAPI v3 import and export. Previously, only the key or title of each schema involved in the hierarchy was considered as its discriminator value or one provided using the x-discriminator-value extension.

Here at APIMatic, we are excited to finally announce support for OpenAPI's newer version v3.1 in all our major offerings including API Transformer, Developer Experience Portal and Code Generation. This format has now become a part of our ever-growing list of supported input and output formats.