diff --git a/docs/reference-docs/api/metadata/creating-task-definitions.md b/docs/reference-docs/api/metadata/creating-task-definitions.md
index a9306a9e..0a5a629e 100644
--- a/docs/reference-docs/api/metadata/creating-task-definitions.md
+++ b/docs/reference-docs/api/metadata/creating-task-definitions.md
@@ -6,29 +6,30 @@ import TabItem from '@theme/TabItem';
# Creating Task Definitions
-Tasks are the building blocks of workflow in Conductor. A task can be an operator, system task, or custom code written in any programming language. This API is used to create task definitions in Orkes Conductor.
+Task definitions register tasks in Conductor. This API is used to create task definitions in Orkes Conductor.
## Input Payload
-You can configure task definitions directly via UI and using API. The task definitions includes the following parameters
-
-| Attribute | Description |
+| Parameter | Description |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| name | Provide a unique identifier for the task. This field is mandatory. |
-| description | A brief description of the task’s purpose. This field is optional. |
-| retryCount | The number of retries to attempt if the task fails. The default value is 3. |
-| retryDelaySeconds | Indicates the time (in seconds) to wait before each retry occurs. The default value is 60. |
-| retryLogic | Indicates the mechanism for the retries. It can take any of the following values:- **FIXED** - Retries occur based on the _retryDelaySeconds_ interval.
- **LINEAR_BACKOFF** - Retries occur with a delay that increases linearly based on the backoff rate and attempt number.
- **EXPONENTIAL_BACKOFF** - Retries occur with a delay that doubles each time, calculated as retryDelaySeconds*2^(retryCount)
|
-| timeOutSeconds | Time (in seconds), after which the task is marked as **TIMED_OUT** if not completed after transitioning to **IN_PROGRESS** status for the first time. No timeout occurs if the value is set to 0. |
-| pollTimeoutSeconds | Time (in seconds), after which the task is marked as **TIMED_OUT** if not polled by a worker. No timeout occurs if the value is set to 0. |
-| timeoutPolicy | Indicates the condition at which the task should time out. It can take any of the following values:- **RETRY** - Retries the task again.
- **TIME_OUT_WF** - The status of the task is marked as TIMEOUT and the task is terminated.
- **ALERT_ONLY** - Registers a counter.
**Note:** To create a task that never times out, set *timeoutSeconds* and *pollTimeoutSeconds* to 0. |
-| responseTimeoutSeconds | Time (in seconds) to wait before rescheduling the task if its status is not updated. The default value is 600. |
+| name | A unique identifier for the task. This field is mandatory. |
+| description | A brief description of the task. This field is optional. |
+| retryCount | The number of retries to attempt when a task fails. The default value is 3. |
+| retryDelaySeconds | The time (in seconds) to wait before each retry occurs. The default value is 60. |
+| retryLogic | The mechanism for the retries. It can take the following values:- **FIXED** - Retries occur based on the _retryDelaySeconds_.
- **LINEAR_BACKOFF** - Retries occur with a delay that increases linearly based on the backoff rate and attempt number. ( _retryDelaySeconds x backoffRate x attemptNumber_)
- **EXPONENTIAL_BACKOFF** - Retries occur with a delay that doubles each time, calculated as retryDelaySeconds*2^(attemptNumber)
|
+| timeOutSeconds | Time (in seconds), after which the task is marked as **TIMED_OUT** if it has not reached a terminal state after transitioning to **IN_PROGRESS** status for the first time. No timeout occurs if the value is set to 0. |
+| pollTimeoutSeconds | Time (in seconds), after which the task is marked as **TIMED_OUT** if not polled by a worker. No timeout occurs if the value is set to 0. |
+| timeoutPolicy | The condition at which the task should time out. It can take the following values:- **RETRY** - Retries the task again.
- **TIME_OUT_WF** - The workflow is marked as TIMED_OUT and terminated.
- **ALERT_ONLY** - Registers a counter.
To create a task that never times out, set *timeoutSeconds* and *pollTimeoutSeconds* to 0. |
+| responseTimeoutSeconds | Time (in seconds) to wait before rescheduling the task if its status is not updated within this period. The default value is 600. |
| inputKeys | An array of keys representing the expected input for the task. |
| outputKeys | An array of keys representing the expected output from the task. |
-| inputTemplate | Input templates are defined as part of task definitions. It acts as default input to the task while adding to the workflow. It can be overridden by values provided in workflow definitions.
**Note**: You cannot view the input templates in the workflow definition JSON code as they are part of only task definitions. However, when clicking the task, you can [view the input templates supplied from the UI](http://localhost:3000/content/developer-guides/passing-inputs-to-task-in-conductor#task-input-templates).|
-| concurrentExecLimit | The maximum number of tasks that can be executed simultaneously.
For example, if you have 1000 task executions waiting in the queue and 1000 workers polling this queue for tasks, but if you have set *concurrentExecLimit* to 10, only ten tasks would be given to workers (which would lead to starvation). If any of the workers finish execution, a new task(s) will be removed from the queue while still keeping the current execution count to 10. |
+| inputTemplate | Input templates are defined as part of task definitions. It acts as default input to the task while adding to the workflow. It can be overridden by values provided in workflow definitions.
**Note**: You cannot view the input templates in the workflow definition JSON as they are part of only task definitions. However, when clicking the task, you can [view the input templates supplied from the UI](https://orkes.io/content/developer-guides/passing-inputs-to-task-in-conductor#task-input-templates).|
+| concurrentExecLimit | The number of tasks that can be executed at any given time.
For example, if you have 1000 task executions waiting in the queue and 1000 workers polling this queue for tasks, but if you have set _concurrentExecLimit_ to 10, only 10 tasks would be given to workers (which would lead to starvation). If any of the workers finish execution, a new task(s) will be removed from the queue while still keeping the current execution count to 10. |
| backOffScaleFactor | The value to be multiplied with retryDelaySeconds in order to determine the interval for retry. |
-| rateLimitFrequencyInSeconds, rateLimitPerFrequency | - **rateLimitFrequencyInSeconds** sets the frequency window, which is the duration to be used in events per duration.
- **rateLimitPerFrequency** defines the number of tasks that can be given to workers per given frequency window.
**Note**: Rate limiting is only supported for the Redis persistence module and is unavailable with other persistence layers.
For example, let’s set **rateLimitFrequencyInSeconds=5**, and **rateLimitPerFrequency=12**. This means our frequency window is 5 seconds in duration, and for each frequency window, the Conductor would only give 12 tasks to workers. So, in a given minute, the Conductor would only give 12*(60/5) = 144 tasks to workers, irrespective of the number of workers polling for the task.
Unlike **concurrentExecLimit**, rate limiting doesn't consider the tasks already in progress/completed. Even if all the previous tasks are executed within 1 sec or would take a few days, the new tasks are still given to workers at configured frequency, 144 tasks per minute in the above example. |
+| rateLimitFrequencyInSeconds, rateLimitPerFrequency | - **rateLimitFrequencyInSeconds** sets the frequency window, which is the _duration_ to be used in events per duration.
- **rateLimitPerFrequency** defines the number of tasks that can be given to workers per given frequency window.
Rate limiting is only supported for the Redis persistence module and is unavailable with other persistence layers.
For example, let’s set **rateLimitFrequencyInSeconds=5**, and **rateLimitPerFrequency=12**. This means our frequency window is 5 seconds in duration, and for each frequency window, the Conductor would only give 12 tasks to workers. So, in a given minute, the Conductor would only give 12*(60/5) = 144 tasks to workers, irrespective of the number of workers polling for the task.
Unlike **concurrentExecLimit**, rate limiting doesn't consider the tasks already in progress or a terminal state. Even if all the previous tasks are executed within 1 sec or would take a few days, the new tasks are still given to workers at configured frequency, 144 tasks per minute in the above example. |
+| enforceSchema | Set to `true` to enforce task inputs/outputs for all instances of the task. By default, the value is set to `false`. |
+| inputSchema | If _enforceSchema_ is set to `true`, select a schema (and version) to be used as input schema for the task definition. Learn more about [creating and using schema](https://orkes.io/content/developer-guides/schema-validation). |
+| outputSchema | If _enforceSchema_ is set to `true`, select a schema (and version) to be used as output schema for the task definition. Learn more about [creating and using schema](https://orkes.io/content/developer-guides/schema-validation). |
| ownerEmail | This field will be auto-populated with the user's email address. |
## API Endpoint