updating keyring documentation

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

@@ -0,0 +1,47 @@
+Developer Keyrings - For Development Workflows
+
+While the previous pages focused on keyrings used to store user or organization credentials, DevRev also offers a special type called developer keyrings. These keyrings cater specifically to developers during the creation process.
+
+* Unlike other keyrings that store user credentials, developer keyrings are designed to hold sensitive information needed by the developer during development and execution of any particular task.
+* These secrets are provided by you, the developer, during the creation of a snap_in version. They are not exposed to users and are stored separately from the snap_in itself.
+
+**Types of Developer Keyrings:**
+
+* **snap_in_secret:** This is a simple way to store any plain text secret your snap_in requires. It's ideal for sensitive information that doesn't require complex formatting.
+* **oauth_secret:** This type of keyring is specifically designed to store OAuth client credentials securely. It allows you to define two separate fields:
+  * client_id: The client ID provided by the OAuth provider.
+  * client_secret: The client secret provided by the OAuth provider.
+
+Creating a Developer Keyring
+
+To create a developer keyring, follow these steps:
+
+1. creating a keyring type of snap_in_secret:
+   * Using the UI:
+     Navigate to the Snap-in page, click on the connection tab, and then find the snap_in_secret keyring type.
+   * Using the CLI:
+     Run the following command:
+     ```bash
+     echo \"[SECRET]\" | devrev developer_keyring create snap-in-secret <name of the keyring>
+     ```
+2. creating a keyring type of oauth_secret:
+    * Using the CLI:
+      Run the following command:
+      ```bash
+      echo '{"client_id":"[CLIENT_ID]","client_secret":"[CLIENT_SECRET]"}' | devrev developer_keyring create oauth-secret <NAME>
+      ```
+Once you've created the keyring, you can use it in your snap_in by referencing the keyring name in the snap_in manifest file.
+
+**Declaring Developer Keyrings in the Snap-in Manifest:**
+
+This section explains how to declare a developer keyring in your snap-in manifest. Developer keyrings provide a secure way to store sensitive information needed by your snap-in, such as OAuth client credentials.
+
+Syntax:
+```yaml
+  developer_keyrings:
+    - name: <name of the keyring>
+      description: <description of the keyring>
+      display_name: <display name of the keyring>
+```
+
+When creating a new `snap_in_version` using the developer tools, you will be prompted to provide the values for the declared developer keyrings. This ensures that the sensitive information is securely stored and accessible to your snap-in at runtime.

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

@@ -0,0 +1,50 @@
+**Keyrings: Securely Connecting Your Snap-in to External Services**
+
+Keyrings provide a secure way to manage credentials for external services used within your DevRev snap-in. This eliminates the need to store sensitive information like passwords or access tokens directly in your code or configuration files, improving overall security.
+
+**Why are Keyrings Important?**
+
+Traditionally, developers might store these credentials directly in their snap-in's code. This poses a significant security risk. If someone gains access to your code, they could also steal these sensitive credentials.
+Keyrings provide a secure alternative. By storing credentials separately from your code, you ensure they remain hidden and inaccessible even if the code is compromised. This strengthens the overall security of your snap-in.
+
+
+
+**How Keyrings Work**
+
+Imagine you're building a DevRev snap-in that helps manage your marketing campaigns across different platforms. This snap-in might need to connect to various external services like Facebook Ads, Mailchimp, and a project management tool like Asana.
+Traditionally, you might embed the API keys or access tokens for these services directly in your snap-in's code. This poses a security risk because anyone with access to the code could potentially steal these credentials.
+
+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.
+
+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 (PATs, JSON):** Store various secret configurations, including Personal Access Tokens (PATs) and JSON Web Tokens (JWTs) 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:**
+```yaml
+keyrings:
+  organization:
+    - name: <name of the keyring>
+      display_name: <display name of the keyring>
+      description: <description of the keyring>
+      types:
+        - <id of the keyring type>
+  user:
+    - name: <name of the keyring>
+      display_name: <display name of the keyring>
+      description: <description of the keyring>
+      types:
+        - <id of the keyring type>
+```