diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
index f46d5bc0..34f4b30f 100644
--- a/modules/ROOT/nav.adoc
+++ b/modules/ROOT/nav.adoc
@@ -8,6 +8,13 @@
   ** xref:api-led-deploy.adoc[Step 5. Deploy the API to CloudHub]
   ** xref:api-led-operate.adoc[Step 6. Operate the API]
 * xref:intro-platform-hosting.adoc[Hosting Options]
+* xref:api-compatibility-matrix.adoc[Anypoint Platform Compatibility Support for Restful-APIs by Products]
+  ** xref:api-spec-support-api-designer.adoc[API Designer]
+  ** xref:api-spec-support-exchange.adoc[Anypoint Exchange]
+  ** xref:api-spec-support-api-manager.adoc[API Manager]
+  ** xref:api-spec-support-datagraph.adoc[Anypoint Datagraph]
+  ** xref:api-spec-support-api-kit.adoc[APIkit]
+  ** xref:api-spec-support-rest-connect.adoc[REST Connect]
 * xref:browser-support.adoc[Browser Support]
 * xref:glossary.adoc[Glossary]
 * xref:contribute.adoc[Contribute to MuleSoft Documentation]
diff --git a/modules/ROOT/pages/api-compatibility-matrix.adoc b/modules/ROOT/pages/api-compatibility-matrix.adoc
new file mode 100644
index 00000000..aae325a7
--- /dev/null
+++ b/modules/ROOT/pages/api-compatibility-matrix.adoc
@@ -0,0 +1,17 @@
+= Anypoint Platform Compatibility Support for Restful-APIs
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+
+You can design an API in Anypoint Platform using the RESTful API Modeling Language (RAML) or the OpenAPI Specification (OAS) format based on your needs. Both RAML and OAS specifications have a common REST API model and provide similar features.
+
+MuleSoft's underlying metadata libraries and components, which includes AMF (parser) and ALS (language server for IDEs), provides interoperability using a common metadata model and enables data definition reuse, use of linting rules, and provides translation to and from both RAML and OAS specifications.
+
+Before you start designing an API, learn more about how each of the specification features are implemented and supported in Anypoint Platform products:
+
+* xref:api-spec-support-api-designer.adoc[API Designer]
+* xref:api-spec-support-exchange.adoc[Anypoint Exchange]
+* xref:api-spec-support-api-manager.adoc[API Manager]
+* xref:api-spec-support-datagraph.adoc[Anypoint Datagraph]
+* xref:api-spec-support-api-kit.adoc[APIkit]
+* xref:api-spec-support-rest-connect.adoc[REST Connect]
diff --git a/modules/ROOT/pages/api-spec-support-api-designer.adoc b/modules/ROOT/pages/api-spec-support-api-designer.adoc
new file mode 100644
index 00000000..cd660f09
--- /dev/null
+++ b/modules/ROOT/pages/api-spec-support-api-designer.adoc
@@ -0,0 +1,58 @@
+= API Specifications Support in API Designer
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+:keywords: api, instance, manager
+
+You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in API Designer.
+
+[%header%autowidth.spread,cols="a,a,a,a"]
+|===
+| Feature: Description| RAML Implementation | OAS Implementation | API Designer Support
+4+| *Modularity:* The ability to break an API specification into reusable and shared units.
+| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | The design of the API project console is rendered and the document and examples are validated.
+| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Edited as a stand-alone project. Supports the reuse of the module in an API project.
+| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Edited as a stand-alone project. Supports the reuse of the module in an API project.
+| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Can be edited and rendered correctly if used as main the project file.
+| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Can be edited and rendered correctly if used as main the project file.
+4+| *Reusability:* The ability to reuse the API description in multiple specifications.
+| Inline declarations and references: The ability to declare and reference elements from multiple documents. | Inclusion and named references to: datatypes, traits, resource types, and annotations declarations. | JSON reference and OAS components. | Autocompletion when editing and dedicated rendering provided in the console.
+| Traits: Macros that extend operations in the functional model, such as pagination, that can be reused in multiple specifications for consistency | Operation macros and RAML traits | Not applicable | Autocompletion when editing and dedicated rendering in console.
+| Resource types: Macros that extend resources in the functional model with complex behavior and data definition that can be reused in multiple specifications for consistency | Endpoint macros and RAML resource types | Not applicable | Autocompletion when editing and dedicated rendering in console.
+4+| *API Metadata:* Provides metadata about the API that might be used by tooling as required.
+| API Entrypoint: The main entry point for the API description, mostly human-readable information, such as title, version, license, and so forth. | RAML document top level information | OAS Open API object| Can be edited and validated and enables console rendering.
+| Server and protocols: Denotes the actual connectivity to the service | RAML base URI information | OAS Server object | Small differences in the supported protocols.
+| Terms of service & licensing: The user agreement and licensing information of the API | Only plain documentation | OAS Info object |
+| User documentation: Includes user guide and reference material that clarifies how the API works. | RAML description properties in different parts of the specification | OAS description properties in the specification objects | Can be edited and validated and enables console rendering.
+| Localized documentation: Specifies multi-lingual descriptions | Using overlays | Not applicable | Not applicable
+| Tags: Classification of parts of the specification | Only use annotations | OAS Tag object | Not applicable
+4+| *Functional model:* A declaration of the resources to use when RPCs are invoked.
+| Endpoints: Refers to the resources and RPC invocations in the API | Because RAML is more RESTful, the RAML resources are more explicit in its working and allows for the nesting of those resources. | OAS Path Item objects under the Paths object | Allows editing and validations, and enables console rendering.
+| Methods and bindings to HTTP uniform interface: Includes operations over the resource and information about how to invoke the RPC operation. | Get, Patch, Put, Post, Delete, Options, and head RAML operations | Get, Put, Post, Delete, Options, Head, Patch, Trace and fixed fields under the OAS Path Item object | Allows editing and validations, and enables console rendering.
+| Input parameters and HTTP bindings: Specifies the input parameters for the operation. | RAML parameters | OAS Parameter object | Allows editing and validations, and enables console rendering.
+| Responses with multiple media types: Specifies the output parameter for the operation. | RAML responses | OAS Response object | Allows editing and validations, and enables console rendering.
+| Responses with bindings to HTTP status codes: Specifies the binding to the HTTP status code. | RAML responses | OAS Response object | Allows editing and validations, and enables console rendering.
+| Callbacks: Specifies the asynchronous invocations and webhooks. | Not applicable | OAS Callback object | Allows editing and validations, and enables console rendering.
+| Links: Specifies the static connections between endpoints in the specification, excluding hyperlinks in the data. |  Not applicable | OAS Link object | Allows editing and validations, and enables console rendering.
+4+| *Security model:* A declaration of which security mechanisms you can used across the APIs.
+| OAuth 1.0: The API authentication requires using OAuth 1.0 as described in https://tools.ietf.org/html/rfc5849[RFC5849]. | RAML security schemes | Not applicable | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| OAuth 2.0: The API authentication requires using OAuth 2.0 as described in https://tools.ietf.org/html/rfc6749[RFC6749]. | RAML security schemes | OAS Security Scheme object | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| Basic: The API authentication relies on using Basic Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617]. | RAML security schemes | OAS Security Scheme object | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| Digest: The API authentication relies on using Digest Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617] | RAML security schemes | Not applicable | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| API Key: The API authentication relies on using API key (either as a header, a cookie parameter, or as a query parameter). | Not applicable | OAS Security Scheme object | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| Open ID Connect: The API authentication relies on using OAuth2's common flows (implicit, password, client credentials and authorization code) defined in https://tools.ietf.org/html/draft-ietf-oauth-discovery-06[OpenID Connect Discovery]. | Not applicable | OAS Security Scheme object | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| Pass through: Headers or query parameters are passed through to the API based on a defined mapping. | RAML security schemes | Not applicable | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+| Custom: The API authentication relies on another custom authentication method. | RAML security schemes | OAS Security Scheme object | Allows editing and validations, and enables console rendering. Note that the security schemes might be out-of-sync with actual policy in API Manager.
+4+| *Data description and validation:* Validation of any XML or JSON instance against inner elements follows the same restrictions as the validation against a regular XML or JSON schema.
+| JSON schema constraints and support: The level of support or constraints on JSON schemas. This is the base for both. RAML Types is a superset | RAML JSON support | OAS Schema object | Allows editing and validations, and enables console rendering.
+| Schema Inheritance: The combining and extending of model definitions by using properties of JSON Schema.| RAML type inheritance | *Simulated with `$allOf`, not proper inheritance, murky situation in OAS Schema* | Allows editing and validations, and enables console rendering.
+| Type expressions: Type expressions can be used wherever a type is expected. Using type expressions, you can devise type unions, arrays, maps, and other things.| RAML type expressions | Not applicable | Allows editing and validations, and enables console rendering.
+| XML Schema constraints and support: The level of support or constraints on XML schemas. | RAML XML support provided indirectly through RAML XML facets for RAML types. | Support provided indirectly through XML properties for the `Schema object` | Limited editing support provided.
+| Examples: RAML or OAS examples of implementing validations. | RAML examples | OAS `Example object` | Allows editing and validations, and enables console rendering.
+| Mandatory valid examples: Required examples that are valid. | Not applicable | Not applicable | Allows validation
+4+| *Meta-model extensibility:* Defines the ability to extend the format to describe additional details or objects.
+| Custom property extensions: Extensions and additional details for custom properties. | Annotations | OAS specification extensions | Allows editing and validations, and enables console rendering.
+| Custom node extensions: Additional details for custom node extensions. | Complex annotations | Not applicable | Allows editing and validations, and enables console rendering.
+| Extensions schema: Additional details about extension schemas | Annotations can have a schema and can be validated | Not applicable | Allows editing and validations, and enables console rendering.
+| Extensions semantics: Semantics to be used for defining extensions. | Not applicable | Not applicable | Not applicable
+|===
diff --git a/modules/ROOT/pages/api-spec-support-api-manager.adoc b/modules/ROOT/pages/api-spec-support-api-manager.adoc
new file mode 100644
index 00000000..fbd34b72
--- /dev/null
+++ b/modules/ROOT/pages/api-spec-support-api-manager.adoc
@@ -0,0 +1,58 @@
+= API Specifications Support in Anypoint API Manager
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+:keywords: api, instance, manager
+
+You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in API Manager.
+
+[%header%autowidth.spread,cols="a,a,a,a"]
+|===
+| Feature: Description| RAML Implementation | OAS Implementation | API Manager Support
+4+| *Modularity:* The ability to break an API specification into reusable and shared units.
+| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | API instance associated with the API (RAML only) can be managed.
+| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Not applicable
+| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Not applicable
+| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be managed.
+| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be managed.
+4+| *Reusability:* The ability to reuse the API description in multiple specifications.
+| Inline declarations and references: The ability to declare and reference elements from multiple documents. | Inclusion and named references to: datatypes, traits, resource types, and annotations declarations. | JSON reference and OAS components. | Inlines through AMF for management.
+| Traits: Macros that extend operations in the functional model, such as pagination, that can be reused in multiple specifications for consistency | Operation macros and RAML traits | Not applicable | Inlines through AMF for management.
+| Resource types: Macros that extend resources in the functional model with complex behavior and data definition that can be reused in multiple specifications for consistency | Endpoint macros and RAML resource types | Not applicable | Inlines through AMF for management.
+4+| *API Metadata:* Provides metadata about the API that might be used by tooling as required.
+| API Entrypoint: The main entry point for the API description, mostly human-readable information, such as title, version, license, and so forth. | RAML document top level information | OAS Open API object| Provides default values for asset creation.
+| Server and protocols: Denotes the actual connectivity to the service | RAML base URI information | OAS Server object | API Manager overwrites the instance being deployed and managed.
+| Terms of service & licensing: The user agreement and licensing information of the API | Only plain documentation | OAS Info object | Not applicable
+| User documentation: Includes user guide and reference material that clarifies how the API works. | RAML description properties in different parts of the specification | OAS description properties in the specification objects | Not applicable
+| Localized documentation: Specifies multi-lingual descriptions | Using overlays | Not applicable | Not applicable
+| Tags: Classification of parts of the specification | Only use annotations | OAS Tag object | Not applicable
+4+| *Functional model:* A declaration of the resources to use when RPCs are invoked.
+| Endpoints: Refers to the resources and RPC invocations in the API | Because RAML is more RESTful, the RAML resources are more explicit in its working and allows for the nesting of those resources. | OAS Path Item objects under the Paths object | Applies endpoint level policies (RAML only).
+| Methods and bindings to HTTP uniform interface: Includes operations over the resource and information about how to invoke the RPC operation. | Get, Patch, Put, Post, Delete, Options, and head RAML operations | Get, Put, Post, Delete, Options, Head, Patch, Trace and fixed fields under the OAS Path Item object | Applies endpoint level policies (RAML only).
+| Input parameters and HTTP bindings: Specifies the input parameters for the operation. | RAML parameters | OAS Parameter object | Applies endpoint level policies (RAML only).
+| Responses with multiple media types: Specifies the output parameter for the operation. | RAML responses | OAS Response object | Applies endpoint level policies (RAML only).
+| Responses with bindings to HTTP status codes: Specifies the binding to the HTTP status code. | RAML responses | OAS Response object | Applies endpoint level policies (RAML only).
+| Callbacks: Specifies the asynchronous invocations and webhooks. | Not applicable | OAS Callback object | Not applicable
+| Links: Specifies the static connections between endpoints in the specification, excluding hyperlinks in the data. |  Not applicable | OAS Link object | Not applicable
+4+| *Security model:* A declaration of which security mechanisms you can used across the APIs.
+| OAuth 1.0: The API authentication requires using OAuth 1.0 as described in https://tools.ietf.org/html/rfc5849[RFC5849]. | RAML security schemes | Not applicable | Not applicable
+| OAuth 2.0: The API authentication requires using OAuth 2.0 as described in https://tools.ietf.org/html/rfc6749[RFC6749]. | RAML security schemes | OAS Security Scheme object | Can apply as a policy.
+| Basic: The API authentication relies on using Basic Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617]. | RAML security schemes | OAS Security Scheme object | Can apply as a policy.
+| Digest: The API authentication relies on using Digest Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617] | RAML security schemes | Not applicable | Not applicable
+| API Key: The API authentication relies on using API key (either as a header, a cookie parameter, or as a query parameter). | Not applicable | OAS Security Scheme object | Can apply as a policy.
+| Open ID Connect: The API authentication relies on using OAuth2's common flows (implicit, password, client credentials and authorization code) defined in https://tools.ietf.org/html/draft-ietf-oauth-discovery-06[OpenID Connect Discovery]. | Not applicable | OAS Security Scheme object | Can apply as a policy.
+| Pass through: Headers or query parameters are passed through to the API based on a defined mapping. | RAML security schemes | Not applicable | Does not need policy.
+| Custom: The API authentication relies on another custom authentication method. | RAML security schemes | OAS Security Scheme object | Can implement custom policies.
+4+| *Data description and validation:* Validation of any XML or JSON instance against inner elements follows the same restrictions as the validation against a regular XML or JSON schema.
+| JSON schema constraints and support: The level of support or constraints on JSON schemas. This is the base for both. RAML Types is a superset | RAML JSON support | OAS Schema object | Not applicable
+| Schema Inheritance: The combining and extending of model definitions by using properties of JSON Schema.| RAML type inheritance | *Simulated with `$allOf`, not proper inheritance, murky situation in OAS Schema* | Not applicable
+| Type expressions: Type expressions can be used wherever a type is expected. Using type expressions, you can devise type unions, arrays, maps, and other things.| RAML type expressions | Not applicable |  Not applicable
+| XML Schema constraints and support: The level of support or constraints on XML schemas. | RAML XML support provided indirectly through RAML XML facets for RAML types. | Support provided indirectly through XML properties for the `Schema object` | Not applicable
+| Examples: RAML or OAS examples of implementing validations. | RAML examples | OAS `Example object` | Not applicable
+| Mandatory valid examples: Required examples that are valid. | Not applicable | Not applicable | Not applicable
+4+| *Meta-model extensibility:* Defines the ability to extend the format to describe additional details or objects.
+| Custom property extensions: Extensions and additional details for custom properties. | Annotations | OAS specification extensions | Not applicable
+| Custom node extensions: Additional details for custom node extensions. | Complex annotations | Not applicable | Not applicable
+| Extensions schema: Additional details about extension schemas | Annotations can have a schema and can be validated |Not applicable | Not applicable
+| Extensions semantics: Semantics to be used for defining extensions. |  Not applicable | Not applicable | Not applicable
+|===
diff --git a/modules/ROOT/pages/api-spec-support-apikit.adoc b/modules/ROOT/pages/api-spec-support-apikit.adoc
new file mode 100644
index 00000000..6e3c3144
--- /dev/null
+++ b/modules/ROOT/pages/api-spec-support-apikit.adoc
@@ -0,0 +1,58 @@
+= API Specifications Support in APIkit
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+:keywords: api, instance, manager
+
+You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in APIkit.
+
+[%header%autowidth.spread,cols="a,a,a,a"]
+|===
+| Feature: Description| RAML Implementation | OAS Implementation | APIkit Support
+4+| *Modularity:* The ability to break an API specification into reusable and shared units.
+| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Can be scaffolded.
+| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Not applicable
+| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Not applicable
+| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be scaffolded.
+| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be scaffolded.
+4+| *Reusability:* The ability to reuse the API description in multiple specifications.
+| Inline declarations and references: The ability to declare and reference elements from multiple documents. | Inclusion and named references to: datatypes, traits, resource types, and annotations declarations. | JSON reference and OAS components. | Inlines through AMF for scaffolding.
+| Traits: Macros that extend operations in the functional model, such as pagination, that can be reused in multiple specifications for consistency | Operation macros and RAML traits | Not applicable | Inlines through AMF for scaffolding.
+| Resource types: Macros that extend resources in the functional model with complex behavior and data definition that can be reused in multiple specifications for consistency | Endpoint macros and RAML resource types | Not applicable | Inlines through AMF for scaffolding.
+4+| *API Metadata:* Provides metadata about the API that might be used by tooling as required.
+| API Entrypoint: The main entry point for the API description, mostly human-readable information, such as title, version, license, and so forth. | RAML document top level information | OAS Open API object| Not applicable
+| Server and protocols: Denotes the actual connectivity to the service | RAML base URI information | OAS Server object | Not applicable
+| Terms of service & licensing: The user agreement and licensing information of the API | Only plain documentation | OAS Info object | Not applicable
+| User documentation: Includes user guide and reference material that clarifies how the API works. | RAML description properties in different parts of the specification | OAS description properties in the specification objects | Not applicable
+| Localized documentation: Specifies multi-lingual descriptions | Using overlays | Not applicable | Not applicable
+| Tags: Classification of parts of the specification | Only use annotations | OAS Tag object | Not applicable
+4+| *Functional model:* A declaration of the resources to use when RPCs are invoked.
+| Endpoints: Refers to the resources and RPC invocations in the API | Because RAML is more RESTful, the RAML resources are more explicit in its working and allows for the nesting of those resources. | OAS Path Item objects under the Paths object | Scaffolds flows.
+| Methods and bindings to HTTP uniform interface: Includes operations over the resource and information about how to invoke the RPC operation. | Get, Patch, Put, Post, Delete, Options, and head RAML operations | Get, Put, Post, Delete, Options, Head, Patch, Trace and fixed fields under the OAS Path Item object | Scaffolds flows.
+| Input parameters and HTTP bindings: Specifies the input parameters for the operation. | RAML parameters | OAS Parameter object | Scaffolds flows.
+| Responses with multiple media types: Specifies the output parameter for the operation. | RAML responses | OAS Response object | Scaffolds flows.
+| Responses with bindings to HTTP status codes: Specifies the binding to the HTTP status code. | RAML responses | OAS Response object | Scaffolds flows.
+| Callbacks: Specifies the asynchronous invocations and webhooks. | Not applicable | OAS Callback object | Not applicable
+| Links: Specifies the static connections between endpoints in the specification, excluding hyperlinks in the data. |  Not applicable | OAS Link object | Not applicable
+4+| *Security model:* A declaration of which security mechanisms you can used across the APIs.
+| OAuth 1.0: The API authentication requires using OAuth 1.0 as described in https://tools.ietf.org/html/rfc5849[RFC5849]. | RAML security schemes | Not applicable | Not applicable
+| OAuth 2.0: The API authentication requires using OAuth 2.0 as described in https://tools.ietf.org/html/rfc6749[RFC6749]. | RAML security schemes | OAS Security Scheme object | Not applicable
+| Basic: The API authentication relies on using Basic Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617]. | RAML security schemes | OAS Security Scheme object | Not applicable
+| Digest: The API authentication relies on using Digest Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617] | RAML security schemes | Not applicable | Not applicable
+| API Key: The API authentication relies on using API key (either as a header, a cookie parameter, or as a query parameter). | Not applicable | OAS Security Scheme object | Not applicable
+| Open ID Connect: The API authentication relies on using OAuth2's common flows (implicit, password, client credentials and authorization code) defined in https://tools.ietf.org/html/draft-ietf-oauth-discovery-06[OpenID Connect Discovery]. | Not applicable | OAS Security Scheme object | Not applicable
+| Pass through: Headers or query parameters are passed through to the API based on a defined mapping. | RAML security schemes | Not applicable | Not applicable
+| Custom: The API authentication relies on another custom authentication method. | RAML security schemes | OAS Security Scheme object | Not applicable
+4+| *Data description and validation:* Validation of any XML or JSON instance against inner elements follows the same restrictions as the validation against a regular XML or JSON schema.
+| JSON schema constraints and support: The level of support or constraints on JSON schemas. This is the base for both. RAML Types is a superset | RAML JSON support | OAS Schema object | Automatic runtime validation.
+| Schema Inheritance: The combining and extending of model definitions by using properties of JSON Schema.| RAML type inheritance | *Simulated with `$allOf`, not proper inheritance, murky situation in OAS Schema* | Flattened at runtime.
+| Type expressions: Type expressions can be used wherever a type is expected. Using type expressions, you can devise type unions, arrays, maps, and other things.| RAML type expressions | Not applicable | Flattened at runtime.
+| XML Schema constraints and support: The level of support or constraints on XML schemas. | RAML XML support provided indirectly through RAML XML facets for RAML types. | Support provided indirectly through XML properties for the `Schema object` | Automatic runtime validation.
+| Examples: RAML or OAS examples of implementing validations. | RAML examples | OAS `Example object` | Not applicable
+| Mandatory valid examples: Required examples that are valid. | Not applicable | Not applicable | Not applicable
+4+| *Meta-model extensibility:* Defines the ability to extend the format to describe additional details or objects.
+| Custom property extensions: Extensions and additional details for custom properties. | Annotations | OAS specification extensions | Used for advanced scaffolding (for example, OData annotations).
+| Custom node extensions: Additional details for custom node extensions. | Complex annotations | Not applicable | Not applicable
+| Extensions schema: Additional details about extension schemas | Annotations can have a schema and can be validated |Not applicable | Not applicable
+| Extensions semantics: Semantics to be used for defining extensions. |  Not applicable | Not applicable | Not applicable
+|===
diff --git a/modules/ROOT/pages/api-spec-support-datagraph.adoc b/modules/ROOT/pages/api-spec-support-datagraph.adoc
new file mode 100644
index 00000000..4fb31dea
--- /dev/null
+++ b/modules/ROOT/pages/api-spec-support-datagraph.adoc
@@ -0,0 +1,58 @@
+= API Specifications Support in Anypoint Datagraph
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+:keywords: api, instance, manager
+
+You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in Anypoint Datagraph.
+
+[%header%autowidth.spread,cols="a,a,a,a"]
+|===
+| Feature: Description| RAML Implementation | OAS Implementation | Anypoint Datagraph Support
+4+| *Modularity:* The ability to break an API specification into reusable and shared units.
+| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Can be federated as part of a federated API.
+| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Not applicable
+| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Not applicable
+| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be federated.
+| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Modified APIs can be federated.
+4+| *Reusability:* The ability to reuse the API description in multiple specifications.
+| Inline declarations and references: The ability to declare and reference elements from multiple documents. | Inclusion and named references to: datatypes, traits, resource types, and annotations declarations. | JSON reference and OAS components. | Provides data type names for federated APIs.
+| Traits: Macros that extend operations in the functional model, such as pagination, that can be reused in multiple specifications for consistency | Operation macros and RAML traits | Not applicable | Inlines through AMF for federation.
+| Resource types: Macros that extend resources in the functional model with complex behavior and data definition that can be reused in multiple specifications for consistency | Endpoint macros and RAML resource types | Not applicable | Inlines through AMF for federation.
+4+| *API Metadata:* Provides metadata about the API that might be used by tooling as required.
+| API Entrypoint: The main entry point for the API description, mostly human-readable information, such as title, version, license, and so forth. | RAML document top level information | OAS Open API object| Provides default values for APIs being federated.
+| Server and protocols: Denotes the actual connectivity to the service | RAML base URI information | OAS Server object | Provides default values for external APIs not managed by Anypoint Platform.
+| Terms of service & licensing: The user agreement and licensing information of the API | Only plain documentation | OAS Info object | Not applicable
+| User documentation: Includes user guide and reference material that clarifies how the API works. | RAML description properties in different parts of the specification | OAS description properties in the specification objects | Not applicable
+| Localized documentation: Specifies multi-lingual descriptions | Using overlays | Not applicable | Not applicable
+| Tags: Classification of parts of the specification | Only use annotations | OAS Tag object | Not applicable
+4+| *Functional model:* A declaration of the resources to use when RPCs are invoked.
+| Endpoints: Refers to the resources and RPC invocations in the API | Because RAML is more RESTful, the RAML resources are more explicit in its working and allows for the nesting of those resources. | OAS Path Item objects under the Paths object | Generates data type providers for federation.
+| Methods and bindings to HTTP uniform interface: Includes operations over the resource and information about how to invoke the RPC operation. | Get, Patch, Put, Post, Delete, Options, and head RAML operations | Get, Put, Post, Delete, Options, Head, Patch, Trace and fixed fields under the OAS Path Item object | Supports only GET.
+| Input parameters and HTTP bindings: Specifies the input parameters for the operation. | RAML parameters | OAS Parameter object | Generates data type providers for federation.
+| Responses with multiple media types: Specifies the output parameter for the operation. | RAML responses | OAS Response object | Orchestrates queries (only JSON).
+| Responses with bindings to HTTP status codes: Specifies the binding to the HTTP status code. | RAML responses | OAS Response object | Orchestrates queries (only 2xx responses).
+| Callbacks: Specifies the asynchronous invocations and webhooks. | Not applicable | OAS Callback object | Not applicable
+| Links: Specifies the static connections between endpoints in the specification, excluding hyperlinks in the data. |  Not applicable | OAS Link object | Not applicable
+4+| *Security model:* A declaration of which security mechanisms you can used across the APIs.
+| OAuth 1.0: The API authentication requires using OAuth 1.0 as described in https://tools.ietf.org/html/rfc5849[RFC5849]. | RAML security schemes | Not applicable | Not applicable
+| OAuth 2.0: The API authentication requires using OAuth 2.0 as described in https://tools.ietf.org/html/rfc6749[RFC6749]. | RAML security schemes | OAS Security Scheme object | Not applicable
+| Basic: The API authentication relies on using Basic Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617]. | RAML security schemes | OAS Security Scheme object | Not applicable
+| Digest: The API authentication relies on using Digest Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617] | RAML security schemes | Not applicable | Not applicable
+| API Key: The API authentication relies on using API key (either as a header, a cookie parameter, or as a query parameter). | Not applicable | OAS Security Scheme object | Supported for federation.
+| Open ID Connect: The API authentication relies on using OAuth2's common flows (implicit, password, client credentials and authorization code) defined in https://tools.ietf.org/html/draft-ietf-oauth-discovery-06[OpenID Connect Discovery]. | Not applicable | OAS Security Scheme object | Not applicable
+| Pass through: Headers or query parameters are passed through to the API based on a defined mapping. | RAML security schemes | Not applicable | Not applicable
+| Custom: The API authentication relies on another custom authentication method. | RAML security schemes | OAS Security Scheme object | Not applicable
+4+| *Data description and validation:* Validation of any XML or JSON instance against inner elements follows the same restrictions as the validation against a regular XML or JSON schema.
+| JSON schema constraints and support: The level of support or constraints on JSON schemas. This is the base for both. RAML Types is a superset | RAML JSON support | OAS Schema object | Generates type schemas in the federated API.
+| Schema Inheritance: The combining and extending of model definitions by using properties of JSON Schema.| RAML type inheritance | *Simulated with `$allOf`, not proper inheritance, murky situation in OAS Schema* | Supports union types in the federated API. Scalars in inheritance are not supported.
+| Type expressions: Type expressions can be used wherever a type is expected. Using type expressions, you can devise type unions, arrays, maps, and other things.| RAML type expressions | Not applicable |  Supports union types in the federated API. Scalars in expression are not supported.
+| XML Schema constraints and support: The level of support or constraints on XML schemas. | RAML XML support provided indirectly through RAML XML facets for RAML types. | Support provided indirectly through XML properties for the `Schema object` | Not applicable
+| Examples: RAML or OAS examples of implementing validations. | RAML examples | OAS `Example object` | Not applicable
+| Mandatory valid examples: Required examples that are valid. | Not applicable | Not applicable | Not applicable
+4+| *Meta-model extensibility:* Defines the ability to extend the format to describe additional details or objects.
+| Custom property extensions: Extensions and additional details for custom properties. | Annotations | OAS specification extensions | Not applicable
+| Custom node extensions: Additional details for custom node extensions. | Complex annotations | Not applicable | Not applicable
+| Extensions schema: Additional details about extension schemas | Annotations can have a schema and can be validated |Not applicable | Not applicable
+| Extensions semantics: Semantics to be used for defining extensions. |  Not applicable | Not applicable | Not applicable
+|===
diff --git a/modules/ROOT/pages/api-spec-support-exchange.adoc b/modules/ROOT/pages/api-spec-support-exchange.adoc
new file mode 100644
index 00000000..4855156d
--- /dev/null
+++ b/modules/ROOT/pages/api-spec-support-exchange.adoc
@@ -0,0 +1,58 @@
+= API Specifications Support in Anypoint Exchange
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+:keywords: api, instance, manager
+
+You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in Exchange.
+
+[%header%autowidth.spread,cols="a,a,a,a"]
+|===
+| Feature: Description| RAML Implementation | OAS Implementation | Exchange Support
+4+| *Modularity:* The ability to break an API specification into reusable and shared units.
+| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Allows publication and versioning of an API asset in Exchange console rendering. Additionally, advanced search is supported.
+| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Allows publication of a RAML API fragment asset (only RAML). Console rendering and advanced search are not supported.
+| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Allows publication of a RAML API fragment asset (only RAML). Console rendering and advanced search are not supported.
+| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Allows publishing modified APIs as an API asset.
+| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Allows publishing modified APIs as an API asset.
+4+| *Reusability:* The ability to reuse the API description in multiple specifications.
+| Inline declarations and references: The ability to declare and reference elements from multiple documents. | Inclusion and named references to: datatypes, traits, resource types, and annotations declarations. | JSON reference and OAS components. | Allows advanced searches when defined in an API document. Does not support advanced searches of fragments.
+| Traits: Macros that extend operations in the functional model, such as pagination, that can be reused in multiple specifications for consistency | Operation macros and RAML traits | Not applicable | Allows advanced searches when defined in an API document. Does not support advanced searches of fragments.
+| Resource types: Macros that extend resources in the functional model with complex behavior and data definition that can be reused in multiple specifications for consistency | Endpoint macros and RAML resource types | Not applicable | Allows advanced searches when defined in an API document. Does not support advanced searches of fragments.
+4+| *API Metadata:* Provides metadata about the API that might be used by tooling as required.
+| API Entrypoint: The main entry point for the API description, mostly human-readable information, such as title, version, license, and so forth. | RAML document top level information | OAS Open API object| Enables console rendering and default values for asset creation.
+| Server and protocols: Denotes the actual connectivity to the service | RAML base URI information | OAS Server object | Enables console rendering and default values for lists of instances.
+| Terms of service & licensing: The user agreement and licensing information of the API | Only plain documentation | OAS Info object | Allows advanced searches and enables console documentation.
+| User documentation: Includes user guide and reference material that clarifies how the API works. | RAML description properties in different parts of the specification | OAS description properties in the specification objects | Allows advanced searches of API documents and enables console documentation.
+| Localized documentation: Specifies multi-lingual descriptions | Using overlays | Not applicable | Allows advanced searches and enables console documentation.
+| Tags: Classification of parts of the specification | Only use annotations | OAS Tag object | Allows advanced searches and enables console documentation.
+4+| *Functional model:* A declaration of the resources to use when RPCs are invoked.
+| Endpoints: Refers to the resources and RPC invocations in the API | Because RAML is more RESTful, the RAML resources are more explicit in its working and allows for the nesting of those resources. | OAS Path Item objects under the Paths object | Enables console rendering.
+| Methods and bindings to HTTP uniform interface: Includes operations over the resource and information about how to invoke the RPC operation. | Get, Patch, Put, Post, Delete, Options, and head RAML operations | Get, Put, Post, Delete, Options, Head, Patch, Trace and fixed fields under the OAS Path Item object | Enables console rendering.
+| Input parameters and HTTP bindings: Specifies the input parameters for the operation. | RAML parameters | OAS Parameter object | Enables console rendering.
+| Responses with multiple media types: Specifies the output parameter for the operation. | RAML responses | OAS Response object | Enables console rendering.
+| Responses with bindings to HTTP status codes: Specifies the binding to the HTTP status code. | RAML responses | OAS Response object | Enables console rendering.
+| Callbacks: Specifies the asynchronous invocations and webhooks. | Not applicable | OAS Callback object | Enables console rendering.
+| Links: Specifies the static connections between endpoints in the specification, excluding hyperlinks in the data. |  Not applicable | OAS Link object | Enables console rendering.
+4+| *Security model:* A declaration of which security mechanisms you can used across the APIs.
+| OAuth 1.0: The API authentication requires using OAuth 1.0 as described in https://tools.ietf.org/html/rfc5849[RFC5849]. | RAML security schemes | Not applicable | Allows advanced searches and enables console rendering.
+| OAuth 2.0: The API authentication requires using OAuth 2.0 as described in https://tools.ietf.org/html/rfc6749[RFC6749]. | RAML security schemes | OAS Security Scheme object | Allows advanced searches and enables console rendering.
+| Basic: The API authentication relies on using Basic Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617]. | RAML security schemes | OAS Security Scheme object | Allows advanced searches and enables console rendering.
+| Digest: The API authentication relies on using Digest Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617] | RAML security schemes | Not applicable | Allows advanced searches and enables console rendering.
+| API Key: The API authentication relies on using API key (either as a header, a cookie parameter, or as a query parameter). | Not applicable | OAS Security Scheme object | Allows advanced searches and enables console rendering.
+| Open ID Connect: The API authentication relies on using OAuth2's common flows (implicit, password, client credentials and authorization code) defined in https://tools.ietf.org/html/draft-ietf-oauth-discovery-06[OpenID Connect Discovery]. | Not applicable | OAS Security Scheme object | Allows advanced searches and enables console rendering.
+| Pass through: Headers or query parameters are passed through to the API based on a defined mapping. | RAML security schemes | Not applicable | Allows advanced searches and enables console rendering.
+| Custom: The API authentication relies on another custom authentication method. | RAML security schemes | OAS Security Scheme object | Allows advanced searches and enables console rendering.
+4+| *Data description and validation:* Validation of any XML or JSON instance against inner elements follows the same restrictions as the validation against a regular XML or JSON schema.
+| JSON schema constraints and support: The level of support or constraints on JSON schemas. This is the base for both. RAML Types is a superset | RAML JSON support | OAS Schema object | Allows advanced searches in the main API document and enables console rendering. Does not support validation of directly uploaded specs.
+| Schema Inheritance: The combining and extending of model definitions by using properties of JSON Schema.| RAML type inheritance | *Simulated with `$allOf`, not proper inheritance, murky situation in OAS Schema* | Allows advanced searches and enables console rendering.
+| Type expressions: Type expressions can be used wherever a type is expected. Using type expressions, you can devise type unions, arrays, maps, and other things.| RAML type expressions | Not applicable |  Allows advanced searches of types in the expression and enables console rendering.
+| XML Schema constraints and support: The level of support or constraints on XML schemas. | RAML XML support provided indirectly through RAML XML facets for RAML types. | Support provided indirectly through XML properties for the `Schema object` | Enables console rendering.
+| Examples: RAML or OAS examples of implementing validations. | RAML examples | OAS `Example object` | Allows advanced searches and enables console rendering.
+| Mandatory valid examples: Required examples that are valid. | Not applicable | Not applicable | Does not support validation of directly uploaded specs.
+4+| *Meta-model extensibility:* Defines the ability to extend the format to describe additional details or objects.
+| Custom property extensions: Extensions and additional details for custom properties. | Annotations | OAS specification extensions | Allows advanced searches and enables console rendering.
+| Custom node extensions: Additional details for custom node extensions. | Complex annotations | Not applicable | Allows advanced searches and enables console rendering.
+| Extensions schema: Additional details about extension schemas | Annotations can have a schema and can be validated |Not applicable | Allows advanced searches and enables console rendering.
+| Extensions semantics: Semantics to be used for defining extensions. |  Not applicable | Not applicable | Not applicable
+|===
diff --git a/modules/ROOT/pages/api-spec-support-rest-connect.adoc b/modules/ROOT/pages/api-spec-support-rest-connect.adoc
new file mode 100644
index 00000000..362265a5
--- /dev/null
+++ b/modules/ROOT/pages/api-spec-support-rest-connect.adoc
@@ -0,0 +1,58 @@
+= API Specifications Support in REST Connect
+ifndef::env-site,env-github[]
+include::_attributes.adoc[]
+endif::[]
+:keywords: api, instance, manager
+
+You can implement your API specification in a way that best suits your needs. The following table explains how each of the features of the API specification is best implemented and the level of support provided for the specification in REST Connect.
+
+[%header%autowidth.spread,cols="a,a,a,a"]
+|===
+| Feature: Description| RAML Implementation | OAS Implementation | REST Connect Support
+4+| *Modularity:* The ability to break an API specification into reusable and shared units.
+| API Document: The main API specification description metadata, which is the entry point for the specification. | RAML root document | OAS root document | Can Generate a simple connector.
+| Libraries: The unit containing collections of related reusable description elements. | RAML library | Can be implemented using an empty OAS specification containing multiple components. | Not applicable
+| Fragments: Stand-alone component of the specification that describes a specific element. | RAML fragment | Can be implemented using an empty OAS specification containing a single component.| Not applicable
+| Overlays: A partial description of the API specification that you can use to overwrite non-functional aspects of the API specification by composing it with the original specification, for example, translating the documentation to other languages. | RAML overlay | Can be simulated with JSON patch or merge preprocessing. | Connectors can be generated for modified APIs.
+| Extensions: A partial description of the API spec that can be used to overwrite non-functional aspects of the API spec composing it with the original specification, like for example adding the security information for a managed API | RAML extension | Can be simulated with JSON patch or merge preprocessing. | Connectors can be generated for modified APIs.
+4+| *Reusability:* The ability to reuse the API description in multiple specifications.
+| Inline declarations and references: The ability to declare and reference elements from multiple documents. | Inclusion and named references to: datatypes, traits, resource types, and annotations declarations. | JSON reference and OAS components. | Inlines through AMF for connectivity.
+| Traits: Macros that extend operations in the functional model, such as pagination, that can be reused in multiple specifications for consistency | Operation macros and RAML traits | Not applicable | Inlines through AMF for connectivity.
+| Resource types: Macros that extend resources in the functional model with complex behavior and data definition that can be reused in multiple specifications for consistency | Endpoint macros and RAML resource types | Not applicable | Inlines through AMF for connectivity.
+4+| *API Metadata:* Provides metadata about the API that might be used by tooling as required.
+| API Entrypoint: The main entry point for the API description, mostly human-readable information, such as title, version, license, and so forth. | RAML document top level information | OAS Open API object| Not applicable
+| Server and protocols: Denotes the actual connectivity to the service | RAML base URI information | OAS Server object | Provides the value for the connection.
+| Terms of service & licensing: The user agreement and licensing information of the API | Only plain documentation | OAS Info object | Not applicable
+| User documentation: Includes user guide and reference material that clarifies how the API works. | RAML description properties in different parts of the specification | OAS description properties in the specification objects | Not applicable
+| Localized documentation: Specifies multi-lingual descriptions | Using overlays | Not applicable | Not applicable
+| Tags: Classification of parts of the specification | Only use annotations | OAS Tag object | Not applicable
+4+| *Functional model:* A declaration of the resources to use when RPCs are invoked.
+| Endpoints: Refers to the resources and RPC invocations in the API | Because RAML is more RESTful, the RAML resources are more explicit in its working and allows for the nesting of those resources. | OAS Path Item objects under the Paths object | Provides options for connectivity.
+| Methods and bindings to HTTP uniform interface: Includes operations over the resource and information about how to invoke the RPC operation. | Get, Patch, Put, Post, Delete, Options, and head RAML operations | Get, Put, Post, Delete, Options, Head, Patch, Trace and fixed fields under the OAS Path Item object | Provides options for connectivity.
+| Input parameters and HTTP bindings: Specifies the input parameters for the operation. | RAML parameters | OAS Parameter object | Provides options for connectivity.
+| Responses with multiple media types: Specifies the output parameter for the operation. | RAML responses | OAS Response object | Provides options for connectivity.
+| Responses with bindings to HTTP status codes: Specifies the binding to the HTTP status code. | RAML responses | OAS Response object | Provides options for connectivity.
+| Callbacks: Specifies the asynchronous invocations and webhooks. | Not applicable | OAS Callback object | Not applicable
+| Links: Specifies the static connections between endpoints in the specification, excluding hyperlinks in the data. |  Not applicable | OAS Link object | Not applicable
+4+| *Security model:* A declaration of which security mechanisms you can used across the APIs.
+| OAuth 1.0: The API authentication requires using OAuth 1.0 as described in https://tools.ietf.org/html/rfc5849[RFC5849]. | RAML security schemes | Not applicable | Not applicable
+| OAuth 2.0: The API authentication requires using OAuth 2.0 as described in https://tools.ietf.org/html/rfc6749[RFC6749]. | RAML security schemes | OAS Security Scheme object | Supported in connectors.
+| Basic: The API authentication relies on using Basic Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617]. | RAML security schemes | OAS Security Scheme object | Supported in connectors.
+| Digest: The API authentication relies on using Digest Access Authentication as described in https://tools.ietf.org/html/rfc2617[RFC2617] | RAML security schemes | Not applicable |  Supported in connectors.
+| API Key: The API authentication relies on using API key (either as a header, a cookie parameter, or as a query parameter). | Not applicable | OAS Security Scheme object | Not applicable
+| Open ID Connect: The API authentication relies on using OAuth2's common flows (implicit, password, client credentials and authorization code) defined in https://tools.ietf.org/html/draft-ietf-oauth-discovery-06[OpenID Connect Discovery]. | Not applicable | OAS Security Scheme object | Not applicable
+| Pass through: Headers or query parameters are passed through to the API based on a defined mapping. | RAML security schemes | Not applicable | Supported in connectors.
+| Custom: The API authentication relies on another custom authentication method. | RAML security schemes | OAS Security Scheme object | Not applicable
+4+| *Data description and validation:* Validation of any XML or JSON instance against inner elements follows the same restrictions as the validation against a regular XML or JSON schema.
+| JSON schema constraints and support: The level of support or constraints on JSON schemas. This is the base for both. RAML Types is a superset | RAML JSON support | OAS Schema object | Not applicable
+| Schema Inheritance: The combining and extending of model definitions by using properties of JSON Schema.| RAML type inheritance | *Simulated with `$allOf`, not proper inheritance, murky situation in OAS Schema* | Not applicable
+| Type expressions: Type expressions can be used wherever a type is expected. Using type expressions, you can devise type unions, arrays, maps, and other things.| RAML type expressions | Not applicable |  Not applicable
+| XML Schema constraints and support: The level of support or constraints on XML schemas. | RAML XML support provided indirectly through RAML XML facets for RAML types. | Support provided indirectly through XML properties for the `Schema object` | Not applicable
+| Examples: RAML or OAS examples of implementing validations. | RAML examples | OAS `Example object` | Not applicable
+| Mandatory valid examples: Required examples that are valid. | Not applicable | Not applicable | Not applicable
+4+| *Meta-model extensibility:* Defines the ability to extend the format to describe additional details or objects.
+| Custom property extensions: Extensions and additional details for custom properties. | Annotations | OAS specification extensions | Used to customize connectivity details.
+| Custom node extensions: Additional details for custom node extensions. | Complex annotations | Not applicable | Not applicable
+| Extensions schema: Additional details about extension schemas | Annotations can have a schema and can be validated |Not applicable | Not applicable
+| Extensions semantics: Semantics to be used for defining extensions. |  Not applicable | Not applicable | Not applicable
+|===