@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/sso/sign-in-consent.mdx

@@ -0,0 +1,59 @@
+---
+title: Sign-in Consent
+description: >-
+  Learn about the sign-in consent screen, an extra layer of protection against
+  login CSRF attacks and phishing attempts.
+originalPath: .tmp-workos-clone/packages/docs/content/sso/sign-in-consent.mdx
+---
+
+The sign-in consent screen is an extra layer of protection against login CSRF attacks or phishing attempts.
+
+A user may click a link that appears legitimate, but which unknowingly leads them to signing in through a malicious identity provider controlled by an attacker. The sign-in consent screen mitigates this risk by displaying the user's email and the identity provider's domain, ensuring the user is aware of how they are signing in to the application.
+
+## How it works
+
+The sign-in consent screen is an interstitial page that appears during the Single Sign-on flow, after the user has gone through the identity provider (IdP), before redirecting to the application.
+
+![Sign-in consent screen](https://images.workoscdn.com/images/32760d6d-eb42-480f-92bc-fe6d2e8709ea.png?auto=format&fit=clip&q=80)
+
+This page displays to the user the `email` returned from the IdP, as well as the IdP origin. With this information, the user must either consent to or deny the sign-in flow.
+
+- **Consenting sign-in** leads to completing the SSO flow, where the authorization code is forwarded to the application callback.
+- **Denying the sign-in** will result in an SSO session failure and the user will be redirected to the application callback with a `signin_consent_denied` error.
+
+## Enabling sign-in consent
+
+In order to activate the sign-in consent protection, you should go to the **Authentication** section and enable the sign-in consent checkbox in the Single Sign-On settings.
+
+![Enable sign-in consent checkbox](https://images.workoscdn.com/images/0ab5bb9f-6acb-45d0-a351-468a7e57a428.png?auto=format&fit=clip&q=80)
+
+## Handling the `signin_consent_denied` error
+
+We recommend using the `signin_consent_denied` error code to display useful information to the user, so that they can contact their admin and your support team for information about a possible phishing attempt.
+
+When a user denies the sign-in consent, your application's callback will receive an error response:
+
+```url title="Redirect URI with signin_consent_denied error"
+https://your-app.com/callback?error=signin_consent_denied&error_description=User%20cancelled%20the%20authentication%20request&state=123456789
+```
+
+For more information about error handling, see the [Get Authorization URL error codes](/reference/sso/get-authorization-url/error-codes) documentation.
+
+## When sign-in consent is displayed
+
+WorkOS determines whether the sign-in consent screen should be displayed, based on the identity provider, user fingerprint, and SSO flow parameters.
+
+Once a user accepts the sign-in consent screen, the system remembers this approval and avoids displaying the page again for a better user experience.
+
+The sign-in consent screen is always displayed in the following scenarios:
+
+- **IdP-initiated flows**: The sign-in consent screen is always displayed for IdP-initiated flows (i.e. users clicking on a tile in their IdP), regardless of the identity provider, if the user has not previously approved it.
+- **Custom SAML or OIDC connections**: The sign-in consent screen is displayed for custom connections if the user has not previously approved sign-in consent.
+
+## Branding
+
+The sign-in consent screen automatically inherits the Admin Portal branding and is served through your custom authentication API domain, if available. If you have AuthKit enabled, the sign-in consent screen will follow your AuthKit branding instead. Ensure you review the primary button color and logos before enabling this feature. This ensures a trusted experience for your customers.
+
+## Availability
+
+The sign-in consent screen is available for both AuthKit and Standalone SSO users. It is enabled by default for new environments.

package/.docs/organized/docs/sso/signing-certificates.mdx

@@ -22,7 +22,7 @@ When the IdP sends a SAML response, the SP must verify the authenticity of the r
 
 Consider the fictional SaaS company _HireOS_, which offers recruiting software to other businesses. _HireOS_ is an online application that allows its customers to track leads, candidates, and interviews. _HireOS_ is referred to as the SP by SAML.
 
-Now let’s consider _HireOS_’ newest enterprise customer: _Enterprise Corp_. _Enterprise Corp_ is a large enterprise company that wants to use _HireOS_ to manage their recruiting. _Enterprise Corp_ IT Admins need recruiters and other employees who will use _HireOS_ to log in using _Enterprise Corp_'s identity provider, Okta. Okta is one of many companies known as an IdP to SAML.
+Now let’s consider _HireOS_’ newest enterprise customer: _Enterprise Corp_. _Enterprise Corp_ is a large enterprise company that wants to use _HireOS_ to manage their recruiting. _Enterprise Corp_ IT admins need recruiters and other employees who will use _HireOS_ to log in using _Enterprise Corp_'s identity provider, Okta. Okta is one of many companies known as an IdP to SAML.
 
 ### Verifying the SAML response
 
@@ -52,7 +52,7 @@ To facilitate certificate renewal, WorKOS offers the ability to renew SAML certi
 
 Alternatively, you are also able to filter connections that have either expired or expiring connections directly from the Organization page's filters.
 
-![Organization page expired filter](https://images.workoscdn.com/images/9605a48f-bc2f-42b8-b1f5-eb0e5a014198.png?auto=format&fit=clip&q=50)
+![Organization page expired filter](https://images.workoscdn.com/images/f306979d-ab49-4c2a-832c-895d16a86041.png?auto=format&fit=clip&q=50)
 
 From the Connection page you can generate an Admin Portal link that WorkOS can email directly to the IT admin. By entering the IT admins' email address, WorkOS will email them with a certificate
 renewal Admin Portal link, and they will be notified about future
@@ -60,13 +60,13 @@ expiring certificates. Alternatively, you can copy the link and share it with th
 
 ![Connection page for an expiring certificate](https://images.workoscdn.com/images/c7896f7f-fcde-4440-9f66-8f3dc8445568.png?auto=format&fit=clip&q=50)
 
-The IT Admin will be guided to a step by step flow to renew their certificate; the exact steps will vary based on the IdP.
+The IT admin will be guided to a step by step flow to renew their certificate; the exact steps will vary based on the IdP.
 
-![IT Admin flow for Entra ID](https://images.workoscdn.com/images/2c8334f2-3784-4e7d-8ba9-f4896da336cb.png?auto=format&fit=clip&q=50)
+![IT admin flow for Entra ID](https://images.workoscdn.com/images/2c8334f2-3784-4e7d-8ba9-f4896da336cb.png?auto=format&fit=clip&q=50)
 
 ### Monitored metadata
 
-To streamline this process, you can instead choose to upload a metadata URL to WorkOS that we will automatically keep updated as metadata changes. If your customer's IdP refreshes a certificate, WorkOS will automatically pull in the updated metadata. Your customer can upload a metadata URL to the Admin Portal during setup. Alternatively, they can provide it to your to manually upload via the Dashboard.
+To streamline this process, you can instead choose to upload a metadata URL to WorkOS that we will automatically keep updated as metadata changes. If your customer's IdP refreshes a certificate, WorkOS will automatically pull in the updated metadata. Your customer can upload a metadata URL to the Admin Portal during setup. Alternatively, they can provide it to you to manually upload via the Dashboard.
 
 ![WorkOS Dashboard UI configuring a connection's metadata URL](https://images.workoscdn.com/images/6407b054-9f84-45cf-81bd-35c25b7af0b5.png?auto=format&fit=clip&q=90)
 
@@ -86,7 +86,7 @@ When the SP sends a SAML request, the IdP must verify that the request is actual
 
 Once again, let’s consider the fictional SaaS company _HireOS_, which offers recruiting software to other businesses. _HireOS_ is referred to as the SP by SAML.
 
-_HireOS_’ newest enterprise customer is called _Enterprise Corp_. _Enterprise Corp_ IT Admins need recruiters and other employees who will use _HireOS_ to log in using _Enterprise Corp_'s identity provider, Okta. Okta is one of many companies known as an IdP to SAML.
+_HireOS_’ newest enterprise customer is called _Enterprise Corp_. _Enterprise Corp_ IT admins need recruiters and other employees who will use _HireOS_ to log in using _Enterprise Corp_'s identity provider, Okta. Okta is one of many companies known as an IdP to SAML.
 
 ### Verifying the SAML request
 
@@ -118,4 +118,4 @@ Your customer can manually download the SP metadata document from the URL, extra
 
 ## Implementing SSO with WorkOS
 
-This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [User Management](/user-management), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
+This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.

package/.docs/organized/docs/sso/single-logout.mdx

@@ -1,7 +1,6 @@
 ---
 title: Single Logout
 description: Learn how to implement Single Logout with WorkOS
-featureFlag: single-logout-docs
 originalPath: .tmp-workos-clone/packages/docs/content/sso/single-logout.mdx
 ---
 

package/.docs/organized/docs/sso/ux/sessions.mdx

@@ -0,0 +1,99 @@
+---
+title: SSO Session Lifecycle
+description: Understanding SSO session statuses and their meaning.
+originalPath: .tmp-workos-clone/packages/docs/content/sso/ux/sessions.mdx
+---
+
+## Introduction
+
+WorkOS creates a session to track each Single Sign-On (SSO) authentication flow. Sessions can originate from different sources depending on how the flow is initiated:
+
+- **Service Provider (SP)**: Your application initiates the flow by redirecting users to WorkOS.
+- **Identity Provider (IdP)**: The IdP initiates the flow, sending users directly to WorkOS. This applies only to SAML connections. OIDC connections are always SP-initiated.
+- **Admin Portal**: Test sessions are initiated through the WorkOS Admin Portal to verify SSO configuration.
+
+As the user interacts with the IdP and the authentication progresses, the session transitions through various statuses. Understanding these statuses helps you monitor authentication activity and troubleshoot issues in your SSO implementation.
+
+## Session Statuses
+
+### In progress
+
+A session is marked as <Badge color="gray" size="2"><Spinner size="1" /> In progress</Badge> when the authentication flow has been initiated but not yet completed. This status indicates that the user is currently interacting with the IdP or that the authorization code exchange is pending.
+
+Sessions in this state are waiting for one or more of the following:
+
+- The user to complete authentication at the IdP
+- The IdP to send a response back to WorkOS
+- Your application to exchange the authorization code for tokens
+
+### Success
+
+A session is marked as <Badge color="green" size="2">Success</Badge> when the entire authentication flow completes successfully. This means:
+
+- The IdP authenticated the user
+- WorkOS validated the IdP response
+- Your application exchanged the authorization code for tokens
+- User profile data was successfully retrieved
+
+### Failed
+
+A session is marked as <Badge color="red" size="2">Failed</Badge> when the authentication flow encounters an error. Common causes include:
+
+- Invalid or expired certificates
+- Invalid or malformed IdP response
+- Profile attribute mapping misconfiguration
+- Profile attribute validation errors
+- CSRF token validation failure
+- User denied access at the IdP
+- IdP returned an authentication error
+
+When a session fails, you can view the error details in the WorkOS Dashboard to understand what went wrong.
+
+### Timed out
+
+A session is marked as <Badge color="yellow" size="2">Timed out</Badge> when it remains in the "In progress" state for too long without completing. By default, sessions time out after 5 minutes.
+
+Timeouts typically occur when:
+
+- The user abandons the authentication flow at the IdP
+- The user closes their browser before completing authentication
+- Network issues prevent the IdP response from reaching WorkOS
+
+## Test Sessions
+
+When testing SSO connections through the Admin Portal, sessions are tracked with special test statuses:
+
+### Test successful
+
+A test session is marked as <Badge color="green" size="2">Test successful</Badge> when the IdP response is received and validated. This confirms that the SSO connection is properly configured and the IdP is sending valid responses.
+
+### Test failed
+
+A test session is marked as <Badge color="red" size="2">Test failed</Badge> when validation errors occur during the test. This helps identify configuration issues before rolling out SSO to your users.
+
+Test sessions are not subject to the standard timeout behavior, allowing you to take your time when verifying your SSO configuration.
+
+## Tracking SSO sessions
+
+You can track SSO sessions in the WorkOS Dashboard by navigating to the Organization → Connection detail page and clicking on the "Sessions" tab.
+
+The Sessions section displays a list of sessions from up to 90 days back and can be filtered by session ID, profile email, status, origin, and timestamp.
+
+![A screenshot showing the WorkOS Dashboard SSO screen and how to navigate to the "Sessions" tab.](https://images.workoscdn.com/images/b3f5bcb4-cc92-4753-a467-49e3eeff941f.png)
+
+Click on a session in the list to see session details, such as the request made to the IdP and the response.
+
+![A screenshot showing the "Session Details" within the WorkOS Dashboard SSO screen.](https://images.workoscdn.com/images/b4c4e900-9fbb-43a0-96fb-d3ec3f453e87.png?auto=format&fit=clip&q=50)
+
+## Monitoring SSO sessions with events
+
+You can monitor SSO sessions by subscribing to the `authentication.sso_*` events. Here's the list of events available:
+
+- `authentication.sso_started`: Emitted when a new SSO session is started.
+- `authentication.sso_succeeded`: Emitted when an SSO session is completed successfully.
+- `authentication.sso_failed`: Emitted when an SSO session fails.
+- `authentication.sso_timed_out`: Emitted when an SSO session times out.
+
+These events can be streamed to Datadog for observability and alerting.
+
+Check the [Stream events to Datadog](/events/observability/datadog) documentation for more details on how to stream events to Datadog and refer to the [events](/events/authentication) documentation for more details on each event and its payload.

package/.docs/organized/docs/sso/ux/sign-in.mdx

@@ -19,7 +19,7 @@ Throughout this guide, let’s consider the following scenario:
 
 ### Implementing SSO with WorkOS
 
-This document offers guidance on UX best practices when integrating SSO with the standalone API. You might instead consider [WorkOS User Management](/user-management) with AuthKit, a complete authentication platform which handles all of the UX complexity for you.
+This document offers guidance on UX best practices when integrating SSO with the standalone API. You might instead consider [WorkOS AuthKit](/authkit), a complete authentication platform which handles all of the UX complexity for you.
 
 ## Separate SSO flow
 

package/.docs/organized/docs/vault/_navigation.mdx

@@ -9,6 +9,8 @@ links:
         url: /vault/quick-start
       - title: Key Context
         url: /vault/key-context
+      - title: BYOK
+        url: /vault/byok
 originalPath: .tmp-workos-clone/packages/docs/content/vault/_navigation.mdx
 ---
 

package/.docs/organized/docs/vault/byok.mdx

@@ -0,0 +1,140 @@
+---
+title: Bring Your Own Key (BYOK)
+description: >-
+  Allow your customers to use their own encryption keys with WorkOS Vault for
+  enhanced security and compliance.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/vault/byok.mdx
+---
+
+Bring Your Own Key (BYOK) allows your customers to use their own customer-managed keys (CMKs) with WorkOS Vault instead of relying solely on WorkOS-managed keys. This feature enables you to offer your customers additional control over their encryption keys and help them meet specific compliance requirements.
+
+## Overview
+
+With BYOK, your customers maintain control over their key material while still leveraging Vault's encryption and data management capabilities. Customer-managed keys are used as key-encrypting keys (KEKs) in place of WorkOS-managed KEKs, providing an additional layer of security and compliance for your application's users.
+
+## How BYOK works
+
+When Vault is configured with BYOK:
+
+1. **Key Matching**: Encryption operations are matched to customer CMKs based on the [key context](/vault/key-context) provided
+2. **Envelope Encryption**: Customer CMKs encrypt data-encrypting keys (DEKs), not the data directly
+3. **Automatic Fallback**: Operations that don't match a customer's CMK configuration will use WorkOS-managed KEKs
+
+### Key Context Matching
+
+BYOK uses the same key context mechanism as standard Vault operations. When a customer's CMK is configured for specific context values, Vault automatically uses that key for matching operations.
+
+**Example Configuration:**
+
+- Customer CMK `key_abc` configured for `organization_id: "org_123"`
+- Key context `{"organization_id": "org_123"}` → Uses customer CMK `key_abc`
+- Key context `{"organization_id": "org_456"}` → Uses WorkOS-managed KEK
+
+## Benefits
+
+### Enhanced Security
+
+- **Key Control**: Your customers maintain complete control over their encryption keys
+- **Isolation**: Customer keys remain separate from other tenants' data
+- **Audit Trail**: Customers have full visibility into their key usage and access patterns
+
+### Compliance
+
+- **Regulatory Requirements**: Help customers meet compliance standards that require customer-controlled keys
+- **Data Sovereignty**: Enable customers to ensure encryption keys remain within their control
+- **Risk Management**: Reduce customer dependency on third-party key management
+
+## Use Cases
+
+### Multitenant Applications
+
+Allow different customers to use their own CMKs while maintaining a single Vault integration:
+
+```javascript
+// Customer A data - uses Customer A's CMK
+await vault.createObject({
+  name: 'customer-a-pii',
+  value: '{"fullname": "customer_a_name"}',
+  context: { organization_id: 'customer_a' },
+});
+
+// Customer B data - uses Customer B's CMK
+await vault.createObject({
+  name: 'customer-b-pii',
+  value: '{"fullname": "customer_b_name"}',
+  context: { organization_id: 'customer_b' },
+});
+```
+
+### Compliance Sensitive Data
+
+Allow customers to apply stricter key controls to specific data types:
+
+```javascript
+// PCI data - uses customer's CMK
+await vault.createObject({
+  name: 'customer-123-payments',
+  value: '{"creditCard": "4111-1111-1111-1111"}',
+  context: {
+    organization_id: 'customer_123',
+  },
+});
+
+// General data - uses WorkOS-managed keys
+await vault.createObject({
+  name: 'customer-123-preferences',
+  value: '{"preference": "dark_mode"}',
+  context: {
+    data_type: 'preferences',
+  },
+});
+```
+
+### Geographic Data Residency
+
+Allow customers to ensure their encryption keys remain in specific regions:
+
+```javascript
+// EU data - uses customer's EU-based CMK
+await vault.createObject({
+  name: 'customer-789-pii',
+  value: '{"userEmail": "user@example.eu"}',
+  context: {
+    organization_id: 'customer_789',
+  },
+});
+```
+
+## Configuration
+
+BYOK configuration is managed through your WorkOS dashboard and admin portal. Contact your WorkOS representative to enable BYOK for your application.
+
+### Prerequisites
+
+- Your customers must have compatible key management systems (AWS KMS, Azure Key Vault, Google Cloud KMS)
+- Proper IAM permissions for WorkOS Vault to access customer keys
+
+### Generate Admin Portal link
+
+Navigate to the organization of your customer who will configure their CMK. Generate a unique portal link by clicking "Invite admin" and selecting "Bring Your Own Key" from the feature selection.
+
+![Generate admin portal link](https://images.workoscdn.com/images/d374bc73-7cdc-441c-b177-82c4ae604db7.png?auto=format&fit=clip&q=80)
+
+### Share link with your customer's IT team
+
+The admin portal will walk an IT admin through the setup and configuration of the CMK. It includes screenshots for using the cloud provider of choice to create a key and set the appropriate permission in IAM policies to allow Vault to use the key.
+
+![Share link with IT](https://images.workoscdn.com/images/7f237529-584b-4a98-b17e-2ce4bf6c1e08.png?auto=format&fit=clip&q=80)
+
+### Confirm successful admin portal setup
+
+The final step of the admin portal setup flow will validate that Vault can use the CMK the IT admin configured. If they see "Setup is complete", Vault will use the customer's CMK whenever an operation includes their organization id as context.
+
+![Confirm CMK setup success](https://images.workoscdn.com/images/f46f7009-3cf5-4706-a37e-691768d63440.png?auto=format&fit=clip&q=80)
+
+### View CMK under Organization details
+
+A Key details card will appear under Organization details, which shows configuration information, CMK active state, and the key context associated with the CMK.
+
+![View key details](https://images.workoscdn.com/images/54c026c7-f3b0-497a-bb48-83661ba1ae3e.png?auto=format&fit=clip&q=80)

package/.docs/organized/docs/vault/index.mdx

@@ -35,4 +35,4 @@ User data such as Personally Identifiable Information (PII) or Protected Health
 
 ### Application secrets
 
-With short-lived dynamic workloads in the cloud, static credentials represent a huge security risk. Secrets can get spread out across many services, making rotation difficult and the change of a leak high. Vault can encrypt and store application data such as API keys, database credentials, and PKI certificates in a centralized service and provide them to your application at runtime.
+With short-lived dynamic workloads in the cloud, static credentials represent a huge security risk. Secrets can get spread out across many services, making rotation difficult and increasing the risk of a leak. Vault can encrypt and store application data such as API keys, database credentials, and PKI certificates in a centralized service and provide them to your application at runtime.

package/.docs/organized/docs/widgets/_navigation.mdx

@@ -0,0 +1,48 @@
+---
+title: Widgets
+links:
+  - title: Getting Started
+    links:
+      - title: Quick Start
+        url: /widgets/quick-start
+      - title: Authorization Tokens
+        url: /widgets/tokens
+      - title: Localization
+        url: /widgets/localization
+  - title: Styling
+    links:
+      - title: Overview
+        url: /widgets/styling
+      - title: Theme Customization
+        url: /widgets/styling/theme-customization
+  - title: AuthKit
+    links:
+      - title: User Management
+        url: /widgets/user-management
+      - title: User Profile
+        url: /widgets/user-profile
+      - title: User Sessions
+        url: /widgets/user-sessions
+      - title: User Security
+        url: /widgets/user-security
+      - title: API Keys
+        url: /widgets/api-keys
+      - title: Pipes
+        url: /widgets/pipes
+  - title: Admin Portal
+    links:
+      - title: Domain Verification
+        url: /widgets/admin-portal-domain-verification
+      - title: SSO Connection
+        url: /widgets/admin-portal-sso-connection
+      - title: Directory Sync
+        url: /widgets/directory-sync
+      - title: Audit Log Streaming
+        url: /widgets/audit-log-streaming
+  - title: Organizations
+    links:
+      - title: Organization Switcher
+        url: /widgets/organization-switcher
+originalPath: .tmp-workos-clone/packages/docs/content/widgets/_navigation.mdx
+---
+

package/.docs/organized/docs/widgets/admin-portal-domain-verification.mdx

@@ -0,0 +1,24 @@
+---
+title: Domain Verification Widget
+description: A widget for verifying domains in the Admin Portal.
+originalPath: >-
+  .tmp-workos-clone/packages/docs/content/widgets/admin-portal-domain-verification.mdx
+---
+
+![Domain Verification Widget screenshot](https://images.workoscdn.com/images/6a98da6f-7178-4bb1-a276-ff024461cc16.png?auto=format&fit=clip&q=50)
+
+The `<AdminPortalDomainVerification />` widget enables users to verify domains in the Admin Portal.
+
+In order to use the Domain Verification widget, a user must have a role that has the `widgets:domain-verification:manage` permission.
+
+<CodeBlock>
+  <CodeBlockTab
+    language="js"
+    file="widget-domainverification-token"
+    title="Widget Token"
+  />
+</CodeBlock>
+
+## API Reference
+
+<PropsTable data={widgets.adminPortalDomainVerification.props} />

package/.docs/organized/docs/widgets/admin-portal-sso-connection.mdx

@@ -0,0 +1,20 @@
+---
+title: SSO Connection Widget
+description: A widget for setting up SSO connections in the Admin Portal.
+originalPath: >-
+  .tmp-workos-clone/packages/docs/content/widgets/admin-portal-sso-connection.mdx
+---
+
+![SSO Connection Widget screenshot](https://images.workoscdn.com/images/1c8bb97f-b321-4fab-8a1b-b46d3dd92f1f.png?auto=format&fit=clip&q=50)
+
+The `<AdminPortalSsoConnection />` widget enables users to set up SSO connections in the Admin Portal.
+
+In order to use the SSO Connection widget, a user must have a role that has the `widgets:sso:manage` permission.
+
+<CodeBlock>
+  <CodeBlockTab language="js" file="widget-sso-token" title="Widget Token" />
+</CodeBlock>
+
+## API Reference
+
+<PropsTable data={widgets.adminPortalSsoConnection.props} />

package/.docs/organized/docs/widgets/api-keys.mdx

@@ -0,0 +1,28 @@
+---
+title: API Keys Widget
+description: A widget for displaying and managing API Keys.
+originalPath: .tmp-workos-clone/packages/docs/content/widgets/api-keys.mdx
+---
+
+![API Keys widget screenshot](https://images.workoscdn.com/images/13e0893f-eb84-43f1-9467-2598567538f3.png?auto=format&fit=clip&q=50)
+
+The `<ApiKeys />` widget allows an admin to manage API keys in an organization. Admins can create API keys with specific permissions, view details of existing API keys, and revoke API keys, all within the widget.
+
+In order to use the API Keys widget, a user must have a role that has the `widgets:api-keys:manage` permission.
+
+<CodeBlock>
+  <CodeBlockTab
+    language="js"
+    file="widget-apikeys-token"
+    title="Widget Token"
+  />
+  <CodeBlockTab
+    language="js"
+    file="widget-apikeys-authkit-react"
+    title="Access Token"
+  />
+</CodeBlock>
+
+## API Reference
+
+<PropsTable data={widgets.apiKeys.props} />

package/.docs/organized/docs/widgets/audit-log-streaming.mdx

@@ -0,0 +1,25 @@
+---
+title: Audit Log Streaming Widget
+description: >-
+  A widget for configuring and monitoring audit log streaming in the Admin
+  Portal.
+originalPath: .tmp-workos-clone/packages/docs/content/widgets/audit-log-streaming.mdx
+---
+
+![Audit Log Streaming Widget screenshot](https://images.workoscdn.com/images/408ea781-5544-4340-a566-a9d2e16f903d.png?auto=format&fit=clip&q=50)
+
+The `<AdminPortalAuditLogStreaming />` widget enables users to configure and monitor audit log streaming to external destinations in the Admin Portal. It displays the streaming status, destination configuration, and connection health.
+
+In order to use the Audit Log Streaming widget, a user must have a role that has the `widgets:audit-log-streaming:manage` permission.
+
+<CodeBlock>
+  <CodeBlockTab
+    language="js"
+    file="widget-auditlogstreaming-token"
+    title="Widget Token"
+  />
+</CodeBlock>
+
+## API Reference
+
+<PropsTable data={widgets.auditLogStreaming.props} />

package/.docs/organized/docs/widgets/directory-sync.mdx

@@ -0,0 +1,23 @@
+---
+title: Directory Sync Widget
+description: A widget for managing Directory Sync connections in the Admin Portal.
+originalPath: .tmp-workos-clone/packages/docs/content/widgets/directory-sync.mdx
+---
+
+![Directory Sync Widget screenshot](/docs/images/widgets/directory-sync-widget.png)
+
+The `<DirectorySync />` widget enables users to manage Directory Sync connections in the Admin Portal. It displays the directory status, metadata, and callout messages.
+
+In order to use the Directory Sync widget, a user must have a role that has the `widgets:dsync:manage` permission.
+
+<CodeBlock>
+  <CodeBlockTab
+    language="js"
+    file="widget-directorysync-token"
+    title="Widget Token"
+  />
+</CodeBlock>
+
+## API Reference
+
+<PropsTable data={widgets.directorySync.props} />

package/.docs/organized/docs/widgets/index.mdx

@@ -0,0 +1,12 @@
+---
+title: WorkOS Widgets
+description: Learn how to integrate WorkOS Widgets in your app.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/widgets/index.mdx
+---
+
+## Introduction
+
+WorkOS Widgets are React components that provide complete functionality for common enterprise app workflows, for example a Users Management Widget that provides a UI for inviting, removing and editing users.
+
+This guide will cover how to add a widget to your app, configure CORS, and supply an authorization token for the widget.