@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/{user-management → authkit}/magic-auth.mdx

@@ -2,7 +2,7 @@
 title: Magic Auth
 description: Maximize user experience and security with passwordless authentication.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/magic-auth.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/magic-auth.mdx
 ---
 
 ## Introduction
@@ -11,9 +11,7 @@ Magic Auth is a passwordless authentication method that allows users to sign in
 
 ## Getting started
 
-AuthKit will make the necessary API calls to issue one-time-use codes via email and provide input verification and authentication automatically. If desired, you can [send these emails yourself](/user-management/custom-emails).
-
-> **Important:** Emails will not be sent from the **production** environment until you have configured a domain. See the [Custom Domains](/custom-domains/email) guide for more information on how to configure this.
+AuthKit will make the necessary API calls to issue one-time-use codes via email and provide input verification and authentication automatically. If desired, you can [send these emails yourself](/authkit/custom-emails).
 
 ### Enabling Magic Auth
 
@@ -31,6 +29,6 @@ One-time-use codes expire after **10 minutes**.
 
 ## Integrating via the API
 
-If you’d prefer to build and manage your own authentication UI, you can do so via the User Management [Magic Auth API](/reference/user-management/magic-auth).
+If you’d prefer to build and manage your own authentication UI, you can do so via the AuthKit [Magic Auth API](/reference/authkit/magic-auth).
 
 Examples of building custom UI are also [available on GitHub](https://github.com/workos/authkit).

package/.docs/organized/docs/{user-management → authkit}/mcp.mdx

@@ -2,7 +2,7 @@
 title: Model Context Protocol
 description: How to use AuthKit as the authorization server for your MCP server.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/mcp.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/mcp.mdx
 ---
 
 ## Introduction
@@ -11,7 +11,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/user-management/mcp.mdx
 
 This guide is intended for application developers implementing an MCP _server_ that requires authentication. WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.
 
-> Support for the MCP authorization spec is currently in feature preview. Reach out to [WorkOS support](mailto:support@workos.com?subject=MCP%20Authentication%20with%20AuthKit) if you want early access.
+> If you have feedback or questions about MCP, we'd love to hear from you! Reach out to [WorkOS support](mailto:support@workos.com?subject=MCP%20Authentication%20with%20AuthKit) or via your team's WorkOS Slack channel.
 
 ## Authorization
 
@@ -20,7 +20,7 @@ The MCP specification builds on industry-standard protocols like [OAuth 2.0](htt
 - **Resource Server** – This is your MCP server, which you may choose to build using the [official Model Context Protocol SDKs](https://github.com/modelcontextprotocol).
 - **Authorization Server** – This is AuthKit, which is a spec-compatible OAuth authorization server. While the spec allows the authorization and resource server to be the same, it can be architecturally simpler to delegate to an existing authorization server like AuthKit.
 
-Support for MCP authorization is built on top of [WorkOS Connect](/user-management/connect), which provides all of the necessary OAuth API endpoints MCP clients will use to authenticate. You can view your AuthKit metadata by making a request to its `/.well-known/oauth-authorization-server` endpoint:
+Support for MCP authorization is built on top of [WorkOS Connect](/authkit/connect/oauth), which provides all of the necessary OAuth API endpoints MCP clients will use to authenticate. You can view your AuthKit metadata by making a request to its `/.well-known/oauth-authorization-server` endpoint:
 
 ```bash
 curl https://authkit_domain/.well-known/oauth-authorization-server | jq
@@ -50,17 +50,19 @@ AuthKit handles the authentication flow so your MCP server only needs to impleme
 1. Verifying access tokens issued by AuthKit for your MCP server.
 1. Direct clients to AuthKit using standardized metadata endpoints.
 
-### Enabling Dynamic Client Registration
+### Enabling Client ID Metadata Document (CIMD)
 
-The MCP protocol requires authorization servers (AuthKit) to implement the [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591). This allows MCP clients to discover and self-register without prior knowledge of the MCP server.
+MCP clients often have no prior relationship with your MCP server. The MCP protocol specifies that authorization servers (AuthKit) should support [Client ID Metadata Document](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00) (CIMD) to allow MCP clients to identify themselves.
 
-Dynamic Client Registration is off by default but can be enabled in the WorkOS Dashboard under _Applications_ → _Configuration_.
+Client ID Metadata Document is off by default, but you should enable it in the WorkOS Dashboard under _Connect_ → _Configuration_.
 
-![A screenshot of the Applications Configuration page in the WorkOS Dashboard.](https://images.workoscdn.com/images/10ae97ec-770c-46b6-b7b1-4a9464392590.png)
+Client ID Metadata Document was added to the MCP specification in November 2025. You can enable the previous approach, [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591) (DCR), in the WorkOS Dashboard for backwards compatibility with MCP clients that don't yet support Client ID Metadata Document.
+
+![A screenshot of the Connect Configuration page in the WorkOS Dashboard.](https://images.workoscdn.com/images/c0ed8f95-9b41-462d-98e8-934b8f022f22.png)
 
 ### Token Verification
 
-Your app needs to gate access to the MCP endpoints by verifying access tokens issued by AuthKit for your MCP server. This process is very similar to [the way any Connect JWT is verified](/user-management/connect/verifying-tokens), with one important addition:
+Your app needs to gate access to the MCP endpoints by verifying access tokens issued by AuthKit for your MCP server. This process is very similar to [the way any Connect JWT is verified](/authkit/connect/oauth/verifying-tokens), with one important addition:
 
 ```js
 import { jwtVerify, createRemoteJWKSet } from 'jose';
@@ -120,7 +122,7 @@ MCP clients that support metadata discovery will automatically fetch this metada
 
 ![The authorization prompt users will be shown when giving access to an MCP client.](https://images.workoscdn.com/images/ce1d133c-503c-4abc-8422-c274bbd8786c.png)
 
-Behind the scenes, AuthKit implements the necessary authorization, dynamic client registration, and token endpoints so that your application doesn't need to. You can read more in the [latest version of the MCP authorization spec](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/901ac03e1c72827acb8017f80eeb14e38ad8ba42/docs/specification/draft/basic/authorization.mdx) but most apps can consider them implementation details of AuthKit as the authorization server.
+Behind the scenes, AuthKit implements the necessary authorization and token endpoints so that your application doesn't need to. You can read more in the [latest version of the MCP authorization spec](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/901ac03e1c72827acb8017f80eeb14e38ad8ba42/docs/specification/draft/basic/authorization.mdx) but most apps can consider them implementation details of AuthKit as the authorization server.
 
 Upon successful authentication the client will receive credentials and can start making requests to your application's MCP endpoints.
 
@@ -144,3 +146,38 @@ app.get('/.well-known/oauth-authorization-server', async (req, res) => {
 ```
 
 Clients will use AuthKit as the authorization server and the rest of the flow will be identical.
+
+## Standalone MCP OAuth
+
+If you already have an existing authentication system in your application, you can use [Standalone Connect](/authkit/connect/standalone) to integrate AuthKit's OAuth capabilities with your MCP server while preserving your current authentication stack.
+
+Standalone Connect is particularly useful for MCP scenarios where you:
+
+- Want to add MCP support to an application with existing user authentication.
+- Need to maintain consistency with your current login experience and user management.
+- Require custom authentication logic.
+
+### How it works
+
+With Standalone Connect for MCP, the authentication flow works differently from the standard AuthKit integration described above:
+
+1. **MCP clients** initiate the OAuth flow for your MCP server with AuthKit as your authorization server.
+2. **AuthKit redirects** users to your application's Login URI instead of showing AuthKit's login page.
+3. **Your application** authenticates users using your existing authentication system.
+4. **Your application** calls [AuthKit's completion API](/reference/workos-connect/standalone/complete) to complete the OAuth flow.
+5. **AuthKit** handles the OAuth consent, token issuance, and returns control to the MCP client.
+
+This approach allows you to maintain full control over the user authentication experience while leveraging AuthKit's OAuth infrastructure for MCP client authorization.
+
+### Implementation considerations
+
+When using Standalone Connect with MCP:
+
+- You'll still need to enable [Client ID Metadata Document](#enabling-client-id-metadata-document-cimd) to support MCP clients that register themselves.
+- [Token verification](#token-verification) works identically—your MCP server validates tokens using the same JWT verification process.
+- The [metadata endpoints](#metadata) remain the same, ensuring MCP clients can discover and interact with your server.
+- Your Login URI must be configured in the WorkOS Dashboard and handle the `external_auth_id` parameter from AuthKit.
+
+The key difference is in the authentication step: instead of users signing in through AuthKit's interface, they authenticate with your existing system, and AuthKit handles only the OAuth authorization and token issuance portions of the flow.
+
+For detailed implementation steps and code examples, see the [Standalone Connect documentation](/authkit/connect/standalone).

package/.docs/organized/docs/{user-management → authkit}/metadata.mdx

@@ -2,7 +2,7 @@
 title: Metadata and External IDs
 description: Store additional information about users and organizations.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/metadata.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/metadata.mdx
 ---
 
 ## Introduction
@@ -24,28 +24,28 @@ External identifiers must be unique within your environment and are limited to 6
 You can add up to 10 key-value pairs to an organization or user within these data limits:
 
 - **Key**: Up to 40 characters long. ASCII only.
-- **Value**: Up to 500 characters long. ASCII only.
+- **Value**: Up to 600 characters long. ASCII only.
 
 If your integration requires more than 10 key-value pairs, consider storing the additional data in your own external database and use an external identifier to associate the data with an organization or user.
 
 > Never store sensitive information in metadata such as passwords, API keys, or other private information.
 
-Metadata is returned in the response body for backend API operations that return organization or user objects, but not in the response body of the [User Authentication](/reference/user-management/authentication) operations. If you want to publicly expose metadata properties from users or organizations in your access tokens, you can use JWT templates to customize claims in your application's access tokens.
+Metadata is returned in the response body for backend API operations that return organization or user objects, but not in the response body of the [User Authentication](/reference/authkit/authentication) operations. If you want to publicly expose metadata properties from users or organizations in your access tokens, you can use JWT templates to customize claims in your application's access tokens.
 
 ## Set an external identifier
 
-To set an external identifier for an organization or user, include the `external_id` property in the request body of the [Create an organization](/reference/organization/create) or [Create a user](/reference/user-management/user/create) endpoints.
+To set an external identifier for an organization or user, include the `external_id` property in the request body of the [Create an organization](/reference/organization/create) or [Create a user](/reference/authkit/user/create) endpoints.
 
 <CodeBlock referenceId="set_external_id">
   <CodeBlockTab title="Request" file="set-external-id" />
   <CodeBlockTab title="Response" file="set-external-id-response" />
 </CodeBlock>
 
-To update an external identifier, include the `external_id` property in the request body of the [Update an organization](/reference/organization/update) or [Update a user](/reference/user-management/user/update) endpoints.
+To update an external identifier, include the `external_id` property in the request body of the [Update an organization](/reference/organization/update) or [Update a user](/reference/authkit/user/update) endpoints.
 
 ## Query by external identifier
 
-To query an organization or user by their external identifier, use the [Get organization by external identifier](/reference/organization/get-by-external-id) or [Get user by external identifier](/reference/user-management/user/get-by-external-id) endpoints.
+To query an organization or user by their external identifier, use the [Get organization by external identifier](/reference/organization/get-by-external-id) or [Get user by external identifier](/reference/authkit/user/get-by-external-id) endpoints.
 
 ## Add and update metadata
 
@@ -55,8 +55,8 @@ Metadata can be included in the request body of the following endpoints:
 
 - [Create an organization](/reference/organization/create)
 - [Update an organization](/reference/organization/update)
-- [Create a user](/reference/user-management/user/create)
-- [Update a user](/reference/user-management/user/update)
+- [Create a user](/reference/authkit/user/create)
+- [Update a user](/reference/authkit/user/update)
 
 To add a metadata attribute to an entity, include the key and value pair in the `metadata` object of the request body.
 
@@ -98,7 +98,7 @@ To delete all metadata attributes, set the `metadata` property an empty object.
 
 ## Exposing metadata in JWTs
 
-Custom metadata and external identifiers can be exposed as claims in JWTs using [JWT Templates](/user-management/jwt-templates).
+Custom metadata and external identifiers can be exposed as claims in JWTs using [JWT Templates](/authkit/jwt-templates).
 
 <CodeBlock>
   <CodeBlockTab

package/.docs/organized/docs/{user-management → authkit}/mfa.mdx

@@ -2,7 +2,7 @@
 title: Multi-Factor Authentication
 description: Add an additional layer of security to your application.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/mfa.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/mfa.mdx
 ---
 
 ## Introduction
@@ -27,6 +27,6 @@ MFA can be enabled in the _Authentication_ section of the [WorkOS Dashboard](htt
 
 ## Integrating via the API
 
-If you’d prefer to build and manage your own authentication UI, you can do so via the User Management [Multi-Factor API](/reference/user-management/mfa).
+If you’d prefer to build and manage your own authentication UI, you can do so via the AuthKit [Multi-Factor API](/reference/authkit/mfa).
 
 Examples of building custom UI are also [available on GitHub](https://github.com/workos/authkit).

package/.docs/organized/docs/{user-management → authkit}/migrations.mdx

@@ -1,13 +1,13 @@
 ---
-title: Migrating to User Management
+title: Migrating to AuthKit
 description: Guidance on moving your existing users to WorkOS.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/migrations.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/migrations.mdx
 ---
 
 ## Introduction
 
-WorkOS provides a [range of guides](/migrate) to help you migrate your existing integration to WorkOS User Management.
+WorkOS provides a [range of guides](/migrate) to help you migrate your existing integration to AuthKit.
 
 ## Migrate from another service
 
@@ -17,4 +17,4 @@ These guides will walk you through the process of moving your users and organiza
 
 ## Migrating an existing WorkOS integration
 
-If you already have an integration with WorkOS (for example, using the [standalone API](/sso) to provide SSO to your customers), you can migrate to User Management and take advantage of all of the features it provides by following [this guide](/migrate/standalone-sso).
+If you already have an integration with WorkOS (for example, using the [standalone API](/sso) to provide SSO to your customers), you can migrate to AuthKit and take advantage of all of the features it provides by following [this guide](/migrate/standalone-sso).

package/.docs/organized/docs/{user-management → authkit}/modeling-your-app.mdx

@@ -2,7 +2,7 @@
 title: Modeling Your App
 description: Learn how to architect your WorkOS integration
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/modeling-your-app.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/modeling-your-app.mdx
 ---
 
 ## Introduction
@@ -29,11 +29,11 @@ There are three main ways to add WorkOS authentication to your application:
 
 ### AuthKit
 
-A [hosted login solution](/user-management/authkit) that provides a customizable UI and supports a wide range of authentication methods.
+A [hosted login solution](/authkit) that provides a customizable UI and supports a wide range of authentication methods.
 
 ### Custom AuthKit UI
 
-If you prefer to craft your own UI in your own stack, AuthKit can be integrated with the [User Management API](/reference/user-management).
+If you prefer to craft your own UI in your own stack, you can use the [AuthKit APIs](/reference/authkit) directly.
 
 ### Standalone Single Sign-On (SSO)
 
@@ -45,7 +45,7 @@ In the majority of cases we recommend using the hosted AuthKit solution.
 
 On successful completion, AuthKit will return an authentication code to your application via your specified redirect URI, this is exchanged for the user object and used to create a session.
 
-See the [Quick Start guide](/user-management) for more information on how to implement this.
+See the [Quick Start guide](/authkit) for more information on how to implement this.
 
 ## Authentication methods
 
@@ -69,7 +69,7 @@ A similar technique is Magic Link, where the user can log in by clicking a link
 
 The favored authentication method by enterprise sized companies, SSO allows an organization's users to sign in with a single ID to related, yet independent software systems.
 
-The WorkOS User Management APIs make the above easy to implement using your own UI, or you can use AuthKit for a fully hosted experience.
+The AuthKit APIs make the above easy to implement using your own UI, or you can use AuthKit's Hosted UI for a fully hosted experience.
 
 ## Single-tenant and multi-tenant models
 
@@ -89,7 +89,7 @@ Multi-tenant refers to a software architecture where a single instance of the so
 
 Each tenant's data is isolated and remains invisible to other tenants because the software is designed to securely handle this data across all tenants.
 
-In the context of WorkOS, a multi-tenant application could be accomplished by the use of [Organizations](/reference/organization) and [Organization Memberships](/reference/user-management/organization-membership) to ensure that end-users only have access to the data they are authorized to.
+In the context of WorkOS, a multi-tenant application could be accomplished by the use of [Organizations](/reference/organization) and [Organization Memberships](/reference/authkit/organization-membership) to ensure that end-users only have access to the data they are authorized to.
 
 By default WorkOS comes with two environments: staging and production. The former is for development and testing, the latter for live traffic. For single-tenant applications, new environments can be added to your WorkOS account to accommodate each of your users. For more information or to request new environments, please reach out to [support](mailto:support@workos.com).
 
@@ -121,7 +121,7 @@ This model starts to become incredibly powerful as we can now capture more compl
 
 ### Domain verification and domain policies
 
-[Domain verification](/user-management/domain-verification) is the process of proving ownership of a specific domain, typically handled by a company’s IT department. Once a domain is verified, all existing and future users with email addresses matching the domain are, by default, managed by the organization's [domain policy](/user-management/organization-policies/domain-policy). This allows the organization to control authentication and membership behavior for these users, such as requiring these users to authenticate via SSO.
+[Domain verification](/authkit/domain-verification) is the process of proving ownership of a specific domain, typically handled by a company’s IT department. Once a domain is verified, all existing and future users with email addresses matching the domain are, by default, managed by the organization's [domain policy](/authkit/organization-policies/domain-policy). This allows the organization to control authentication and membership behavior for these users, such as requiring these users to authenticate via SSO.
 
 Users signing in with SSO with a verified email domain are automatically considered verified and do not need to complete the email verification process.
 
@@ -139,11 +139,11 @@ With the Admin Portal, the process of configuring your customer’s SSO integrat
 
 As with B2C models, user data on the WorkOS side can be used as the source of truth, but the far more common scenario is to store user information in your own database which links to the WorkOS user.
 
-The WorkOS User Management and SSO products can be used independently, with the latter acting as authentication middleware which intentionally does not handle user database management for your application. If you’re unsure which is best for your business, it’s recommended to stick with User Management as it gives you the aforementioned flexibility to add and/or remove features as your needs grow.
+The AuthKit and SSO products can be used independently, with the latter acting as authentication middleware which intentionally does not handle user database management for your application. If you're unsure which is best for your business, it's recommended to stick with AuthKit as it gives you the aforementioned flexibility to add and/or remove features as your needs grow.
 
 ## Example scenarios
 
-As your application grows you may find yourself needing to add additional features to support customer needs. WorkOS User Management is designed with this is mind. As you move upmarket and take on larger and larger customers, you can easily adopt and extend your feature set within an established architecture. The following scenarios explain some common use cases with specific feature sets.
+As your application grows you may find yourself needing to add additional features to support customer needs. AuthKit is designed with this is mind. As you move upmarket and take on larger and larger customers, you can easily adopt and extend your feature set within an established architecture. The following scenarios explain some common use cases with specific feature sets.
 
-- [SSO with contractors](/user-management/sso-with-contractors) – Enforcing Organization SSO with external guest members.
-- [Invite-only Signup](/user-management/invite-only-signup) – An invite only application that allows existing users to invite new members.
+- [SSO with contractors](/authkit/sso-with-contractors) – Enforcing Organization SSO with external guest members.
+- [Invite-only Signup](/authkit/invite-only-signup) – An invite only application that allows existing users to invite new members.

package/.docs/organized/docs/{user-management → authkit}/organization-policies.mdx

@@ -2,8 +2,7 @@
 title: Organization Authentication Policies
 description: Customize available authentication methods for each organization.
 showNextPage: true
-originalPath: >-
-  .tmp-workos-clone/packages/docs/content/user-management/organization-policies.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/organization-policies.mdx
 ---
 
 ## Introduction
@@ -12,9 +11,9 @@ Some organizations may prefer to limit their users to specific authentication me
 
 ## Domain policy
 
-A domain policy allows an organization to control authentication and membership behavior of users whose email domain matches one of the organization’s [verified domains](/user-management/domain-verification). Domain policies are enforced for _all_ users with email domains included in the policy, regardless of their membership status within the organization or the organization selected during sign-in.
+A domain policy allows an organization to control authentication and membership behavior of users whose email domain matches one of the organization’s [verified domains](/authkit/domain-verification). Domain policies are enforced for _all_ users with email domains included in the policy, regardless of their membership status within the organization or the organization selected during sign-in.
 
-Additionally, users provisioned through a [directory](/user-management/directory-provisioning) with an email domain included in the organization's domain policy will be automatically added as active members of the organization without needing an invitation.
+Additionally, users provisioned through a [directory](/authkit/directory-provisioning) with an email domain included in the organization's domain policy will be automatically added as active members of the organization without needing an invitation.
 
 ![Configuring a domain policy in the dashboard](https://images.workoscdn.com/images/b98493d9-f9fe-475d-a448-f9099558cd19.png?auto=format&fit=clip&q=50)
 

package/.docs/organized/docs/authkit/overview.mdx

@@ -0,0 +1,46 @@
+---
+title: AuthKit
+description: >-
+  Easy to use authentication APIs designed to provide a flexible, secure, and
+  fast integration.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/overview.mdx
+---
+
+## Introduction
+
+WorkOS AuthKit is a user management platform that provides a set of user authentication and organization security features that securely power your application. Features are designed to be flexible, while offering a fast integration to handle all of the user management complexity that comes with advanced business and customer needs.
+
+## Authentication
+
+AuthKit supports many authentication methods out of the box. They are designed to grow with your app, from the simplest use case all the way to complex Enterprise [SSO](/authkit/sso) for your largest customers, these include:
+
+- [Single Sign-On](/authkit/sso)
+- [Email & Password](/authkit/email-password)
+- [Social Login](/authkit/social-login)
+- [Multi-Factor Auth](/authkit/mfa)
+- [Magic Auth](/authkit/magic-auth)
+
+These features are available via [AuthKit](/authkit), or through the public [API](/reference/authkit). AuthKit provides an easy to integrate, pre-built authentication flow, while integrating against the API allows you to implement your own UI and Sign In flow.
+
+## Fast integration
+
+The fastest way to integrate AuthKit features is with the [Hosted UI](/authkit/hosted-ui).
+
+![AuthKit Sign In UI](https://images.workoscdn.com/images/b8286e7e-3ad9-4d43-99d5-e022e6bb36fb.png?auto=format&fit=clip&q=80)
+
+AuthKit abstracts away many of the UX and WorkOS API calling concerns automatically, allowing you to focus on building your application. See the [Quick Start](/authkit) guide for more information on how to get started.
+
+## Security
+
+Adopting AuthKit in your app provides a wealth of security benefits.
+
+- Best-in-class [email verification](/authkit/email-verification), enabled by default.
+- Safe [identity linking](/authkit/identity-linking) and merging of duplicate accounts. This protects against spoofing and reduces the user support burden.
+- Identity Provider (IdP) differences are normalized, so that you get consistency across user profiles. This reduces the likelihood of security issues related to differing semantics across providers.
+- Automatic bot detection and blocking, to protect against brute force attacks.
+- [Multi-Factor Authentication (MFA)](/authkit/mfa) available per environment to further enhance your app’s security posture.
+
+## Getting started
+
+Start integrating AuthKit into your app today, check out the [Quick Start](/authkit) guide to get started with AuthKit or review the [API Reference](/reference/authkit) material.

package/.docs/organized/docs/{user-management → authkit}/passkeys.mdx

@@ -2,7 +2,7 @@
 title: Passkeys
 description: Configuring passkey authentication and enrollment.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/passkeys.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/passkeys.mdx
 ---
 
 ## Introduction
@@ -31,7 +31,7 @@ If users skip passkey enrollment they will be reminded every two weeks, and addi
 
 ### Multi-factor auth
 
-If [MFA](/user-management/mfa) is also enabled and required, users who sign in with a passkey will not be prompted for a separate TOTP code. AuthKit treats passkeys as both a first and second factor by requiring user verification when a passkey is presented.
+If [MFA](/authkit/mfa) is also enabled and required, users who sign in with a passkey will not be prompted for a separate TOTP code. AuthKit treats passkeys as both a first and second factor by requiring user verification when a passkey is presented.
 
 User verification in the context of a passkey means the passkey must be combined with another "authorization gesture", like the scanning of a fingerprint, or entering a separate PIN.
 
@@ -39,4 +39,4 @@ User verification in the context of a passkey means the passkey must be combined
 
 ## Integrating via the API
 
-Passkey authentication is currently only available in AuthKit. If you'd like to discuss an API-based integration, please reach out to [support](mailto:support@workos.com).
+Passkey authentication is currently only available with the hosted UI in AuthKit.

package/.docs/organized/docs/authkit/pipes.mdx

@@ -0,0 +1,75 @@
+---
+title: Pipes
+description: >-
+  Enable your customers to connect their third-party accounts to your
+  application.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/pipes.mdx
+---
+
+## Introduction
+
+Pipes allows your users to securely connect their third-party accounts to your
+application. With Pipes, you can easily integrate with popular services like
+GitHub, Slack, Google, Salesforce, and many more without managing OAuth flows,
+token refresh logic, or credential storage.
+
+## Configuring providers
+
+To make an provider available to your users, you will need to configure it in
+the WorkOS Dashboard.
+
+Visit the _Pipes_ section of the WorkOS Dashboard to get started. Click _Connect
+provider_ then choose the provider from the list. If you don’t see the provider
+you need, please reach out to [our team](mailto:support@workos.com).
+
+![A screenshot of a GitHub provider being configured via the Pipes page in the WorkOS Dashboard](https://images.workoscdn.com/images/88a1f135-53ba-4d26-92ef-6c61e924e178.png?auto=format&fit=clip&q=50)
+
+### Shared Credentials
+
+For the fastest setup, you can use WorkOS-managed shared credentials in sandbox
+environments. This allows users to connect immediately without requiring you to
+create OAuth applications with each provider.
+
+1. Specify the required **scopes** for your application.
+2. Provide an optional **description**. This will be used in the widget to inform users
+   on how your application will use their data from the provider.
+
+### Custom Credentials
+
+For production applications, configure the provider with your own OAuth credentials:
+
+1. **Create an OAuth application** within the provider's dashboard.
+   1. You can find instructions on setting up the provider in the documentation section of the setup modal.
+1. Use the provided **redirect URI** when configuring the provider.
+1. Set the **client ID and secret** from the provider.
+1. Specify the required **scopes** for your application.
+   1. You may need to set these scopes in the provider configuration as well.
+1. Provide an optional **description**. This will be used in the widget to inform users
+   on how your application will use their data from the provider.
+
+Commonly used scopes are provided in-line, but you should consult each provider's documentation for the full list of available scopes.
+
+## Provider management in your application
+
+The [Pipes Widget](/widgets/pipes) provides a pre-built UI for users to connect
+and manage their connected accounts. The widget shows the user which
+providers are available, and lets them easily initiate the authorization
+flow. It communicates with the WorkOS API and stores the connection information
+for the user. If there's ever a problem with the user’s access token, the widget
+will let them know they need to reauthorize.
+
+![Pipes widget screenshot](https://images.workoscdn.com/images/e84a33bb-0510-4d85-9041-33b1a0ce938c.png?auto=format&fit=clip&q=50)
+
+> The description in the widget is set in the provider's configuration in the WorkOS Dashboard.
+
+## Fetching access tokens
+
+Once a user has connected a provider, you can [fetch access tokens](/reference/pipes) from your
+backend to make API calls to the connected service on their behalf. Pipes takes
+care of refreshing the token if needed, so you’ll always have a fresh token. If
+there’s a problem with the token, the endpoint will return information about the issue so you can
+direct the user to the correct it. This may require sending the user to re-authorize directly
+or via the page with the Pipes widget.
+
+<CodeBlock file="pipes-fetch-token" />

package/.docs/organized/docs/{user-management → authkit}/radar.mdx

@@ -2,7 +2,7 @@
 title: Radar
 description: 'Protecting against bots, fraud and abuse.'
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/radar.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/radar.mdx
 ---
 
 ## Introduction
@@ -17,8 +17,9 @@ It's also a signal for suspicious behavior, such as when a device is used for mu
 
 ## Getting Started
 
-Radar is not enabled for all AuthKit instances by default.
-If you would like to access this feature, please reach out to [our team](mailto:support@workos.com), or for current customers, drop a note in your shared Slack channel.
+Radar works with AuthKit without additional integration effort.
+You can enable Radar directly from the WorkOS dashboard.
+If you are interested in using Radar but are not an AuthKit customer, please reach out to [our team](mailto:support@workos.com), or for current customers, drop a note in your shared Slack channel.
 
 ## Dashboard
 
@@ -57,6 +58,10 @@ The user is then prompted to enter that code to continue authentication.
 Challenging suspicious authentication attempts with an OTP is effective in stopping bots that are capable of solving CAPTCHAs,
 as well as malicious users who have stolen credentials but don't have access to the user's email account.
 
+> Radar supports SMS challenges for sign ups in preview.
+> Reach out to support via [email](mailto:support@workos.com) or Slack if you are interested in using SMS challenges.
+> Additional fees may apply.
+
 **Notifying** on an attempt will send an informational email to users and/or admins when Radar detects a suspicious behavior.
 This is helpful to proactively make individuals aware that an attack might be taking place, or their account was compromised.
 
@@ -92,6 +97,15 @@ Radar will detect if these attempts happen over a short period where it's not po
 
 ![Radar impossible travel configuration](https://images.workoscdn.com/images/458b59af-a3e8-4646-b8a2-1bc04ae27e8e.png?auto=format&fit=clip&q=50)
 
+### Repeat sign up
+
+Block or challenge repeat sign up attempts from the same email. By default, AuthKit fully deletes users.
+
+If your application allows for account deletion and has a free-trial, then users may be able to delete their account and sign up again to get a new free-trial.
+This protection restricts an email to a max of three uses before denying further sign ups.
+
+![Radar Repeat Sign Up protection modal](https://images.workoscdn.com/images/3e4a6937-c891-4076-b2bf-a2ed829c8004.png?auto=format&fit=clip&q=50)
+
 ### Stale accounts
 
 Get notified when an account that has been dormant without use becomes active
@@ -112,7 +126,28 @@ If it hasn’t, both the user and an administrator can be notified by email.
 
 ![Radar unrecognized device configuration](https://images.workoscdn.com/images/f574e3d9-feed-43bc-aadb-2790cbfd2ce0.png?auto=format&fit=clip&q=50)
 
-### Custom restrictions
+## Managed lists
+
+### Disposable email domains
+
+Radar maintains a constantly updated list of email domains known to provide disposable email services.
+Disposable email services may be used to bypass free account or free trial limits in your application.
+
+You can choose to block or log registrations that match an email domain in this list.
+Logging is useful to verify no adverse impact will occur before blocking all the domains.
+
+![Radar Disposable Email List Protection](https://images.workoscdn.com/images/33d5c007-a5c3-4451-8da2-745bb4096268.png?auto=format&fit=clip&q=50)
+
+### U.S. Sanctioned countries
+
+Block users from countries under US Sanctions from signing up or logging into your application. Contact [support](mailto:support@workos.com) to get the current list of countries.
+
+> If you need to block a different set of countries, please reach out to support via [email](mailto:support@workos.com) or slack to configure regional blocks.
+> Radar supports any region in the [ISO 3166-1 specification](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes).
+
+![Radar US sanctions country managed lists](https://images.workoscdn.com/images/a2cff432-daf6-4c8f-a192-f33071afacf5.png?auto=format&fit=clip&q=50)
+
+## Custom restrictions
 
 Specific user identifiers can be configured to always allow or deny an authentication attempt.
 Examples of using a custom restrictions: