Fix as per comments

Author: codeon

fern/docs/pages/references/snap-in-configuration.mdx

@@ -2,8 +2,6 @@
 
 The DevRev snap-ins platform allows developers to define custom configuration pages for their snap-ins. 
 
-## Why Customize Configuration Pages?
-
 While the default configuration page automatically renders input fields for keyrings and inputs, there may be cases where a custom configuration page is more suitable:
 
 - Improved user experience: Developers can design the configuration page to provide a more intuitive and streamlined experience for users setting up the snap-in.
@@ -44,7 +42,7 @@ The `configuration_handler` section in the manifest connects the functions respo
 - `org_snap_in_configuration_handler`: This function processes the organization configuration options. It is triggered when actions are performed on the organization configuration snap-kit.
 - `user_snap_in_configuration_handler`: This function processes the user configuration options. It is triggered when actions are performed on the user configuration snap-kit.
 
-## Configuration Functions
+## Configuration functions
 
 The configuration functions should return a valid snap-kit JSON that defines the layout and elements of the custom configuration page. Here's an example of a snap-kit JSON:
 
@@ -115,9 +113,7 @@ The configuration functions should return a valid snap-kit JSON that defines the
 In this example, the snap-kit renders a dropdown select for choosing between "Ticket" and "Conversation," along with a "Next" button. When the "Next" button is clicked, the `user_snap_in_configuration_handler` function is invoked to process the user's selection.
 In the snap-kit action handler, the `event.payload.action.id` can be used to determine the form being submitted and call the `snap-ins.update` API to update the configuration.
 
-Certainly! Here's the updated documentation in Markdown format:
-
-## Update Snap-in Inputs (BETA)
+## Update snap-in inputs (BETA)
 
 Updates the inputs of a snap-in based on the inputs defined in the snap-in configuration.
 
@@ -151,12 +147,12 @@ In the example above, the `part_picker` and `enum_list_picker` are the input nam
 
 ### Response
 
-#### Success Response
+#### Success response
 
 - Status Code: 200 OK
 - Content-Type: application/json
 
-Response Body:
+Response body:
 ```json
 {
   "data": {},
@@ -165,14 +161,14 @@ Response Body:
 }
 ```
 
-#### Error Response
+#### Error response
 
-If an error occurs while updating the snap-in, the response will have the following format:
+If an error occurs while updating the snap-in, the response has the following format:
 
 - Status Code: 4xx or 5xx
 - Content-Type: application/json
 
-Response Body:
+Response body:
 ```json
 {
   "data": {},

fern/docs/pages/retry-mechanism.mdx

@@ -1,12 +1,21 @@
-# Event Reliability in DevRev Snap-ins
+# Event reliability in DevRev snap-ins
 
 The DevRev snap-ins platform offers event reliability features to ensure smooth and resilient event processing. This document provides an overview of these features and how developers can leverage them to build reliable snap-ins.
 
-## Retryable Errors
+## Getting started
 
-Snap-ins can now define retryable errors using the `FunctionExecutionError` interface provided by the DevRev SDK. This allows the platform to automatically retry events that encounter intermittent or transient errors, improving overall reliability.
+To start using the event reliability features in your Snap-ins, follow these steps:
 
-## Retry Configuration
+1. Update your DevRev SDK to the latest version.
+2. Define retryable errors using the `FunctionExecutionError` interface in your Snap-in code.
+3. Configure the retry behavior in your Snap-in manifest.
+4. Handle errors appropriately in your Snap-in function.
+
+## Retryable errors
+
+Snap-ins can define retryable errors using the `FunctionExecutionError` interface provided by the DevRev SDK. This enables the platform to automatically retry events that encounter intermittent or transient errors, improving overall reliability.
+
+## Retry configuration
 
 Developers can configure the retry behavior of their Snap-in functions using the Snap-in manifest. The following options are available:
 
@@ -22,28 +31,28 @@ functions:
 - `max_retries`: The maximum number of retries before marking the event as failed.
 - `min_interval`: The minimum interval in seconds between each retry attempt. This interval may be adjusted based on the timeout of the corresponding function.
 
-## Error Handling
+## Error handling
 
-The DevRev snap-ins platform handles errors based on the ordering guarantees of the snap-in function.
+The DevRev snap-in platform handles errors based on the ordering guarantees of the snap-in function.
 
-For Snap-in functions with relaxed ordering, non-retryable errors will be marked as failed, and the error will be propagated to the DevRev platform for tracking. Retryable errors will be automatically retried based on the specified retry configuration. If the maximum number of retries is exhausted, the event will be moved to a dead-letter queue (DLQ) for further handling.
+For snap-in functions with relaxed ordering, non-retryable errors are marked as failed, and the errored event is propagated to the DevRev platform for tracking. Retryable errors are automatically retried based on the specified retry configuration. If the maximum number of retries is exhausted, the errored events are moved to a dead-letter queue (DLQ) for further handling.
 
-## Error Interface
+## Error interface
 
 The DevRev SDK defines the `FunctionExecutionError` type to represent errors returned from the snap-in's run function. Developers can use this type to provide additional error details and indicate whether an error is retryable.
 
 ```typescript
 class FunctionExecutionError extends Error {
   /**
    * Toggle to determine if the event should be retried or not. If not set or set to false,
-   * the event will not be retried.
+   * the event is not retried.
    */
   retry: boolean;
 
   /**
    * Whether to retry the event payload with updated metadata
    * that platform provides. Useful when the event payload is
-   * not in a state to be directly processed, and may need new 
+   * not in a state to be directly processed, and may need new
    * keyrings/service account tokens or new inputs.
    */
   refresh?: boolean;
@@ -56,7 +65,7 @@ class FunctionExecutionError extends Error {
 }
 ```
 
-## Example Usage
+## Example usage
 
 Here's an example of how to use the `FunctionExecutionError` in your Snap-in code:
 
@@ -95,15 +104,4 @@ export const run = async (events: any[]) => {
 export default run;
 ```
 
-In this example, the Snap-in function's `run` method processes the events and can throw a `FunctionExecutionError` to indicate whether the error is retryable or not. The Snap-in platform will handle the error based on the `retry` and `refresh` properties set in the error object.
-
-## Getting Started
-
-To start using the event reliability features in your Snap-ins, follow these steps:
-
-1. Update your DevRev SDK to the latest version.
-2. Define retryable errors using the `FunctionExecutionError` interface in your Snap-in code.
-3. Configure the retry behavior in your Snap-in manifest.
-4. Handle errors appropriately in your Snap-in function.
-
-With these updates, your Snap-ins can leverage the enhanced event reliability features provided by the DevRev Snap-ins platform.
+In this example, the Snap-in function's `run` method processes the events and can throw a `FunctionExecutionError` to indicate whether the error is retryable or not. The Snap-in platform handles the error based on the `retry` and `refresh` properties set in the error object.