updated PR comments

Author: SathishKumarHS

fern/docs/pages/references/keyrings/developer_keyring.mdx

@@ -8,10 +8,10 @@ A `snap_in_secret` is a simple way to store any plain text secret your snap_in r
 
 To create a snap-in secret in the UI, go to the snap-in page **Connection** tab and find the `snap_in_secret` keyring type.
 
-To create a snap-in secret with the CLI, ruun the following command:
+To create a snap-in secret with the CLI, run the following command:
 
 ```bash
-echo \"[<SECRET>]\" | devrev developer_keyring create snap-in-secret <KEYRING NAME>
+echo \"<SECRET>\" | devrev developer_keyring create snap-in-secret <KEYRING NAME>
 ```
 
 ## OAuth secrets
@@ -24,7 +24,7 @@ An `oauth_secret` is specifically designed to store OAuth client credentials sec
 To create an OAuth secret with the CLI, run the following command:
 
 ```bash
-echo '{"client_id":"[<CLIENT ID>]","client_secret":"[<CLIENT SECRET>]"}' | devrev developer_keyring create oauth-secret <KEYRING NAME>
+echo '{"client_id":"<CLIENT ID>","client_secret":"<CLIENT SECRET>"}' | devrev developer_keyring create oauth-secret <KEYRING NAME>
 ```
 
 ## Developer keyrings in the snap-in manifest

fern/docs/pages/references/keyrings/introduction.mdx

@@ -10,21 +10,22 @@ Here's where DevRev keyrings come in:
 
 You can define keyrings within your snap-in manifest for each external service you need to connect to.
 During installation, users will be prompted to provide their credentials for each keyring (think of it like securely logging in to each service through your snap-in). These credentials are then stored securely in the keyrings.
-When your snap-in needs to interact with a specific service, it retrieves the necessary credentials from the corresponding keyring instead of your code. This keeps your sensitive information safe and isolated.
+When your snap-in needs to interact with a specific service, it retrieves the necessary credentials from the corresponding keyring (see snap-in resources) instead of your code. This keeps your sensitive information safe and isolated.
 
 Think of keyrings as secure vaults within your snap-in, acting as a middleman between your snap-in and the external services it connects to. This ensures both security and a smooth user experience during installation.
 
 ## Supported credential types
 
 * **OAuth:** Streamline connections with popular services like Slack and Jira using pre-defined OAuth keyrings.
-* **Secrets:** Store various secret configurations, including personal access tokens (PATs) and JSON web tokens (JWTs) for broader service integrations.
+* **Secrets:** Store various secret configurations, including personal access tokens (PATs) and Multi-field Token (JSON) for broader service integrations.
 
 ## Access levels
 
 - **User level:** Securely store credentials specific to individual users, allowing them to connect their own accounts to external services through your snap-in.
 - **Organization level:** Share credentials across your organization for access to a single, shared account for an external service.
 
 ## Syntax
+A syntax for defining keyrings within your snap-in manifest:
 
 ```yaml
 keyrings:

fern/docs/pages/references/keyrings/oauth_config.mdx

@@ -1,4 +1,4 @@
-OAuth (Open Authorization) is a widely adopted standard for authorization that allows users to grant access to their accounts on one service (like Google or GitHub) to another application (like your DevRev snap-in) without needing to share their passwords directly. This approach enhances security and user convenience.
+OAuth 2.0 (Open Authorization) is a widely adopted standard for authorization that allows users to grant access to their accounts on one service (like Google or GitHub) to another application (like your DevRev snap-in) without needing to share their passwords directly. This approach enhances security and user convenience.
 
 For comprehensive information about the OAuth specification, refer to the official documentation: [OAuth 2.0](https://oauth.net/2/).
 
@@ -13,6 +13,12 @@ For comprehensive information about the OAuth specification, refer to the offici
 4. **Access tokens:** Upon successful authorization, the service provides your snap-in with an access token. This token is used to access user data on the service's behalf without requiring the user's password again.
 
 5. **Refreshing tokens:** A key benefit of using keyrings for OAuth is that they can handle refreshing access tokens automatically. Most OAuth implementations issue a refresh token alongside the access token. This refresh token can be used to obtain a new access token before the current one expires.
+    - if refresh_token is not provided, the user will need to re-authorize the connection after the access token expires.
+    - if refresh_token is expires, the user will need to re-authorize the connection after the access token expires.
+
+6. **Revoking tokens:** For enhanced security, you can also configure your keyring to revoke access tokens when they are no longer needed. This ensures that even if a token is compromised, it can't be used to access user data.
+
+7. **Organization data:** Optionally, you can configure your keyring to fetch additional information about the user's organization within the service. This can be useful for snap-ins that need to access organization-wide data.
 
 ### Keywords
 
@@ -45,6 +51,7 @@ keyring_types:
     name: <keyring_type_name>
     description: <keyring_type_description>
     kind: "oauth2"
+    is_subdomain: <true/false> # optional: whether the keyring is a subdomain keyring or not. Default is false. It is used to get the subdomain from the user during creation.
     scopes: # Scopes that the connection can request, add more scopes if needed for your use case. Each scope should have a name, description and value.
       - name: <scope_name>
         description: <scope_description>

fern/docs/pages/references/keyrings/secret_config.mdx

@@ -108,10 +108,10 @@ keyring_types:
     secret_config: # The secret_config section is used to define the fields in the secret.
       secret_transform: <jq query> # example: .field_1 + ":" + .field_2 | @base64
       fields: # optional: data that the user shall provide in the input form when creating the connection. Each element represents one input field. Fields will be included in the final JSON secret. If omitted, the user will be asked for a generic secret.
-        - id: <field_id>
+        - id: <field_id_1>
           name: <field_name>
           description: <field_description>
-        - id: <field_id>
+        - id: <field_id_2>
           name: <field_name>
           description: <field_description>
       token_verification: # The token_verification section is used to verify the token provided by the user.
@@ -122,7 +122,9 @@ keyring_types:
         query_params:
             <param_name>: <param_value> # optional: query parameters to be included in the verification request.
 ```
-The secret_transform field is intended for more advanced scenarios where the secret needs to be transformed before use. For example, it could be used to hash a password before storing it within the keyring. The jq query provided in this field will be applied to the secret data before it is stored.
+
+- The `secret_transform` field is intended for more advanced scenarios where the secret needs to be transformed before use. For example, it could be used to hash a password before storing it within the keyring. The jq query provided in this field will be applied to the secret data before it is stored.
+- The `is_subdomain` field is optional and specifies whether the keyring contains a subdomain. Enabling this field allows the keyring to get the subdomain from the user during creation. This is useful when the keyring requires a subdomain as part of the configuration.
 
 ### Keyring types