@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/authkit/email-verification.mdx

@@ -0,0 +1,31 @@
+---
+title: Email Verification
+description: Learn more about the email verification process.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/email-verification.mdx
+---
+
+## Introduction
+
+Email verification is a process in which a new user must validate ownership of their email inbox before they can access the application, ensuring authenticity of inbox ownership.
+
+## The email verification flow
+
+Verification is a two-step process:
+
+- A user signs up to your application and an email is sent with a verification code.
+- The user inputs the verification code to complete the signup process.
+
+This applies to all authentication methods including [OAuth](/authkit/social-login) and [SSO](/authkit/sso). This unifying interface simplifies how your application considers the authenticity of your users.
+
+**Email verification is always on** to ensure that verified users are always returned to your application.
+
+## Users with verified email domains
+
+Users signing in with SSO with a [verified domain](/authkit/domain-verification) are automatically considered verified and do not need to complete the email verification process.
+
+## Sending verification emails
+
+[AuthKit](/authkit) automatically handles email verification out of the box. When a user signs up via the hosted signup form, AuthKit will automatically send the verification email, prompt the user to input the code and route them through the authentication process before they gain access to the application. If desired, you can [send these emails yourself](/authkit/custom-emails).
+
+If a verification email bounces or is blocked, the recipient's address may be added to your provider's suppression list, preventing future deliveries. See [Check suppression status](/email/e-check-suppression-status) to check and resolve suppressions.

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

@@ -1,10 +1,10 @@
 ---
 title: Example apps
-description: View sample User Management apps.
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/example-apps.mdx
+description: View sample AuthKit apps.
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/example-apps.mdx
 ---
 
-You can view minimal example apps that demonstrate how to use WorkOS User Management and AuthKit to authenticate users:
+You can view minimal example apps that demonstrate how to use AuthKit to authenticate users:
 
 <ExampleApps.Root>
   <ExampleApps.Card href="https://github.com/workos/authkit" title="AuthKit" />

package/.docs/organized/docs/authkit/hosted-ui.mdx

@@ -0,0 +1,165 @@
+---
+title: Hosted UI
+description: >-
+  Customizable sign-in UI that abstracts away all of the complexity associated
+  with building secure authentication flows.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/hosted-ui.mdx
+---
+
+## Introduction
+
+Implementing authentication flows that handle every possible error state and edge case across multiple identity providers can be a daunting task. AuthKit makes this easy by providing a hosted, pre-built, customizable authentication UI with automatic handling of:
+
+- Sign up, sign in, password reset, and [email verification](/authkit/email-verification) flows.
+- Enterprise [SSO](/authkit/sso) routing and [MFA](/authkit/mfa) enrollment.
+- Automatic bot detection and blocking, to protect against brute force attacks.
+- Customizable [domain](/custom-domains/authkit) and [branding](/authkit/branding).
+
+![AuthKit sign-in UI](https://images.workoscdn.com/images/4d736ca3-eec8-4a90-bd14-2530c4210415.png?auto=format&fit=clip&q=80)
+
+## Authentication flow
+
+AuthKit is conceptually similar to a [Social Login (OAuth)](/authkit/social-login) experience, but with the added benefit of being able to authenticate users with any identity provider.
+
+AuthKit sits outside of your application code. When a user initiates a sign-in request, your application redirects them to the AuthKit URL. The user then completes the authentication process with WorkOS before being returned to the application.
+
+Your application will exchange the resulting authorization code to retrieve an authenticated [User object](/reference/authkit/user) and handle the session.
+
+![AuthKit authentication flow diagram](https://images.workoscdn.com/images/0b3265fa-a209-4ca7-beaf-7d2514a3e00a.png?auto=format&fit=clip&q=80)[border=false]
+
+> The AuthKit flow abstracts away many of the UX and WorkOS API calling concerns automatically, for more guidance on integrating with AuthKit, see the [Quick Start](/authkit) guide.
+
+AuthKit also provides a signup flow for creating users. Available options are determined by the configured [authentication methods](/authkit/hosted-ui/authentication-methods). If a user’s email address is associated with an SSO connection, they will automatically be redirected to sign up via their IdP.
+
+## Authentication methods
+
+AuthKit's hosted UI supports all of the authentication methods available and will automatically adjust the available options depending on the configured methods in the _Authentication_ section of the [WorkOS Dashboard](https://dashboard.workos.com).
+
+![Dashboard displaying available authentication methods](https://images.workoscdn.com/images/ea3b2c3b-723e-462c-aa10-6b1cec1b635f.png?auto=format&fit=clip&q=80)
+
+Email + Password authentication is enabled by default, though set up may be required to enable additional methods. See the relevant feature section for more information:
+
+- [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)
+
+## Localization
+
+By default, AuthKit's hosted UI is automatically localized into many global languages.
+Your users will be served in the locale that closest matches their device's OS preference.
+All user-facing text, including error messages and transactional emails, are translated into the user's native tongue.
+
+- ### Supported locales
+  | Locale code | Language                | Autonym                 |
+  | ----------- | ----------------------- | ----------------------- |
+  | `af`        | Afrikaans               | Afrikaans               |
+  | `am`        | Amharic                 | አማርኛ                    |
+  | `ar`        | Arabic                  | العربية                 |
+  | `bg`        | Bulgarian               | Български               |
+  | `bn`        | Bengali (Bangla)        | বাংলা                   |
+  | `bs`        | Bosnian                 | Bosanski                |
+  | `ca`        | Catalan                 | Català                  |
+  | `cs`        | Czech                   | Čeština                 |
+  | `da`        | Danish                  | Dansk                   |
+  | `de`        | German                  | Deutsch                 |
+  | `de-DE`     | German (Germany)        | Deutsch (Deutschland)   |
+  | `el`        | Greek                   | Ελληνικά                |
+  | `en`        | English                 | English                 |
+  | `en-AU`     | English (Australia)     | English (Australia)     |
+  | `en-CA`     | English (Canada)        | English (Canada)        |
+  | `en-GB`     | English (UK)            | English (UK)            |
+  | `en-US`     | English (US)            | English (US)            |
+  | `es`        | Spanish                 | Español                 |
+  | `es-419`    | Spanish (Latin America) | Español (Latinoamérica) |
+  | `es-ES`     | Spanish (Spain)         | Español (España)        |
+  | `es-US`     | Spanish (US)            | Español (EE.UU.)        |
+  | `et`        | Estonian                | Eesti                   |
+  | `fa`        | Farsi (Persian)         | فارسی                   |
+  | `fi`        | Finnish                 | Suomi                   |
+  | `fil`       | Filipino (Tagalog)      | Filipino                |
+  | `fr`        | French                  | Français                |
+  | `fr-BE`     | French (Belgium)        | Français (Belgique)     |
+  | `fr-CA`     | French (Canada)         | Français (Canada)       |
+  | `fr-FR`     | French (France)         | Français (France)       |
+  | `fy`        | Frisian                 | Frysk                   |
+  | `gl`        | Galician                | Galego                  |
+  | `gu`        | Gujarati                | ગુજરાતી                 |
+  | `ha`        | Hausa                   | هَرْشٜن هَوْس           |
+  | `he`        | Hebrew                  | עברית                   |
+  | `hi`        | Hindi                   | हिन्दी                  |
+  | `hr`        | Croatian                | Hrvatski                |
+  | `hu`        | Hungarian               | Magyar                  |
+  | `hy`        | Armenian                | Հայերեն                 |
+  | `id`        | Indonesian              | Bahasa Indonesia        |
+  | `is`        | Icelandic               | Íslenska                |
+  | `it`        | Italian                 | Italiano                |
+  | `it-IT`     | Italian (Italy)         | Italiano (Italia)       |
+  | `ja`        | Japanese                | 日本語                  |
+  | `jv`        | Javanese                | ꦧꦱꦗꦮ                    |
+  | `ka`        | Georgian                | ქართული                 |
+  | `kk`        | Kazakh                  | Қазақ тілі              |
+  | `km`        | Khmer                   | ខេមរភាសា                |
+  | `kn`        | Kannada                 | ಕನ್ನಡ                   |
+  | `ko`        | Korean                  | 한국어                  |
+  | `lt`        | Lithuanian              | Lietuvių                |
+  | `lv`        | Latvian                 | Latviešu                |
+  | `mk`        | Macedonian              | Македонски              |
+  | `ml`        | Malayalam               | മലയാളം                  |
+  | `mn`        | Mongolian               | Монгол                  |
+  | `mr`        | Marathi                 | मराठी                   |
+  | `ms`        | Malay                   | Bahasa Melayu           |
+  | `my`        | Burmese                 | မြန်မာ                  |
+  | `nb`        | Norwegian Bokmål        | Norsk Bokmål            |
+  | `ne`        | Nepali                  | नेपाली भाषा             |
+  | `nl`        | Dutch                   | Nederlands              |
+  | `nl-BE`     | Flemish                 | Vlaams                  |
+  | `nl-NL`     | Dutch (Netherlands)     | Nederlands (Nederland)  |
+  | `nn`        | Norwegian Nynorsk       | Norsk Nynorsk           |
+  | `no`        | Norwegian               | Norsk                   |
+  | `pa`        | Punjabi                 | ਪੰਜਾਬੀ                  |
+  | `pl`        | Polish                  | Polski                  |
+  | `pt`        | Portuguese              | Português               |
+  | `pt-BR`     | Portuguese (Brazil)     | Português (Brasil)      |
+  | `pt-PT`     | Portuguese (Portugal)   | Português (Portugal)    |
+  | `ro`        | Romanian                | Română                  |
+  | `ru`        | Russian                 | Русский                 |
+  | `sk`        | Slovak                  | Slovenčina              |
+  | `sl`        | Slovenian               | Slovenščina             |
+  | `sq`        | Albanian                | Shqip                   |
+  | `sr`        | Serbian                 | Српски                  |
+  | `sv`        | Swedish                 | Svenska                 |
+  | `sw`        | Swahili                 | Kiswahili               |
+  | `ta`        | Tamil                   | தமிழ்                   |
+  | `te`        | Telugu                  | తెలుగు                  |
+  | `th`        | Thai                    | ไทย                     |
+  | `tr`        | Turkish                 | Türkçe                  |
+  | `uk`        | Ukrainian               | Українська              |
+  | `ur`        | Urdu                    | اُردُو                  |
+  | `uz`        | Uzbek                   | Ózbekça                 |
+  | `vi`        | Vietnamese              | Tiếng Việt              |
+  | `zh`        | Chinese                 | 中文                    |
+  | `zh-CN`     | Chinese (Simplified)    | 中文 (中国)             |
+  | `zh-HK`     | Chinese (Hong Kong)     | 中文（香港）            |
+  | `zh-TW`     | Chinese (Taiwan)        | 中文（台灣）            |
+  | `zu`        | Zulu                    | isiZulu                 |
+
+In cases where a user's browser does not send their preferred locale, or when AuthKit cannot identify a match, the user is served in the environment's **fallback language**. The fallback language can be configured [in the dashboard](https://dashboard.workos.com/environment/authentication/features) in the _Authentication > Features > Localization_ section.
+
+![With localization, you can change the environment's fallback language](https://images.workoscdn.com/images/bb8c017b-f9cd-4882-baa2-b38e01a51875.png?auto=format&fit=clip&q=50)
+
+## Integrating
+
+Integration into your app is quick and easy, though the route you choose varies depending on your specific requirements:
+
+### (A) Integrate with AuthKit's Hosted UI
+
+In just a few lines of code, you can add AuthKit to your app and start authenticating users. See the [quick start](/authkit) guide for more information.
+
+### (B) Build your own authentication flows
+
+While the hosted solution is the fastest way to get started, if you’d prefer to build and manage your own authentication UI, you can do so via the [AuthKit API](/reference/authkit).
+
+Examples of building custom UI are [available on GitHub](https://github.com/workos/authkit).

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

@@ -2,12 +2,12 @@
 title: Identity Linking
 description: Automatic deduplication of user credentials across identity providers.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/identity-linking.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/identity-linking.mdx
 ---
 
 ## Introduction
 
-Users have unique email addresses, because each user’s access to their inbox represents ultimate access to all of their credentials and thus services they control. The [User object](/reference/user-management/user) unifies all of the identities they use so that your application does not have to consider different identity systems.
+Users have unique email addresses, because each user’s access to their inbox represents ultimate access to all of their credentials and thus services they control. The [User object](/reference/authkit/user) unifies all of the identities they use so that your application does not have to consider different identity systems.
 
 Identity linking is the process in which WorkOS safely deduplicates various credentials across identity providers to offer a single, unified user interface. It does this by using the **email address** as the unique identifier and access to the email inbox as the source of truth.
 
@@ -15,15 +15,15 @@ Identity linking is the process in which WorkOS safely deduplicates various cred
 
 ## Credentials
 
-A credential is an authentication method in a specific identity provider. For example, WorkOS offers a [password credential](/user-management/email-password) for users to authenticate with. In this case, WorkOS is the identity provider and password is the authentication method.
+A credential is an authentication method in a specific identity provider. For example, WorkOS offers a [password credential](/authkit/email-password) for users to authenticate with. In this case, WorkOS is the identity provider and password is the authentication method.
 
-[Google OAuth](/user-management/social-login) is another credential, where Google is the identity provider and OAuth is the authentication method.
+[Google OAuth](/authkit/social-login) is another credential, where Google is the identity provider and OAuth is the authentication method.
 
 Users may use multiple types of authentication methods based on preference, perhaps because one is more convenient to use on one of their devices, or they simply didn’t remember which method they used in the past.
 
 ## Email verification
 
-WorkOS ensures all user emails are unique via an [email verification process](/user-management/email-verification). By default, email verification is required by all users for authentication to succeed. This ensures that verified users are always returned to your application.
+WorkOS ensures all user emails are unique via an [email verification process](/authkit/email-verification). By default, email verification is required by all users for authentication to succeed. This ensures that verified users are always returned to your application.
 
 When a user signs in with a new credential for the first time, e.g. they sign in through Google OAuth despite already having a password account, WorkOS will safely attach the new credential to the existing user. This is only performed if WorkOS can verify that the user has access to the email inbox referenced by that credential.
 
@@ -33,15 +33,15 @@ WorkOS considers it a **security risk if the user cannot verify access to their
 
 ## Domain verification
 
-When an IT admin [verifies a domain for their organization](/user-management/domain-verification), it means they have access to create email inboxes. Thus, a **verified domain implies the ability to verify all users with that email domain**.
+When an IT admin [verifies a domain for their organization](/authkit/domain-verification), it means they have access to create email inboxes. Thus, a **verified domain implies the ability to verify all users with that email domain**.
 
 In practice, when a domain is verified and an SSO connection is configured, users who sign in through an organization’s IdP are automatically considered email verified if the domain matches. This shortcut reduces friction for your end users.
 
-> Users who sign-in through SSO with an email address that is not a verified domain are not considered verified and will have go through the [email verification](/user-management/email-verification) process.
+> Users who sign-in through SSO with an email address that is not a verified domain are not considered verified and will have go through the [email verification](/authkit/email-verification) process.
 
 ## SSO identity linking
 
-Not only can a user have multiple credentials, they may also have multiple SSO credentials. This might happen when a user works with multiple organizations that require SSO authentication for all members. In this case, there is still only one [User object](/reference/user-management/user), but they would choose which organization’s SSO IdP to use when authenticating.
+Not only can a user have multiple credentials, they may also have multiple SSO credentials. This might happen when a user works with multiple organizations that require SSO authentication for all members. In this case, there is still only one [User object](/reference/authkit/user), but they would choose which organization’s SSO IdP to use when authenticating.
 
 ![Example UI showing organization selection](https://images.workoscdn.com/images/876aeb05-cd96-46b4-9adf-3e9dd0208e47.png?auto=format&fit=clip&q=80)
 
@@ -49,4 +49,4 @@ The email verification safety still applies. When the user signs-in for the firs
 
 Users without a verified domain **must be invited to the organization** before they have access via SSO for the first time.
 
-> An [invitation](/user-management/invitations) ensures that the authentication flow gives the user an opportunity to go to the SSO’s identity provider.
+> An [invitation](/authkit/invitations) ensures that the authentication flow gives the user an opportunity to go to the SSO’s identity provider.

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

@@ -2,7 +2,7 @@
 title: Impersonation
 description: Learn how to sign into your application as one of your users.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/impersonation.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/impersonation.mdx
 ---
 
 ## Introduction
@@ -23,22 +23,22 @@ To impersonate one of your users, navigate to _Users_, select the user you'd lik
 
 ![A screenshot of the User details page in the WorkOS Dashboard](https://images.workoscdn.com/images/afcfc2b9-275c-4a08-9976-ab9b1b30a7b8.png?auto=format&fit=clip&q=80)
 
-You will be prompted for the reason your are impersonating the user. It is optional to provide a reason in staging environments, and required in production. The reason will be recorded internally on the `session.created` event that is emitted whenever impersonation is used.
+You will be prompted for the reason your are impersonating the user. The reason is required and will be recorded internally on the `session.created` event that is emitted whenever impersonation is used.
 
 If the user is a member of more than one organization, you will also need to choose which of
-these organizations you will be signing-into as the user. You can read more about users and organizations in our [dedicated guide](/user-management/users-organizations).
+these organizations you will be signing-into as the user. You can read more about users and organizations in our [dedicated guide](/authkit/users-organizations).
 
-Finally, click _Impersonate user_ to start an impersonation session, redirecting your browser to your application's callback endpoint with an authorization code for the impersonated user. You can read more about how to implement a callback endpoint in our [Quick Start guide](/user-management/2-add-authkit-to-your-app/add-a-callback-endpoint).
+Finally, click _Impersonate user_ to start an impersonation session, redirecting your browser to your application's callback endpoint with an authorization code for the impersonated user. You can read more about how to implement a callback endpoint in our [Quick Start guide](/authkit/2-add-authkit-to-your-app/add-a-callback-endpoint).
 
 > Impersonation sessions automatically expire after 60 minutes.
 
-Be aware that impersonating a user usually generally gives the same level of access as that user, allowing the impersonator to see the user's information. If your application contains sensitive user data, see the [Integrating impersonation](/user-management/impersonation/integrating-impersonation) section about how to customize your application when using impersonation.
+Be aware that impersonating a user usually generally gives the same level of access as that user, allowing the impersonator to see the user's information. If your application contains sensitive user data, see the [Integrating impersonation](/authkit/impersonation/integrating-impersonation) section about how to customize your application when using impersonation.
 
 ### Deep-linking to the impersonation flow
 
 You can deep-link to the impersonation flow in the WorkOS Dashboard from your own admin tool using the following URL structure:
 
-`https://dashboard.workos.com/<environment_id>/users/<user_id>?dialog=impersonate`
+`https://dashboard.workos.com/<environment_id>/users/<user_id>/details?dialog=impersonate`
 
 ## Auditing impersonation usage
 
@@ -52,7 +52,7 @@ The `session.created` event has an `impersonator` field that contains informatio
 
 No additional code is required to start using impersonation once you have integrated with WorkOS. However, many developers may want to augment their application's behavior when your team members are impersonating one of your users.
 
-The response from the [Authenticate with Code API](/reference/user-management/authentication/code) will include an additional `impersonator` field when the resulting session was created via impersonation, containing the impersonator's `email` and `reason` for using impersonation. Similarly, the `access_token` will include an `act` claim with the impersonator's `email`. Your application can use either in order to trigger impersonation-specific behavior.
+The response from the [Authenticate with Code API](/reference/authkit/authentication/code) will include an additional `impersonator` field when the resulting session was created via impersonation, containing the impersonator's `email` and `reason` for using impersonation. Similarly, the `access_token` will include an `act` claim with the impersonator's `email`. Your application can use either in order to trigger impersonation-specific behavior.
 
 A common enhancement is to change the appearance of the application in order to make it obvious to the viewer they are currently impersonating one of your users, such as a "Staff Bar" displayed at the top of the viewport. You may also want to restrict access to sensitive views or redact certain fields in your application.
 
@@ -60,7 +60,7 @@ A common enhancement is to change the appearance of the application in order to
 
 If using the [`authkit-nextjs` library](https://github.com/workos/authkit-nextjs), impersonation can be easily added by using the provided helper component.
 
-After completing the setup instructions in the [quick start](/user-management) guide, add the Impersonation component to your app code.
+After completing the setup instructions in the [quick start](/authkit) guide, add the Impersonation component to your app code.
 
 ```js title="Impersonation component"
 import { Impersonation } from '@workos-inc/authkit-nextjs';