@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/migrate/descope.mdx

@@ -0,0 +1,290 @@
+---
+title: Migrate from Descope
+description: Learn how to migrate users and organizations from Descope.
+icon: descope
+breadcrumb:
+  title: Migrations
+  url: /migrate
+originalPath: .tmp-workos-clone/packages/docs/content/migrate/descope.mdx
+---
+
+## Introduction
+
+The 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 Descope.
+
+---
+
+## (1) Export Descope data
+
+Descope allows you to export user data through their [Management API](https://docs.descope.com/api/management/users) or directly from the Descope console.
+
+You can export user data programmatically using the [Search Users endpoint](https://docs.descope.com/management/user-management/user-exporting). The `searchAll()` function in the Descope Backend SDKs retrieves a comprehensive list of users. Submitting an empty request payload will return all users:
+
+```bash
+curl -X POST https://api.descope.com/v1/mgmt/user/search \
+  -H 'Authorization: Bearer <ProjectId>:<ManagementKey>' \
+  -H 'Content-Type: application/json' \
+  -d '{}'
+```
+
+Alternatively, you can export users directly from the [Descope console](https://docs.descope.com/management/user-management/user-exporting) by selecting users on the users page and clicking the "Export CSV" button.
+
+### Exporting passwords
+
+If your Descope users currently sign in using password-based authentication, and you'd like to import those passwords, you'll need to [contact Descope support](https://docs.descope.com/management/user-management/user-exporting).
+
+Descope does not make hashed passwords available through their Backend APIs. After opening a support ticket, Descope can generate a CSV file containing your users' data including password hashes and facilitate a secure data transfer.
+
+Descope supports multiple password hashing algorithms including bcrypt, argon2, pbkdf2, and others. When you receive the password export from Descope support, make note of which hashing algorithm was used, as you'll need this information when importing.
+
+---
+
+## (2) Import users into WorkOS
+
+Once you've obtained the necessary export data from Descope, you can import your users into WorkOS using the WorkOS APIs.
+
+### Using WorkOS APIs
+
+With the data from Descope's user export, 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 fields from the Descope export, use the following mapping from Descope to parameters in your Create User API calls:
+
+| Descope         |     | WorkOS API       |
+| --------------- | --- | ---------------- |
+| `email`         | →   | `email`          |
+| `givenName`     | →   | `first_name`     |
+| `familyName`    | →   | `last_name`      |
+| `verifiedEmail` | →   | `email_verified` |
+
+Here's an example migration script:
+
+### Import passwords
+
+If you also exported passwords from Descope support, you can import them during the [user creation](/reference/authkit/user/create) process, or later using the [Update User API](/reference/authkit/user/update).
+
+WorkOS supports the following password hashing algorithms that Descope uses:
+
+- `bcrypt`
+- `argon2`
+- `pbkdf2`
+
+When importing passwords, pass the following parameters to the WorkOS API based on the hash format Descope provided:
+
+- The `password_hash_type` set to the appropriate algorithm (e.g., `'bcrypt'`, `'argon2'`, or `'pbkdf2'`)
+- The `password_hash` set to the password hash value from your Descope export
+
+For `argon2` and `pbkdf2` passwords, WorkOS expects the PHC string format. Refer to the [other services migration guide](/migrate/other-services/2-importing-users-into-workos/importing-passwords) for detailed formatting requirements for these hash types.
+
+- | Without passwords
+
+  ```typescript
+  import { WorkOS } from '@workos-inc/node';
+
+  const workos = new WorkOS(process.env.WORKOS_API_KEY);
+
+  async function migrateUsers(descopeUsers) {
+    for (const user of descopeUsers) {
+      try {
+        // In the JavaScript SDK, the property names are camelCase
+        const workosUser = await workos.userManagement.createUser({
+          email: user.email,
+          emailVerified: user.verifiedEmail,
+          firstName: user.givenName,
+          lastName: user.familyName,
+        });
+
+        console.log(`Migrated user: ${user.email} -> ${workosUser.id}`);
+      } catch (error) {
+        console.error(`Failed to migrate user ${user.email}:`, error);
+      }
+    }
+  }
+  ```
+
+- | With passwords
+
+  ```typescript
+  import { WorkOS } from '@workos-inc/node';
+
+  const workos = new WorkOS(process.env.WORKOS_API_KEY);
+
+  async function migrateUsersWithPasswords(descopeUsers) {
+    for (const user of descopeUsers) {
+      try {
+        const workosUser = await workos.userManagement.createUser({
+          email: user.email,
+          emailVerified: user.verifiedEmail,
+          firstName: user.givenName,
+          lastName: user.familyName,
+          // Include password hash if available from Descope export
+          passwordHash: user.passwordHash,
+          passwordHashType: user.passwordHashType, // 'bcrypt', 'argon2', or 'pbkdf2'
+        });
+
+        console.log(
+          `Migrated user with password: ${user.email} -> ${workosUser.id}`,
+        );
+      } catch (error) {
+        console.error(`Failed to migrate user ${user.email}:`, error);
+      }
+    }
+  }
+  ```
+
+### Migrate social auth users
+
+If you have users who previously signed in through Descope 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.
+
+Check out the [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 WorkOS user. WorkOS uses the **email address** from the social auth provider 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
+
+Descope has a concept of ["Tenants"](https://docs.descope.com/b2b) which are analogous to [WorkOS Organizations](/reference/organization), in that both represent a B2B customer or organization within your application.
+
+### Creating Organizations
+
+If you'd like to export your Descope tenants, you can use the [Descope Management API](https://docs.descope.com/management/tenant-management/sdks) to programmatically retrieve each tenant. You can then call the [Create Organization API](/reference/organization/create) to create matching Organizations in WorkOS.
+
+When creating Organizations in WorkOS, you can map the following fields from Descope tenants:
+
+| Descope Tenant |     | WorkOS Organization |
+| -------------- | --- | ------------------- |
+| `name`         | →   | `name`              |
+| `id`           | →   | `external_id`       |
+
+Storing the Descope tenant ID as the `external_id` in WorkOS can help you maintain a reference between the two systems during migration.
+
+Here's an example migration script:
+
+```typescript
+import { WorkOS } from '@workos-inc/node';
+
+const workos = new WorkOS(process.env.WORKOS_API_KEY);
+
+async function migrateOrganizations(descopeTenants) {
+  const orgIdMap = new Map();
+
+  for (const tenant of descopeTenants) {
+    try {
+      const workosOrg = await workos.organizations.createOrganization({
+        name: tenant.name,
+        // Store the Descope tenant ID for reference
+        externalId: tenant.id,
+      });
+
+      console.log(`Migrated organization: ${tenant.name} -> ${workosOrg.id}`);
+
+      // Store this mapping for migrating user memberships later
+      orgIdMap.set(tenant.id, workosOrg.id);
+    } catch (error) {
+      console.error(`Failed to migrate organization ${tenant.name}:`, error);
+    }
+  }
+
+  return orgIdMap;
+}
+```
+
+### Adding user memberships
+
+Once you've created Organizations in WorkOS, you can add users to their respective organizations using the [Organization Membership API](/reference/authkit/organization-membership/create).
+
+In Descope, users can be associated with tenants, and this information is available when you export users via the Search Users API. Use this tenant association data to create the corresponding organization memberships in WorkOS.
+
+RBAC capabilities are available through [roles and permissions](/authkit/roles-and-permissions). When migrating, identify your roles defined in Descope, then create equivalent roles in [the dashboard](https://dashboard.workos.com/environment/authorization), and assign roles during migration by specifying the `roleSlug` parameter when creating organization memberships.
+
+```typescript
+async function migrateMemberships(descopeUserTenants, orgIdMap, userIdMap) {
+  for (const userTenant of descopeUserTenants) {
+    const orgId = orgIdMap.get(userTenant.tenantId);
+    const userId = userIdMap.get(userTenant.userId);
+
+    if (!orgId || !userId) {
+      console.error(`Missing mapping for user-tenant relationship`);
+      continue;
+    }
+
+    try {
+      await workos.userManagement.createOrganizationMembership({
+        userId: userId,
+        organizationId: orgId,
+        // Map Descope roles to WorkOS roles as needed
+        roleSlug: userTenant.roleNames?.[0] || 'member',
+      });
+
+      console.log(`Migrated membership: ${userId} -> ${orgId}`);
+    } catch (error) {
+      console.error(`Failed to migrate membership:`, error);
+    }
+  }
+}
+```
+
+---
+
+## (4) Special considerations
+
+There are some differences between the authentication strategies offered by Descope and WorkOS that you should be aware of when planning your migration.
+
+### Multi-Factor Auth
+
+Descope supports SMS-based one-time passwords (OTP) for authentication and multi-factor auth. However, WorkOS does not support SMS-based second factors due to known security issues with SMS.
+
+Users who have SMS-based authentication or second factors will need to switch to using [email-based Magic Auth](/authkit/magic-auth), or re-enroll in MFA using a [TOTP-based authenticator](/authkit/mfa) instead.
+
+### Passkeys and advanced authentication
+
+Descope supports [passkeys](https://docs.descope.com/auth-methods/passkeys) (WebAuthn) for passwordless authentication. [Passkey authentication](/authkit/passkeys) is also available through AuthKit's hosted UI, using the WebAuthn standard. Passkeys offer:
+
+- **Progressive enrollment**: Users with password-based accounts can be prompted to create passkeys
+- **MFA integration**: Passkeys serve as both first and second factors when MFA is enabled
+- **Secure authentication**: Using biometric or PIN verification on the user's device
+
+Note that passkey authentication is currently available through the hosted UI. You'll need to configure a custom domain for your AuthKit environment before enabling passkeys in production.
+
+Descope also offers other authentication methods like Magic Links and Enchanted Links. [Magic Auth](/authkit/magic-auth) delivers a similar passwordless email-based authentication experience.
+
+### Enterprise SSO and SCIM
+
+Both Descope and WorkOS provide robust enterprise authentication features. If you're currently using Descope's [SSO](https://docs.descope.com/auth-methods/sso) or [SCIM provisioning](https://docs.descope.com/b2b/scim) features, WorkOS offers equivalent capabilities:
+
+- [Single Sign-On (SSO)](/sso) - Support for SAML and OIDC providers
+- [Directory Sync](/directory-sync) - SCIM-based user provisioning from identity providers
+
+When migrating enterprise customers who use SSO, you'll need to coordinate with them to reconfigure their Identity Provider (IdP) to point to WorkOS instead of Descope. WorkOS provides [comprehensive documentation](/sso) for setting up SSO connections with various providers.
+
+### Account linking behavior
+
+Descope has account linking capabilities 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 Descope (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 Descope 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 Descope project 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.
+
+---
+
+## Next steps
+
+With your users now imported, you can start using WorkOS to manage authentication for your application. If you haven't already, take a look at the [AuthKit Quick Start guide](/authkit) to learn how to integrate AuthKit into your application.

package/.docs/organized/docs/migrate/firebase.mdx

@@ -10,7 +10,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/migrate/firebase.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 your users from Firebase, and then import them into WorkOS.
+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 your users from Firebase, and then import them into WorkOS.
 
 ## (1) Exporting Firebase user data
 
@@ -24,7 +24,7 @@ firebase auth:export --project=<your_firebase_project_id> --format=json users.js
 
 After obtaining your user data from Firebase, it’s time to import it into WorkOS, mapping attributes from the [Firebase User format](https://firebase.google.com/docs/cli/auth#JSON) to WorkOS API parameters.
 
-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 Firebase format 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 Firebase format to parameters in your WorkOS Create User API calls:
 
 | Firebase        |     | WorkOS API       |
 | --------------- | --- | ---------------- |
@@ -35,7 +35,7 @@ Using the WorkOS [Create User API](/reference/user-management/user/create), you
 
 ### Importing passwords
 
-If your users sign in to your Firebase application using passwords, you can choose to also import those password hashes. Firebase uses a [forked version of `scrypt`](https://firebaseopensource.com/projects/firebase/scrypt/) which can be directly imported during the [user creation](/reference/user-management/user/create) process into WorkOS, or later using the [Update User API](/reference/user-management/user/update).
+If your users sign in to your Firebase application using passwords, you can choose to also import those password hashes. Firebase uses a [forked version of `scrypt`](https://firebaseopensource.com/projects/firebase/scrypt/) which can be directly imported during the [user creation](/reference/authkit/user/create) process into WorkOS, or later using the [Update User API](/reference/authkit/user/update).
 
 First, retrieve your Firebase project's password hash parameters from the Firebase console following the [export documentation](https://firebase.google.com/docs/cli/auth#password_hash_parameters). These parameters are the `base64_signer_key`, `base64_salt_separator`, `rounds`, and `mem_cost`.
 
@@ -71,7 +71,7 @@ Reach out to [support@workos.com](mailto:support@workos.com) if there are additi
 
 ### Email Link
 
-If your users sign in using [Email Link](https://firebase.google.com/docs/auth/web/email-link-auth), sometimes called “passwordless”, you can achieve the same experience by adding WorkOS [Magic Auth](/reference/user-management/magic-auth) to your application.
+If your users sign in using [Email Link](https://firebase.google.com/docs/auth/web/email-link-auth), sometimes called “passwordless”, you can achieve the same experience by adding WorkOS [Magic Auth](/reference/authkit/magic-auth) to your application.
 
 ### OIDC and SAML
 

package/.docs/organized/docs/migrate/other-services.mdx

@@ -9,7 +9,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/migrate/other-services.mdx
 
 ## Introduction
 
-The WorkOS User Management API allows you to migrate your existing user data from a variety of sources. In this guide, we’ll walk through the steps to export, and then import users from your own data store.
+The WorkOS AuthKit API allows you to migrate your existing user data from a variety of sources. In this guide, we'll walk through the steps to export, and then import users from your own data store.
 
 ## (1) Exporting data
 
@@ -20,7 +20,7 @@ While moving authentication related metadata to WorkOS, most applications will c
 | Email               | The user’s email address. Used for various authentication and verification purposes.                                           | Required |
 | First Name          | The user’s first, or given name.                                                                                               | Optional |
 | Last Name           | The user’s last, or family name.                                                                                               | Optional |
-| Verification Status | The user’s email verification status if they have gone through a verification flow. Assumed as “not verified” unless supplied. | Optional |
+| Verification Status | The user’s email verification status if they have gone through a verification flow. Assumed as “not verified” unless supplied. | Optional |
 | Password            | The user’s password hash, if they use password-based authentication.                                                           | Optional |
 
 While preparing the migration, you’ll want to ensure this information is programmatically available for use in the import step, this can mean:
@@ -38,7 +38,7 @@ Now that the User data is available, we can import it into WorkOS.
 
 ### Creating users
 
-For each of your users, you can call the WorkOS [Create User API](/reference/user-management/user/create). This will create a matching [User object](/reference/user-management/user) within WorkOS.
+For each of your users, you can call the WorkOS [Create User API](/reference/authkit/user/create). This will create a matching [User object](/reference/authkit/user) within WorkOS.
 
 A successful response will include a new WorkOS user ID, most apps will want to persist this WorkOS user ID alongside the application-local user object.
 
@@ -63,7 +63,7 @@ There are now several options on how to proceed, depending on your application
 
 ### Importing passwords
 
-If your users currently use password-based authentication, you can import existing password hashes during the [users creation](/reference/user-management/user/create) process, or later using the WorkOS [Update User API](/reference/user-management/user/update).
+If your users currently use password-based authentication, you can import existing password hashes during the [users creation](/reference/authkit/user/create) process, or later using the WorkOS [Update User API](/reference/authkit/user/update).
 
 WorkOS currently supports the following password hashing algorithms:
 
@@ -72,6 +72,7 @@ WorkOS currently supports the following password hashing algorithms:
 - `firebase-scrypt`
 - `ssha`
 - `pbkdf2`
+- `argon2`
 
 For `scrypt` and `pbkdf2` passwords, use the PHC string format.
 The hash and salt should be B64 encoded: trim the `=` characters that represent Base64 padding. Using a PHC-formatting library, like
@@ -109,6 +110,24 @@ A valid `pbkdf2` PHC formatted string looks like this:
 $pbkdf2$i=600000,d=sha256$T2ptRFh6MXhDQVh2SWZuUGdpQXBUTg$xXiyTisD7390NijyCv5ICMhFW4eDuMlzypRoLGLyIvA
 ```
 
+#### argon2
+
+| `argon2` value |     | PHC hash parameter |
+| -------------- | --- | ------------------ |
+| `variant`      | →   | algorithm id       |
+| `version`      | →   | `v`                |
+| `memory`       | →   | `m`                |
+| `time`         | →   | `t`                |
+| `parallelism`  | →   | `p`                |
+
+The variant should be `argon2id`, but older supported variants include `argon2d` and `argon2i`. The version must be `19`. The following memory, time (iterations), and parallelism settings are based on [OWASP recommendations](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id). Memory is specified in KiB with a minimum of 4,096 KiB (4 MiB) and maximum of 262,144 KiB (256 MiB). For time, there is a minimum of 1 iteration and a maximum of 5 iterations, except for `argon2i` which has a minimum of 3 iterations. Parallelism ranges from 1 to 8 threads. If your requirements fall outside of these guidelines, please [contact support](mailto:support@workos.com).
+
+A valid `argon2` PHC formatted string looks like this:
+
+```txt
+$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG
+```
+
 For `firebase-scrypt` passwords, refer to the [Firebase Migration guide](/migrate/firebase) for an example of how to format the `password_hash`.
 
 For `ssha` passwords, use the following algorithm:
@@ -124,7 +143,7 @@ Once imported, users can continue to sign-in with their existing password, **wit
 
 ### Triggering password resets
 
-If you are unable to export passwords from your existing data store, whether for security reasons or other limitations, you can programmatically trigger a password reset flow using the WorkOS [Password Reset API](/reference/user-management/password-reset).
+If you are unable to export passwords from your existing data store, whether for security reasons or other limitations, you can programmatically trigger a password reset flow using the WorkOS [Password Reset API](/reference/authkit/password-reset).
 
 This process can be initiated at any time, and doesn’t need to happen during the user import process.
 
@@ -162,7 +181,7 @@ For applications that want to avoid disabling signups, a “dual-write” strate
 
 ![Diagram demonstrating the dual-write process.](https://images.workoscdn.com/images/656fbbac-adb1-4f99-b416-056d80e408ac.png?auto=format&fit=clip&q=80)[border=false]
 
-When a new user signs-up, in addition to creating a user record in the existing user store, the application should also create a matching record in WorkOS using the [Create User API](/reference/user-management/user/create). As time passes, WorkOS will stay consistent with future new users, but a migration will still need to be performed for the historical set of users.
+When a new user signs-up, in addition to creating a user record in the existing user store, the application should also create a matching record in WorkOS using the [Create User API](/reference/authkit/user/create). As time passes, WorkOS will stay consistent with future new users, but a migration will still need to be performed for the historical set of users.
 
 You will need to perform the same export and import process into WorkOS, but keeping in mind that some users will already exist in WorkOS as a result from the “dual-write”.
 

package/.docs/organized/docs/migrate/standalone-sso.mdx

@@ -9,23 +9,23 @@ originalPath: .tmp-workos-clone/packages/docs/content/migrate/standalone-sso.mdx
 
 ## Introduction
 
-The WorkOS User Management API supports all of the same social and enterprise identity providers, while providing higher level authentication features that most applications need. In this guide, we’ll outline the steps to migrate an existing WorkOS SSO integration to the User Management API.
+The WorkOS AuthKit API supports all of the same social and enterprise identity providers, while providing higher level authentication features that most applications need. In this guide, we'll outline the steps to migrate an existing WorkOS SSO integration to the AuthKit API.
 
 > The existing standalone [WorkOS SSO API](/reference/sso) will continue to be supported. This is a viable option for you if you prefer to handle more of the authentication flow yourself.
 
 ## The new User resource
 
-The primary difference between existing integrations with [SSO](/sso) or [Directory Sync](/directory-sync) is the addition of a new resource: [Users](/reference/user-management/user).
+The primary difference between existing integrations with [SSO](/sso) or [Directory Sync](/directory-sync) is the addition of a new resource: [Users](/reference/authkit/user).
 
-The WorkOS [User object](/reference/user-management/user) represents a single user in your application, and binds together information from all of the Directory and Identity providers that WorkOS supports into a single resource. As you migrate your existing integration, you can expect to replace references to WorkOS Profiles and Directory Users with instead references to Users.
+The WorkOS [User object](/reference/authkit/user) represents a single user in your application, and binds together information from all of the Directory and Identity providers that WorkOS supports into a single resource. As you migrate your existing integration, you can expect to replace references to WorkOS Profiles and Directory Users with instead references to Users.
 
-## Switch to User Management API calls
+## Switch to AuthKit API calls
 
-If you have built an integration with our standalone SSO API using [Get Authorization URL](/reference/sso/get-authorization-url), you will need to switch these calls with analogous calls to the User Management API.
+If you have built an integration with our standalone SSO API using [Get Authorization URL](/reference/sso/get-authorization-url), you will need to switch these calls with analogous calls to the AuthKit API.
 
 ### (1) Switch SSO initiation call
 
-When initiating SSO for one of your users, instead of calling the SSO [Get Authorization URL](/reference/sso/get-authorization-url) API, call the User Management [Get Authorization URL](/reference/user-management/authentication/get-authorization-url) API instead:
+When initiating SSO for one of your users, instead of calling the SSO [Get Authorization URL](/reference/sso/get-authorization-url) API, call the AuthKit [Get Authorization URL](/reference/authkit/authentication/get-authorization-url) API instead:
 
 <CodeBlock title="Update Initiation Calls">
   <CodeBlockTab
@@ -40,13 +40,13 @@ When initiating SSO for one of your users, instead of calling the SSO [Get Autho
   />
 </CodeBlock>
 
-The User Management Get Authorization API supports all of the same initiation parameters as the old API. In addition, it also supports an additional provider type, `authkit`, which will be covered later in this guide.
+The AuthKit Get Authorization API supports all of the same initiation parameters as the SSO API. In addition, it also supports an additional provider type, `authkit`, which will be covered later in this guide.
 
 ### (2) Switch API in Application Callback
 
 Similar to an SSO integration, your application will still have a callback identified by the Redirect URI passed during the previous initiation call. The contract with your callback is the same, where you should expect to be given a `code`, along with any `state` that was originally provided.
 
-However, instead of calling the SSO [Get a Profile and Token](/reference/sso/profile/get-profile-and-token) API, call the User Management [Authenticate](/reference/user-management/authentication) API instead, with the `grant_type` set to `authorization_code`:
+However, instead of calling the SSO [Get a Profile and Token](/reference/sso/profile/get-profile-and-token) API, call the AuthKit [Authenticate](/reference/authkit/authentication) API instead, with the `grant_type` set to `authorization_code`:
 
 <CodeBlock title="Update Application Callback">
   <CodeBlockTab
@@ -61,13 +61,13 @@ However, instead of calling the SSO [Get a Profile and Token](/reference/sso/pro
   />
 </CodeBlock>
 
-> **Important:** Instead of receiving a [Profile](/reference/sso/profile), your application now receives a full [User object](/reference/user-management/user). While many of the fields are similar, such as the user’s email or name, the **User ID’s will be different** than the Profile ID’s you may have previously persisted in your application.
+> **Important:** Instead of receiving a [Profile](/reference/sso/profile), your application now receives a full [User object](/reference/authkit/user). While many of the fields are similar, such as the user’s email or name, the **User ID’s will be different** than the Profile ID’s you may have previously persisted in your application.
 
-If email is a unique identifier in your application, you can use the WorkOS User’s email to identify the application-local user. WorkOS ensures that user email is verified before successfully completing an authentication request. When the API issues an email verification challenge, an [email verification response](/reference/user-management/authentication-errors/email-verification-required-error) is returned.
+If email is a unique identifier in your application, you can use the WorkOS User’s email to identify the application-local user. WorkOS ensures that user email is verified before successfully completing an authentication request. When the API issues an email verification challenge, an [email verification response](/reference/authkit/authentication-errors/email-verification-required-error) is returned.
 
 ### Handling new authentication flows
 
-The User Management API offers a higher-level abstraction than the SSO API, offering more advanced [security features](/user-management/overview/security) like email verification and account Linking.
+The AuthKit API offers a higher-level abstraction than the SSO API, offering more advanced [security features](/authkit/overview/security) like email verification and account Linking.
 
 This means that when your application attempts to exchange a code for a user object, it may return one of several new expected errors. These map to cases that were previously mentioned, like requiring that the user first verify their email, or enroll in MFA.
 
@@ -77,7 +77,7 @@ If your application doesn’t require these extra settings, they can be disabled
 
 ## AuthKit
 
-If you prefer to have full control over the authentication UI, you can choose to integrate with the User Management API directly. However, the easiest way to get started is to use AuthKit, a pre-built hosted authentication UI that supports guiding users through all of the advanced flows, like email verification, MFA enrollment + verification, and identity linking.
+If you prefer to have full control over the authentication UI, you can choose to integrate with the AuthKit API directly. However, the easiest way to get started is to use AuthKit Hosted UI, a pre-built hosted authentication UI that guides users through all of the advanced flows, like email verification and MFA enrollment.
 
 You can enable AuthKit from the WorkOS dashboard, where you can also configure AuthKit branding and custom domains.
 
@@ -96,10 +96,10 @@ AuthKit can handle many of the concerns your application likely needed to previo
 
 ## Directory Sync
 
-Directory provisioning is also supported in User Management. See the [Directory Provisioning documentation](/user-management/directory-provisioning) to learn more.
+Directory provisioning is also supported in AuthKit. See the [Directory Provisioning documentation](/authkit/directory-provisioning) to learn more.
 
 ## Next Steps
 
-Check out the [full guide](/user-management), along with the [API reference](/reference/user-management) to get an idea of all the ways your application’s user management needs can be solved by WorkOS.
+Check out the [full guide](/authkit), along with the [API reference](/reference/authkit) to get an idea of all the ways your application’s user management needs can be solved by WorkOS.
 
 If you need help migrating your existing WorkOS integration, or have any other questions, please reach out to [WorkOS support](mailto:support@workos.com?subject=WorkOS%20Support).