@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/mfa/example-apps.mdx

@@ -1,10 +1,10 @@
 ---
 title: Example Apps
-description: "View sample Multi-Factor\_Auth apps for\_each\_SDK."
+description: View sample Multi-Factor Auth apps for each SDK.
 originalPath: .tmp-workos-clone/packages/docs/content/mfa/example-apps.mdx
 ---
 
-You can view minimal example apps that demonstrate how to use the WorkOS SDKs to authenticate users via MFA:
+You can view minimal example apps that demonstrate how to use the WorkOS SDKs to authenticate users via MFA:
 
 <ExampleApps.Root>
   <ExampleApps.Card

package/.docs/organized/docs/mfa/index.mdx

@@ -34,10 +34,10 @@ To get the most out of this guide, you’ll need:
 
 ## API object definitions
 
-[Authentication Factor](/reference/mfa/authentication-factor)
+[Authentication Factor](/reference/mfa/factor)
 : A factor of authentication that can be used in conjunction with a primary factor to provide multiple factors of authentication.
 
-[Authentication Challenge](/reference/mfa/authentication-challenge)
+[Authentication Challenge](/reference/mfa/challenge)
 : A request for an Authentication Factor to be verified.
 
 ## (1) Create an Authentication Factor

package/.docs/organized/docs/mfa/ux/enrollment.mdx

@@ -23,7 +23,7 @@ If a user has enrolled in multiple methods, consider letting them select a prima
 
 ## Setup a `totp` factor accessibly
 
-As we have previously seen, [when enrolling a `totp` factor using the MFA API](mfa/1-create-an-authentication-factor/enroll-the-authentication-factor), the response returns a `qr_code` and a `secret`.
+As we have previously seen, [when enrolling a `totp` factor using the MFA API](/mfa/1-create-an-authentication-factor/enroll-the-authentication-factor), the response returns a `qr_code` and a `secret`.
 
 The `qr_code` value can be passed directly to the source on an image tag as follows:
 

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

@@ -17,7 +17,7 @@ At the very least, assuming the user has enrolled in one method (e.g. SMS/Text m
 
 ## When the user has enrolled in multiple methods
 
-If the user has enrolled in multiple methods, consider including both methods in the verification step after they have entered their username and password. Following what we discussed in the [enrollment guide](mfa/ux/enrollment/let-users-choose-their-primary-method), consider presenting the user with their primary method first as well as letting them switch.
+If the user has enrolled in multiple methods, consider including both methods in the verification step after they have entered their username and password. Following what we discussed in the [enrollment guide](/mfa/ux/enrollment/let-users-choose-their-primary-method), consider presenting the user with their primary method first as well as letting them switch.
 
 <MfaSignInDemoMultipleMethods />
 

package/.docs/organized/docs/migrate/_navigation.mdx

@@ -1,6 +1,26 @@
 ---
 title: Migrations
-links: []
+links:
+  - title: Auth0
+    url: /migrate/auth0
+  - title: AWS Cognito
+    url: /migrate/aws-cognito
+  - title: Better Auth
+    url: /migrate/better-auth
+  - title: Clerk
+    url: /migrate/clerk
+  - title: Descope
+    url: /migrate/descope
+  - title: Firebase
+    url: /migrate/firebase
+  - title: Stytch
+    url: /migrate/stytch
+  - title: Supabase
+    url: /migrate/supabase
+  - title: Standalone SSO
+    url: /migrate/standalone-sso
+  - title: Other Services
+    url: /migrate/other-services
 originalPath: .tmp-workos-clone/packages/docs/content/migrate/_navigation.mdx
 ---
 

package/.docs/organized/docs/migrate/auth0.mdx

@@ -10,7 +10,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/migrate/auth0.mdx
 
 ## Introduction
 
-The WorkOS User Management API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through the steps to export, and then import your users from Auth0.
+The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through the steps to export, and then import your users from Auth0.
 
 ## (1) Exporting Auth0 user data
 
@@ -43,7 +43,7 @@ If you’d rather write your own code, the same process can be completed using t
 
 ### (B) Using WorkOS APIs
 
-With the data from Auth0’s “Bulk User Export” job, you can use the WorkOS [Create User API](/reference/user-management/user/create) to import each of the users. Using the default fields from the [Auth0 export](https://auth0.com/docs/customize/extensions/user-import-export-extension#export-users), use the following mapping from Auth0 to parameters in your WorkOS Create User API calls:
+With the data from Auth0’s “Bulk User Export” job, you can use the WorkOS [Create User API](/reference/authkit/user/create) to import each of the users. Using the default fields from the [Auth0 export](https://auth0.com/docs/customize/extensions/user-import-export-extension#export-users), use the following mapping from Auth0 to parameters in your WorkOS Create User API calls:
 
 | Auth0          |     | WorkOS API       |
 | -------------- | --- | ---------------- |
@@ -54,7 +54,7 @@ With the data from Auth0’s “Bulk User Export” job, you can use the WorkOS
 
 ### Importing passwords
 
-If you also exported passwords from Auth0, you can import them during the [user creation](/reference/user-management/user/create) process, or later using the WorkOS [Update User API](/reference/user-management/user/update).
+If you also exported passwords from Auth0, you can import them during the [user creation](/reference/authkit/user/create) process, or later using the WorkOS [Update User API](/reference/authkit/user/update).
 
 Auth0 uses the `bcrypt` password hashing algorithm, which is supported by WorkOS. Make sure to pass the following parameters to the WorkOS API:
 
@@ -85,7 +85,7 @@ If you’d like to export your Auth0 organizations, you can use the [Auth0 Manag
 
 ### Adding user memberships
 
-You can export Auth0 organization memberships using Auth0’s “Bulk User Export” as described in the [Exporting Auth0 user data](/migrate/auth0/1-exporting-auth0-user-data) step, and then use the WorkOS [Organization Membership API](/reference/user-management/organization-membership/create) to add each user to their respective organization.
+You can export Auth0 organization memberships using Auth0’s “Bulk User Export” as described in the [Exporting Auth0 user data](/migrate/auth0/1-exporting-auth0-user-data) step, and then use the WorkOS [Organization Membership API](/reference/authkit/organization-membership/create) to add each user to their respective organization.
 
 ## Multi-Factor Auth
 
@@ -95,4 +95,4 @@ Auth0 supports SMS-based second factors, however WorkOS does not due to known se
 
 ## Wrapping-up
 
-With your users now imported, you can now start using WorkOS to manage your Auth0 users. If you haven’t, take a look at our [Quick Start guide](/user-management) to learn how to integrate WorkOS User Management into your application.
+With your users now imported, you can now start using WorkOS to manage your Auth0 users. If you haven't, take a look at our [Quick Start guide](/authkit) to learn how to integrate WorkOS AuthKit into your application.

package/.docs/organized/docs/migrate/aws-cognito.mdx

@@ -1,6 +1,6 @@
 ---
 title: Migrate from AWS Cognito
-description: "Learn how to migrate users to\_WorkOS from AWS Cognito."
+description: Learn how to migrate users to WorkOS from AWS Cognito.
 icon: aws
 breadcrumb:
   title: Migrations
@@ -10,7 +10,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/migrate/aws-cognito.mdx
 
 ## Introduction
 
-The WorkOS User Management API allows you to migrate your existing user data from a variety of existing sources. In this guide, we’ll walk through the steps to export, and then import your users from AWS Cognito.
+The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources. In this guide, we’ll walk through the steps to export, and then import your users from AWS Cognito.
 
 > AWS Cognito does not offer exports of user password hashes or MFA keys. This means that your imported users will need to reset their passwords and reconfigure any required MFA.
 
@@ -89,7 +89,7 @@ After obtaining your user data from Cognito, it’s time to import them into Wor
 }
 ```
 
-Using the WorkOS [Create User API](/reference/user-management/user/create), you can create a corresponding record in WorkOS for each exported user. Use the following mapping from the AWS Cognito object to parameters in your WorkOS Create User API calls:
+Using the WorkOS [Create User API](/reference/authkit/user/create), you can create a corresponding record in WorkOS for each exported user. Use the following mapping from the AWS Cognito object to parameters in your WorkOS Create User API calls:
 
 | AWS Cognito     |     | WorkOS API       |
 | --------------- | --- | ---------------- |
@@ -104,7 +104,7 @@ Using the WorkOS [Create User API](/reference/user-management/user/create), you
 
 It’s important to have a strategy for triggering password resets after importing your users into WorkOS. You may want to ask users to reset their password the next time they attempt to sign in, or proactively send them password reset emails.
 
-In either case, you can trigger the password reset flow by using the WorkOS [Send Password Reset Email API](/reference/user-management/password-reset/create).
+In either case, you can trigger the password reset flow by using the WorkOS [Send Password Reset Email API](/reference/authkit/password-reset/create).
 
 ## Other authentication methods
 
@@ -112,4 +112,4 @@ In addition to migrating username and password users to WorkOS, you can migrate
 
 Ensure you use the same credentials (i.e. Client ID and Client Secret) in WorkOS as those used for your connection in AWS Cognito.
 
-For OAuth providers, you will need to add WorkOS as an additional Redirect URI. See the [Google OAuth integration guide](/integrations/google-oauth/customize-google-oauth-domain/3-add-new-redirect-uri-to-google) as an example of what this process looks like.
+For OAuth providers, you will need to add WorkOS as an additional Redirect URI. See the [Google OAuth integration guide](/integrations/google-oauth/customize-google-oauth-domain-optional/3-add-new-redirect-uri-to-google) as an example of what this process looks like.

package/.docs/organized/docs/migrate/better-auth.mdx

@@ -0,0 +1,282 @@
+---
+title: Migrate from Better Auth
+description: Learn how to migrate users and organizations from Better Auth.
+icon: better-auth
+breadcrumb:
+  title: Migrations
+  url: /migrate
+originalPath: .tmp-workos-clone/packages/docs/content/migrate/better-auth.mdx
+---
+
+## Introduction
+
+You can migrate your existing user data from a variety of sources into WorkOS using the AuthKit API. This guide will walk you through the steps to export your data from Better Auth, and import into WorkOS.
+
+---
+
+## (1) Export Better Auth data
+
+Better Auth stores user data directly in your database, which means you have full control over exporting your data. Unlike hosted authentication services, Better Auth does not provide a built-in export tool, but you can access your data directly through your database.
+
+### Accessing your database
+
+Better Auth uses [multiple database tables](https://www.better-auth.com/docs/concepts/database) to store authentication data. The main tables you'll need to export are:
+
+- **user**: Contains core user information (`id`, `name`, `email`, `emailVerified`, `image`, timestamps)
+- **account**: Stores provider-specific authentication data, including password hashes for credential-based accounts
+- **organization**: Available when using the [organization plugin](https://www.better-auth.com/docs/plugins/organization)
+- **member**: Mapping of users (and their roles) to organizations
+
+You can export this data using your database's native export tools, your ORM (for example, Prisma), or direct SQL queries.
+
+### Exporting user data
+
+To export users, query the `user` table directly.
+
+```sql
+SELECT * FROM user;
+```
+
+You can export this data to JSON, CSV, or any format that works for your migration script.
+
+### Exporting passwords
+
+Better Auth stores password hashes in the `account` table with `providerId` set to `'credential'`. The passwords are hashed using [scrypt by default](https://www.better-auth.com/docs/authentication/email-password), though Better Auth supports custom hashing functions.
+
+To export password hashes, query the `account` table:
+
+```sql
+SELECT userId, password
+FROM account
+WHERE providerId = 'credential';
+```
+
+If you're using a custom password hashing algorithm in Better Auth, make note of the algorithm for the import step. The default is `scrypt`, which is supported by WorkOS.
+
+---
+
+## (2) Import users into WorkOS
+
+Once you've exported your user data from Better Auth, you can import it into WorkOS using the WorkOS APIs.
+
+### Using WorkOS APIs
+
+With the data from your Better Auth database, you can use the [Create User API](/reference/authkit/user/create) to import each user. The API is rate-limited, so for large migrations, you may want to implement batching with appropriate delays. You can view the [rate limits](/reference/rate-limits) documentation for more information.
+
+Using the Better Auth user table schema, use the following mapping to Create User API parameters:
+
+| Better Auth     |     | WorkOS           |
+| --------------- | --- | ---------------- |
+| `email`         | →   | `email`          |
+| `emailVerified` | →   | `email_verified` |
+| `name`          | →   | `first_name`     |
+| `name`          | →   | `last_name`      |
+| `image`         | →   | (not supported)  |
+
+> Better Auth stores a single `name` field, while WorkOS has separate `first_name` and `last_name` fields. You'll need to parse the name field or use it entirely for `first_name`.
+
+Here's an example migration script:
+
+```typescript
+import { WorkOS } from '@workos-inc/node';
+
+const workos = new WorkOS(process.env.WORKOS_API_KEY);
+
+async function migrateUsers(betterAuthUsers) {
+  for (const user of betterAuthUsers) {
+    // Parse name into first and last name if possible
+    const [firstName, ...lastNameParts] = user.name.split(' ');
+    const lastName = lastNameParts.join(' ') || undefined;
+
+    try {
+      // In the JavaScript SDK, the property names are camelCase
+      const workosUser = await workos.userManagement.createUser({
+        email: user.email,
+        emailVerified: user.emailVerified,
+        firstName: firstName,
+        lastName: lastName,
+      });
+
+      console.log(`Migrated user: ${user.email} -> ${workosUser.id}`);
+    } catch (error) {
+      console.error(`Failed to migrate user ${user.email}:`, error);
+    }
+  }
+}
+```
+
+### Importing passwords
+
+If you exported password hashes from Better Auth, you can import them during the [user creation](/reference/authkit/user/create) process, or later using the [Update User API](/reference/authkit/user/update).
+
+Better Auth uses `scrypt` as the default password hashing algorithm, which is supported by WorkOS. Make sure to pass the following parameters:
+
+- The `password_hash_type` set to `'scrypt'`
+- The `password_hash` set to the password hash value from your Better Auth `account` table
+
+The password hash should be in PHC string format. If Better Auth is storing raw scrypt hashes, you'll need to convert them to PHC format. See the [other services migration guide](/migrate/other-services/2-importing-users-into-workos/importing-passwords) for detailed information about PHC format parameters for scrypt.
+
+If you configured Better Auth to use a different password hashing algorithm, such as bcrypt, argon2, or pbkdf2, WorkOS supports these as well. Refer to the [password hash types](/migrate/other-services/2-importing-users-into-workos/importing-passwords) documentation for format requirements.
+
+### Migrating social auth users
+
+If you have users who previously signed in through Better Auth using social auth providers, such as [Google](/integrations/google-oauth) or [Microsoft](/integrations/microsoft-oauth), those users can continue to sign in with those providers after you've migrated.
+
+Better Auth stores social auth accounts in the `account` table with different `providerId` values (e.g., `'google'`, `'github'`, `'microsoft'`). These accounts are linked to users via the `userId` field.
+
+Check out our [integrations](/integrations) page for guidance on configuring the relevant provider's client credentials. After your provider is configured, users can sign in with their provider credentials and will be automatically linked to a user. The **email address** from the social auth provider is used to determine this match.
+
+> Some users may need to verify their email address through WorkOS if email verification is enabled in your environment's authentication settings.
+
+Email verification behavior varies depending on whether the provider is known to verify email addresses. For example, users signing in using Google OAuth and a `gmail.com` email domain will not need to perform the extra verification step.
+
+---
+
+## (3) Organizations
+
+Better Auth has an [organization plugin](https://www.better-auth.com/docs/plugins/organization) that allows you to manage organization members and teams. If you're using this plugin, you can migrate your organizations to WorkOS, which has native support for [Organizations](/reference/organization) as a core B2B feature.
+
+### Creating Organizations
+
+Better Auth stores organizations in an `organization` table with fields like `id`, `name`, `slug`, `logo`, and `metadata`. To migrate these, you'll need to:
+
+1. Export organizations from your Better Auth database:
+
+```sql
+SELECT * FROM organization;
+```
+
+2. Create matching organizations using the [Create Organization API](/reference/organization/create):
+
+```typescript
+import { WorkOS } from '@workos-inc/node';
+
+const workos = new WorkOS(process.env.WORKOS_API_KEY);
+
+async function migrateOrganizations(betterAuthOrgs) {
+  for (const org of betterAuthOrgs) {
+    try {
+      const workosOrg = await workos.organizations.createOrganization({
+        name: org.name,
+        // You may want to store the Better Auth slug in organization metadata
+        metadata: {
+          betterAuthSlug: org.slug,
+        },
+      });
+
+      console.log(`Migrated organization: ${org.name} -> ${workosOrg.id}`);
+
+      // Store this mapping for migrating user memberships later
+      orgIdMap.set(org.id, workosOrg.id);
+    } catch (error) {
+      console.error(`Failed to migrate organization ${org.name}:`, error);
+    }
+  }
+}
+```
+
+### Adding organization memberships
+
+Better Auth stores organization memberships in a `member` table that links users (and their roles) to organizations.
+
+```sql
+SELECT * FROM member;
+```
+
+Then use the [Organization Membership API](/reference/authkit/organization-membership/create) to add each user to their respective organization.
+
+WorkOS offers RBAC capabilities through [roles and permissions](/authkit/roles-and-permissions). When migrating, identify your roles defined in Better Auth, then create equivalent roles in the WorkOS Dashboard, and assign roles during migration by specifying the `roleSlug` parameter when creating organization memberships. If your Better Auth implementation uses complex RBAC policies with custom resources and actions, you may need to simplify to standard roles or implement custom authorization in your application logic.
+
+```typescript
+async function migrateMemberships(betterAuthMemberships, orgIdMap, userIdMap) {
+  for (const membership of betterAuthMemberships) {
+    const orgId = orgIdMap.get(membership.organizationId);
+    const userId = userIdMap.get(membership.userId);
+
+    if (!orgId || !userId) {
+      console.error(`Missing mapping for membership: ${membership.id}`);
+      continue;
+    }
+
+    try {
+      await workos.userManagement.createOrganizationMembership({
+        userId: userId,
+        organizationId: orgId,
+        // Better Auth uses custom role strings; map these to WorkOS roles as needed
+        roleSlug: getRole(membership.role),
+      });
+
+      console.log(`Migrated membership: ${membership.userId} -> ${orgId}`);
+    } catch (error) {
+      console.error(`Failed to migrate membership:`, error);
+    }
+  }
+}
+```
+
+### Migrating teams
+
+If you're using the teams feature within Better Auth (an optional hierarchical level within organizations), note that there is not a directly corresponding "teams" concept. However, you have several options:
+
+1. **Convert to organizations**: Create separate organizations for each Better Auth team
+2. **Use organization metadata**: Store team information in organization metadata
+3. **Use RBAC roles**: Represent team membership through custom roles in [role-based access control](/rbac/quick-start)
+
+For most B2B applications, flattening teams into separate organizations provides the cleanest migration path and takes full advantage of enterprise features like SSO and Directory Sync, which operate at the organization level.
+
+---
+
+## (4) Special considerations
+
+There are several differences between Better Auth and WorkOS that you should be aware of during migration.
+
+### Multi-Factor Authentication
+
+Better Auth offers a [Two-Factor Authentication plugin](https://www.better-auth.com/docs/plugins/2fa) that supports TOTP-based authenticators. If your Better Auth users have enrolled in 2FA, they will need to re-enroll in MFA after migrating, as MFA secrets cannot be migrated for security reasons. See the [MFA guide](/authkit/mfa) for information on enrolling users in MFA.
+
+> WorkOS does not support SMS-based factors due to known security vulnerabilities with SMS.
+
+### Account linking behavior
+
+Better Auth has sophisticated [account linking capabilities](https://www.better-auth.com/docs/concepts/users-accounts#account-linking) that automatically link social accounts with matching verified email addresses. WorkOS also supports automatic account linking based on email addresses. When migrating users who have multiple linked accounts in Better Auth (e.g., password + Google OAuth), you should:
+
+1. Import the user once with their primary email
+2. Configure the relevant social providers
+3. When users sign in with their social provider, they will automatically be linked with the accounts based on email match
+
+### Handling interim new users
+
+If your application allows users to sign up at any time, you should [consider the timing of your migration](/migrate/other-services/3-handling-interim-new-users). Users who sign up after you've exported data from Better Auth but before you've switched to WorkOS for authentication will be omitted from the migration.
+
+There are two main strategies to handle this:
+
+#### (A) Disable signups during migration
+
+Schedule an appropriate time for the migration and temporarily disable signup functionality. This can be controlled using a feature flag in your application. After the migration is complete and your application is using WorkOS for authentication, re-enable signups.
+
+#### (B) Use a dual-write strategy
+
+For applications that cannot disable signups, implement a "dual-write" strategy. When a new user signs up, create records in both your Better Auth database and WorkOS using the [Create User API](/reference/authkit/user/create). This keeps WorkOS synchronized with new users, though you'll still need to perform the historical user migration. Be aware that you'll need to keep user updates (email changes, password changes) synchronized between both systems until the migration is complete.
+
+### Database-specific considerations
+
+Since Better Auth stores data in your own database, you have flexibility in how you structure the migration:
+
+- You can keep Better Auth tables in your database during a transition period
+- Consider implementing a gradual rollout where some users authenticate via WorkOS while others continue using Better Auth
+- Database schema is extensible, so custom fields will need to be handled separately (consider using [user metadata](/authkit/metadata) for custom data)
+
+---
+
+## Next steps
+
+With your users and organizations now imported, you can start using WorkOS to manage authentication for your application. If you haven't already, take a look at our [Quick Start guide](/authkit) to learn how to integrate AuthKit into your application.
+
+These enterprise-ready features go beyond basic authentication:
+
+- **[Single Sign-On](/sso)**: Enable SAML and OIDC SSO for enterprise customers
+- **[Directory Sync](/directory-sync)**: Automatically provision and deprovision users from identity providers
+- **[Admin Portal](/admin-portal)**: Allow your customers to self-serve SSO and Directory Sync configuration
+- **[Audit Logs](/audit-logs)**: Track security-relevant events in your application
+
+If you have questions about your migration or need assistance, reach out to [support@workos.com](mailto:support@workos.com).

package/.docs/organized/docs/migrate/clerk.mdx

@@ -10,7 +10,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/migrate/clerk.mdx
 
 ## Introduction
 
-The WorkOS User Management API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through the steps to export, and then import your users from Clerk.
+The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through the steps to export, and then import your users from Clerk.
 
 ---
 
@@ -20,9 +20,7 @@ Clerk allows for exporting user data [directly from their API](https://clerk.com
 
 ### Export passwords
 
-If your Clerk users currently sign in using password-based authentication, and you'd like to import those passwords into WorkOS, then you'll need to [contact Clerk support](https://clerk.com/support).
-
-After opening a ticket with Clerk, it can take up to a week or more for your request to be processed. At the end you’ll be given a JSON file that includes user data and hashed passwords.
+If your Clerk users currently sign in using password-based authentication, and you'd like to import those passwords into WorkOS, then you'll need to use the [Clerk backend API](https://clerk.com/changelog/2024-10-23-export-users) to export them with your user data as a CSV file.
 
 > Clerk does not make the plaintext passwords available for export.
 
@@ -40,7 +38,7 @@ If you’d rather write your own code, or if you chose to not export data via Cl
 
 ### (B) Using WorkOS APIs
 
-Using the data either from the Clerk API or from a JSON file received from their support team, you can use the WorkOS API to [create users](/reference/user-management/user/create) during the import. Keep in mind that user creation is rate-limited. You can view the docs on the [rate limits](/reference/rate-limits) for more information.
+Using the data either from the Clerk API or from a JSON file received from their support team, you can use the WorkOS API to [create users](/reference/authkit/user/create) during the import. Keep in mind that user creation is rate-limited. You can view the docs on the [rate limits](/reference/rate-limits) for more information.
 
 Using the default fields from the [Clerk export](https://clerk.com/docs/deployments/exporting-users), use the following mapping from Clerk to parameters in your WorkOS Create User API calls:
 
@@ -62,7 +60,7 @@ Unfortunately there's no way to know which email is the primary one from the exp
 
 ### Import passwords
 
-If you also exported passwords from Clerk, you can import them during the [user creation](/reference/user-management/user/create) process, or later using the WorkOS [Update User API](/reference/user-management/user/update).
+If you also exported passwords from Clerk, you can import them during the [user creation](/reference/authkit/user/create) process, or later using the WorkOS [Update User API](/reference/authkit/user/update).
 
 Clerk uses the `bcrypt` password hashing algorithm, which is supported by WorkOS. Make sure to pass the following parameters to the WorkOS API:
 
@@ -79,7 +77,7 @@ After your provider is configured in WorkOS, users can sign in with their provid
 
 ---
 
-### (3) Create organizations
+## (3) Create organizations
 
 Clerk’s [organizations](https://clerk.com/docs/organizations/overview) are analogous to WorkOS [organizations](/reference/organization) – both represent a B2B customer.
 
@@ -89,18 +87,18 @@ If you’d like to export your Clerk organizations, you can use the [Clerk Backe
 
 ### Adding user memberships
 
-You can export Clerk organization memberships using Clerk’s [Backend SDK](https://clerk.com/docs/references/backend/organization/get-organization-membership-list), and then use the WorkOS [Organization Membership API](/reference/user-management/organization-membership/create) to add each user to their respective organization.
+You can export Clerk organization memberships using Clerk’s [Backend SDK](https://clerk.com/docs/references/backend/organization/get-organization-membership-list), and then use the WorkOS [Organization Membership API](/reference/authkit/organization-membership/create) to add each user to their respective organization.
 
 ---
 
-### (4) Multi-Factor Auth
+## (4) Multi-Factor Auth
 
 There are some differences between the MFA strategies offered by Clerk and WorkOS.
 
-Clerk supports SMS-based second factors, however WorkOS does not due to known security issues with SMS. Users who have SMS-based second factors will need to switch to using email-based Magic Auth, or re-enroll in MFA using a TOTP-based authenticator instead. See the [MFA guide](/user-management/mfa) for more information on enrolling users.
+Clerk supports SMS-based second factors, however WorkOS does not due to known security issues with SMS. Users who have SMS-based second factors will need to switch to using email-based Magic Auth, or re-enroll in MFA using a TOTP-based authenticator instead. See the [MFA guide](/authkit/mfa) for more information on enrolling users.
 
 ---
 
 ## Next steps
 
-After the import, you can now start using WorkOS to manage your users. If you haven’t, take a look at the [Quick Start guide](/user-management) to learn how to integrate WorkOS User Management into your application.
+After the import, you can now start using WorkOS to manage your users. If you haven't, take a look at our [Quick Start guide](/authkit) to learn how to integrate WorkOS AuthKit into your application.