diff --git a/en/docs/get-started/key-concepts.md b/en/docs/get-started/key-concepts.md
index cc9ab7be50..ac76d15d82 100644
--- a/en/docs/get-started/key-concepts.md
+++ b/en/docs/get-started/key-concepts.md
@@ -4,13 +4,13 @@
 | ---------------------------------- | ------------------------------------------------------------ |
 | <a name="api"></a>API                     | An API (Application Programming Interface) is the fundamental building block of WSO2 API Manager. It is an intermediate layer that acts as a communication protocol between a consumer and a service, simplifying the consumption of the service. In addition to hiding the underlying implementation details of a service, an API provides a secure, controlled, and a well-documented approach for accessing the exposed service. |
 |  <a name="api-format"></a> API Format                         | Open API Specification (OAS, a.k.a Swagger) format is the underneath representation of an API in WSO2 API Manager. A Swagger definition can be used to import an API to the Publisher Portal. In addition, a user can view, edit, import, or download an API definition in OAS format via the API Publisher Portal.   |
-|  <a name="api-resource-path-and-http-methods"></a> API Resource path and HTTP Methods | An API is made up of one or more resources, each of which has a unique resource path (URI). An API Resource has a set of HTTP methods that operates on it.  The supported HTTP methods are: GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS |
+|  <a name="api-resource-path-and-http-methods"></a> API Resource path and HTTP Methods | An API is made up of one or more resources, each of which has a unique resource path (URI). An API Resource has a set of HTTP methods that operate on it.  The supported HTTP methods are: GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS |
 |  <a name="api-lifecycle"></a> API Lifecycle                      | The stages that an API goes through from creation to retirement. APIs have lifecycle stages that are independent of the backend services they rely on. The  lifecycle's states are CREATED, PRE-RELEASED, PUBLISHED, BLOCKED, DEPRECATED, and RETIRED. The life cycles of the APIs are customized based on the needs of an organization. |
 |  <a name="application"></a> Application                        | The logical representation of a physical application such as a mobile app, web app, device, etc. For an application to use an API, the application should subscribe to the relevant APIs it intends to use. A subscription to an API happens over a selected business plan, which determines the usage quota the application gets. An application has a consumer-key and a consumer-secret, which acts as the credentials of the application. |
 |  <a name="api-product"></a> API Product                        | A combination of resources from one or more available APIs. An API product allows API product managers to mix and match resources from the available APIs. Similar to using an API, an application that intends to use an API product needs to subscribe to the APIs under a selected business plan. An application that subscribes to an API product gets access to all of its resources, which belong to one or more of the APIs that are used to create the API product. |
 |  <a name="access-token"></a> Access Token                       | Using OAuth2.0 bearer token-based authentication to allow a consumer to access an API. It is a string that is passed as an HTTP header of an API request. WSO2 API Manager supports JWT-formatted, self-contained access tokens. The opaque token support is available for the applications that are migrated from older versions. |
-|  <a name="api-visibility"></a>  API Visibility                     | API visibility determines who can view the API on the Developer Portal. The available visibility levels are as follows: <ul><li> Public - Visible to all users. </li><li> Restricted by role. - Visible only to the users under the creator's tenant domain who have the relevant roles attached.</li>  <li> Visible to my domain - Visible to all users who are registered to the API creator's tenant domain. This applies only when there is more than 1 tenant in the system.</li></ul> |
-|  <a name="rate-limits"></a> Rate Limits                        | Rate limiting allows you to limit the number of permitted requests to an API within a given time window. Rate limiting can be useful to - <ul><li> Protect your APIs from common types of security attacks such as certain types of  Denial of Service (DoS) attacks. </li><li>Regulate traffic according to infrastructure availability. </li><li>To apply request quotas for monetization purposes of APIs.</li></ul> |
+|  <a name="api-visibility"></a>  API Visibility                     | API visibility determines who can view the API on the Developer Portal. The available visibility levels are as follows: <ul><li> Public - Visible to all users. </li><li> Restricted by role - Visible only to the users under the creator's tenant domain who have the relevant roles attached.</li>  <li> Visible to my domain - Visible to all users who are registered to the API creator's tenant domain. This applies only when there is more than 1 tenant in the system.</li></ul> |
+|  <a name="rate-limits"></a> Rate Limits                        | Rate limiting allows you to limit the number of permitted requests to an API within a given time window. Rate limiting can be useful to: <ul><li> Protect your APIs from common types of security attacks such as certain types of  Denial of Service (DoS) attacks. </li><li>Regulate traffic according to infrastructure availability. </li><li>To apply request quotas for monetization purposes of APIs.</li></ul> |
 |  <a name="workflows"></a> Workflows                          | Allows controlling selected user actions on the API Publisher and the Developer Portal. For example, enabling a human approval process to approve users signing up to the Developer Portal. Workflow plugins can be used creatively for other purposes as well, such as performing custom validations, compliance checks, etc. Its asynchronous nature developed on webhooks allows user actions to be put on hold in order to be completed later. |
 |  <a name="message-mediation-policies"></a> Message Mediation Policies         | Message mediation policies are used to enrich, transform, or modify a request or response message that is being routed via the Universal Gateway. For example, when exposing an XML endpoint as JSON, message mediation policies may be used to convert the message format from XML to JSON and vice versa. These policies can also be used for composing services into APIs and for various other needs such as validations, conformance, etc. |
 |  <a name="handler"></a> Handler                            | A handler allows a message to be processed before passing it to the routing logic of the Universal Gateway. Handlers can be used for security validation, policy enforcement, pushing out events to third party systems, custom logging requirements, etc. A handler allows the processing of both request and response messages. |