microcks · pratik-mahalle · Jan 26, 2026
diff --git a/content/documentation/explanations/dispatching.md b/content/documentation/explanations/dispatching.md
@@ -39,7 +39,7 @@ Below are some explanations on these dispatchers and associated dispatching rule
 Changing `Dispatching Rules` or even the `Dispatcher` can be done by different ways:
 * Via the web UI, selecting `Edit Properties` of the operation from the 3-dots menu on the right of the operation name. You should be logged as a repository `manager` to have this option (see [Managing Users](/documentation/guides/administration/users) how-to guide if needed),
 * Via [Microcks' owns API](/documentation/references/apis/open-api) after being [connected to Microcks API](/documentation/guides/automation/api),
-* Via an additional [API Metadata](/documentation/references/metadada) artifact that allow this customization,
+* Via an additional [API Metadata](/documentation/references/metadata) artifact that allow this customization,
 * Via Microcks [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) or [AsyncAPI extensions](/documentation/references/artifacts/asyncapi-conventions/#asyncapi-extensions) that allow this customization as well.
 
 ## Advanced dispatchers and rules

diff --git a/content/documentation/explanations/multi-artifacts.md b/content/documentation/explanations/multi-artifacts.md
@@ -35,7 +35,7 @@ Also, note that multiple artifacts for one API definition don't necessarily invo
 
 {{< image src="images/documentation/artifacts-merging-overlay.png" alt="image" zoomable="true" >}}
 
-One specific case of the merging process - that can be used in combination with any other artifact as a `primary` one - relates to the [Microcks APIMetadata](/documentation/references/metadada) format. When importing such artifacts as secondary ones, the merging process involves the metadata of the API or Service and not the examples or tests, as illustrated below:
+One specific case of the merging process - that can be used in combination with any other artifact as a `primary` one - relates to the [Microcks APIMetadata](/documentation/references/metadata) format. When importing such artifacts as secondary ones, the merging process involves the metadata of the API or Service and not the examples or tests, as illustrated below:
 
 {{< image src="images/documentation/artifacts-merging-metadata.png" alt="image" zoomable="true" >}}
 

diff --git a/content/documentation/guides/administration/organizing-repository.md b/content/documentation/guides/administration/organizing-repository.md
@@ -97,7 +97,7 @@ As an administrator of the Microcks instance, you can now assign users to differ
 
 ## Wrap-up
 
-Walking through this guide, you have learned the different means available for organizing your API & Services repository thanks to `labels` 🏷️. It's important to note that labels are saved into Microcks' database and not replaced by a new import of your Service or API definition. They can be independently set and updated using the [Microcks APIs](/documentation/references/apis/open-api), [Microcks Metadata](/documentation/references/metadada), [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) or [AsyncAPI extensions](/documentation/references/artifacts/asyncapi-conventions/#asyncapi-extensions).
+Walking through this guide, you have learned the different means available for organizing your API & Services repository thanks to `labels` 🏷️. It's important to note that labels are saved into Microcks' database and not replaced by a new import of your Service or API definition. They can be independently set and updated using the [Microcks APIs](/documentation/references/apis/open-api), [Microcks Metadata](/documentation/references/metadata), [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) or [AsyncAPI extensions](/documentation/references/artifacts/asyncapi-conventions/#asyncapi-extensions).
 
 You may follow up this guide with the one related to [Managing Users](/documentation/guides/administration/users) or [Snapshotting/restoring your Repository](/documentation/guides/administration/snapshots)
 
diff --git a/content/documentation/guides/troubleshoot/_index.md b/content/documentation/guides/troubleshoot/_index.md
@@ -15,7 +15,7 @@ Changing the log level depends on the way you installed Microcks.
 <details>
   <summary><strong>Helm Chart</strong></summary>
 
-When using the [Helm Chart](/documentation/references/configuration/helm-chart-config/) to deploy Microcks, there's a `microcks.logLevel`spec property you can set to `DEBUG`. Change it into your `values.yaml` file or as a command line argument using `--set microcks.logLevel=DEBUG` when redeploying the chart. This property changes both values for the main webapp and Async Miniong components.
+When using the [Helm Chart](/documentation/references/configuration/helm-chart-config/) to deploy Microcks, there's a `microcks.logLevel`spec property you can set to `DEBUG`. Change it into your `values.yaml` file or as a command line argument using `--set microcks.logLevel=DEBUG` when redeploying the chart. This property changes both values for the main webapp and Async Minion components.
 </details>
 
 <details>
@@ -45,7 +45,7 @@ After the next operator reconciliation, the log level is changed in both the mai
 
 When using [Docker or Podman Compose](/documentation/guides/installation/docker-compose/) for running Microcks, you just have to add additional environment variables to the `microcks` and `microcks-async-minoin` containers. 
 
-You just have to edit the `docker-compose.yml` file to uncomment/enable the correct environement variables:
+You just have to edit the `docker-compose.yml` file to uncomment/enable the correct environment variables:
 
 ```yaml
   app:

diff --git a/content/documentation/guides/usage/custom-dispatchers.md b/content/documentation/guides/usage/custom-dispatchers.md
@@ -135,7 +135,7 @@ operations:
       }
 ```
 
-Import this as a secondary artifact (via Importers or Upload). It will set or overwrite the dispatcher for the target operation. See [API Metadata Format](/documentation/references/metadada/#api-metadata-properties).
+Import this as a secondary artifact (via Importers or Upload). It will set or overwrite the dispatcher for the target operation. See [API Metadata Format](/documentation/references/metadata/#api-metadata-properties).
 
 ### 3.3 Using the Microcks API
 
@@ -163,5 +163,5 @@ Next steps and related topics:
 
 - **Learn more about strategies**: [Dispatcher & dispatching rules](/documentation/explanations/dispatching)
 - **Keep it in your artifact**: [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions)
-- **Manage separately**: [API Metadata](/documentation/references/metadada)
+- **Manage separately**: [API Metadata](/documentation/references/metadata)
 - **See similar guides**: [Importing Services & APIs](/documentation/guides/usage/importing-content) · [Defining delays for mocks](/documentation/guides/usage/delays)
diff --git a/content/documentation/guides/usage/delays.md b/content/documentation/guides/usage/delays.md
@@ -87,7 +87,7 @@ So cool! 🙌 You have now defined a per-request delay that will change with the
 
 Defining the **Default delay** view in the Microcks UI can be cumbersome. You have plenty of other ways to do so:
 * Using our [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) if you're dealing with REST APIs,
-* Using an additional [APIMetadata artifact](/documentation/references/metadada/#api-metadata-properties) if you don't want this information to be mixed with your API definition or if you're dealing with GraphQL or gRPC services,
+* Using an additional [APIMetadata artifact](/documentation/references/metadata/#api-metadata-properties) if you don't want this information to be mixed with your API definition or if you're dealing with GraphQL or gRPC services,
 * Via the [Microcks API](/documentation/references/apis/open-api/) using the `PUT /services/{id}/operation` directly.
 
 ## Wrap-up

diff --git a/content/documentation/references/artifacts/grpc-conventions.md b/content/documentation/references/artifacts/grpc-conventions.md
@@ -99,6 +99,6 @@ The next step is now to create a bunch of examples for each of the requests/oper
 
 If the default inferred dispatchers don't match with your use-case, you'll need an additional step for assembling data coming from gRPC Protofile and Postman Collection is to define how to dispatch requests. For gRPC, your can typically use a `JSON_BODY` or a `SCRIPT` dispatcher as mentionned above.
 
-You can use a [Metadata artifact](/documentation/references/metadada) for that or directly edit the dispatcher in the Web UI. Here-after we have defined a simple rule that is routing incoming requests depending on the value of the `firstname` property of the incoming message.
+You can use a [Metadata artifact](/documentation/references/metadata) for that or directly edit the dispatcher in the Web UI. Here-after we have defined a simple rule that is routing incoming requests depending on the value of the `firstname` property of the incoming message.
 
 {{< image src="images/documentation/grpc-dispatch-rule.png" alt="image" zoomable="true" >}}
diff --git a/content/documentation/references/container-images.md b/content/documentation/references/container-images.md
@@ -20,7 +20,7 @@ Microcks images repositories are primilarly located on <img src="https://quay.io
 
 ## Container images
 
-Here is below the list of available container images. For more information on their role in the archutecture, you may check the [Architecture & deployment options](/documentation/explanations/deployment-options) explanations.
+Here is below the list of available container images. For more information on their role in the architecture, you may check the [Architecture & deployment options](/documentation/explanations/deployment-options) explanations.
 
 ### Microcks App
 

diff --git a/content/documentation/references/metadada.md → content/documentation/references/metadata.md b/content/documentation/references/metadada.md → content/documentation/references/metadata.md
diff --git a/content/documentation/tutorials/getting-started.md b/content/documentation/tutorials/getting-started.md
@@ -11,7 +11,7 @@ weight: 1
 
 In this tutorial, you will discover Microcks mocking features by re-using a simple REST API sample. For that: you will run Microcks on your local machine, then load a sample provided by the Microcks team, explore the web user interface and then interact with an API mock.
 
-The easiest way to get started with Microcks is using [Docker](https://docs.docker.com/get-docker/) or [Podman](https://podman.io/) with our ephemral all-in-one Microcks distribution. 
+The easiest way to get started with Microcks is using [Docker](https://docs.docker.com/get-docker/) or [Podman](https://podman.io/) with our ephemeral all-in-one Microcks distribution. 
 
 In your terminal issue the following command - maybe replacing `8585` by another port of your choice if this one is not free: