chore: remove unnecessary instances of "clerk" (#1688)

Co-authored-by: Lennart <[email protected]>
Co-authored-by: Alexis Aguilar <[email protected]>

docs/advanced-usage/satellite-domains.mdx

@@ -12,7 +12,7 @@ Clerk supports sharing sessions across different domains by adding one or many s
 
 Your "primary" domain is where the authentication state lives, and satellite domains are able to securely read that state from the primary domain, enabling a seamless authentication flow across domains.
 
-Users must complete both the sign-in and sign-up flows on the primary domain by using Clerk's [`<SignIn />`](/docs/components/authentication/sign-in) component or [`useSignIn()`](/docs/references/react/use-sign-in) hook for sign-in and [`<SignUp />`](/docs/components/authentication/sign-up) component or [`useSignUp()`](/docs/references/react/use-sign-up) hook for sign-up.
+Users must complete both the sign-in and sign-up flows on the primary domain by using the [`<SignIn />`](/docs/components/authentication/sign-in) component or [`useSignIn()`](/docs/references/react/use-sign-in) hook for sign-in and [`<SignUp />`](/docs/components/authentication/sign-up) component or [`useSignUp()`](/docs/references/react/use-sign-up) hook for sign-up.
 
 To access authentication state from a satellite domain, users will be transparently redirected to the primary domain. If users need to sign in, they must be redirected to a sign in flow hosted on the primary domain, then redirected back to the originating satellite domain. The same redirection process applies to sign-up flows.
 
@@ -35,7 +35,7 @@ To access authentication state from a satellite domain, users will be transparen
   When building your sign-in flow, you must configure it to run within your primary application, e.g. on `/sign-in`.
 
   > [!NOTE]
-  > For more information about creating your application, check out Clerk's [detailed guide](/docs/quickstarts/setup-clerk).
+  > For more information about creating your application, see the [setup guide](/docs/quickstarts/setup-clerk).
 
   ### Add your first satellite domain
 

docs/advanced-usage/using-proxies.mdx

@@ -4,7 +4,7 @@ description: Learn how to proxy the Clerk Frontend API through your domain.
 ---
 
 > [!WARNING]
-> This guide is for users who need to proxy Clerk's Frontend API for deployment. If your application already uses a CNAME subdomain that is required for deploying with Clerk, then you must proxy Clerk's API using a different subdomain. Refer to [the Clerk deployment guide](/docs/deployments/overview#dns-records) on how to configure DNS records for deployment.
+> This guide is for users who need to proxy the Frontend API for deployment. If your application already uses a CNAME subdomain that is required for deploying with Clerk, then you must proxy the Frontend API using a different subdomain. Refer to the [deployment guide](/docs/deployments/overview#dns-records) on how to configure DNS records for deployment.
 
 Clerk supports two configuration methods for connecting to the Clerk Frontend API: CNAME and Proxy.
 
@@ -322,7 +322,7 @@ When using a proxy, all requests to the Frontend API will be made through your d
 
   ### Ready to go 🎉
 
-  Your application should now be able to access Clerk's Frontend API from your proxy!
+  Your application should now be able to access the Frontend API from your proxy!
 </Steps>
 
 If you have any questions about proxying, or you're having any trouble setting this up, please contact [[email protected]](mailto:[email protected]).

docs/authentication/configuration/session-options.mdx

@@ -11,7 +11,7 @@ Depending on the business domain of an application, there might be different req
 
 Ultimately, picking the ideal session lifetime is a trade-off between security and user experience. Longer sessions are generally better for UX but worse for security; and vice-versa.
 
-Fortunately, with Clerk you have to ability to fully control the lifetime of your users' sessions. There are two settings for doing so and you can set them via your instance settings in the [Clerk Dashboard](https://dashboard.clerk.com/): Inactivity timeout and Maximum lifetime.
+Fortunately, with Clerk, you have the ability to fully control the lifetime of your users' sessions. There are two settings for doing so and you can set them via your instance settings in the [Clerk Dashboard](https://dashboard.clerk.com/): Inactivity timeout and Maximum lifetime.
 
 > [!NOTE]
 > Note that either one or both must be enabled at all times. For security reasons, you are not allowed to disable both settings.
@@ -56,7 +56,7 @@ To enable multi-session in your application, you need to configure it in the Cle
 
 There are two main ways to add the multi-session feature to your application:
 
-- Use the [`<UserButton />`](/docs/components/user/user-button) component if you want to use Clerk's prebuilt UI.
+- Use the [`<UserButton />`](/docs/components/user/user-button) component if you want to use a prebuilt UI.
 - [Build a custom flow](/docs/custom-flows/multi-session-applications) if you want to rebuild the existing Clerk flow using the Clerk API.
 
 ## Customize session token

docs/authentication/configuration/sign-up-sign-in-options.mdx

@@ -9,7 +9,7 @@ You can modify your authentication options after your application has been creat
 
 ## Identifiers
 
-Identifiers are how your application recognizes an individual user. Clerk offers three primary identifiers:
+Identifiers are how your application recognizes an individual user. There are three primary identifiers:
 
 - **Email address**
 - **Phone number**
@@ -39,9 +39,9 @@ To update your identifiers after your application has been created:
 
 Authentication strategies are methods that users can use to sign up and sign in to your application.
 
-Clerk offers two kinds of authentication strategies: **password** and **passwordless**.
+There are two kinds of authentication strategies: **password** and **passwordless**.
 
-Choosing the **password** strategy requires users to set a password during the sign up process. Passwords are required to be at least 8 characters long, and Clerk offers out-of-the-box protection against weak and compromised passwords.
+Choosing the **password** strategy requires users to set a password during the sign up process. Passwords are required to be at least 8 characters long, and have built-in protection against weak and compromised passwords.
 
 > [!NOTE]
 > Passwordless authentication remains available to users, even if the password strategy is enabled.
@@ -75,7 +75,7 @@ Users can only create passkeys after signing up, so you'll need to enable anothe
 
 The easiest way to allow your users to create and manage their passkeys is to use the prebuilt [`<UserProfile>`](/docs/components/user/user-profile) component, which includes passkey management in the **Security** tab.
 
-If you're building a custom user interface, refer to the [passkeys custom flow](/docs/custom-flows/passkeys) guide to learn how to create a custom passkey management flow using Clerks API.
+If you're building a custom user interface, refer to the [passkeys custom flow](/docs/custom-flows/passkeys) guide to learn how to create a custom passkey management flow using the Clerk API.
 
 #### Passkey limitations
 
@@ -156,7 +156,7 @@ Clerk's OAuth process is designed to be seamless. If an existing user attempts t
 
 {/* TODO: Is this too much to add? */}
 
-Users can link multiple social providers to their account, depending on your application's setup. You can configure your application to use the [Account Portal User Profile page](/docs/customization/account-portal/overview#user-profile), the prebuilt [`<UserProfile />`](/docs/components/user/user-profile) component, or [build your own custom user interface using the Clerk API](/docs/custom-flows/oauth-connections).
+Users can link multiple social providers to their account, depending on your application's setup. You can configure your application to use the [Account Portal User Profile page](/docs/customization/account-portal/overview#user-profile), the prebuilt [`<UserProfile />`](/docs/components/user/user-profile) component, or [build your own custom user interface using the Clerk API.](/docs/custom-flows/oauth-connections).
 
 To enable social connections:
 
@@ -185,15 +185,15 @@ MFA is not available on the new application screen, but it can be enabled in the
 1. In the navigation sidebar, select **User & Authentication > Multi-factor**.
 1. Toggle on the MFA strategies you would like to enable.
 
-Clerk currently offers the following MFA strategies:
+The following MFA strategies are currently available:
 
 - **SMS verification code**
 - **Authenticator application (also known as TOTP - Time-based One-time Password)**
 - **Backup codes**
 
 Enabling MFA allows users of your app to turn it on for their own accounts through their [User Profile](/docs/customization/account-portal/overview#user-profile) page. Enabling MFA does not automatically turn on MFA for all users.
 
-If you're building a custom user interface instead of using Clerk's [Account Portal](/docs/customization/account-portal/overview) or [prebuilt components](/docs/components/overview), you can use [Clerk elements](/docs/customization/elements/examples/sign-in#multi-factor-authentication-mfa) or use [Clerk's API](/docs/custom-flows/email-password-mfa) to build a custom sign-in flow that allows users to sign in with MFA.
+If you're building a custom user interface instead of using the [Account Portal](/docs/customization/account-portal/overview) or [prebuilt components](/docs/components/overview), you can use [elements](/docs/customization/elements/examples/sign-in#multi-factor-authentication-mfa) or [the Clerk API](/docs/custom-flows/email-password-mfa) to build a custom sign-in flow that allows users to sign in with MFA.
 
 ### Reset a user's MFA
 

docs/authentication/overview.mdx

@@ -3,7 +3,7 @@ title: Sign-up & sign-in overview
 description: Learn how to configure authentication and user management for your Clerk application.
 ---
 
-Clerk supports multiple authentication strategies so that you can implement the strategy that makes sense for _your_ users. You can use Clerk's [Account Portal](/docs/customization/account-portal/overview), [prebuilt components](/docs/components/overview), or [build your own custom flows](/docs/custom-flows/overview).
+Clerk supports multiple authentication strategies so that you can implement the strategy that makes sense for _your_ users. You can use the [Account Portal](/docs/customization/account-portal/overview), [prebuilt components](/docs/components/overview), or build your own [custom flows](/docs/custom-flows/overview).
 
 ## Configuration
 

docs/authentication/social-connections/google.mdx

@@ -110,4 +110,4 @@ To configure this setting:
 
 ## Google One Tap
 
-[Google One Tap](https://developers.google.com/identity/gsi/web/guides/features) enables users to sign up or sign in to your Clerk app with the press of a button. After adding Google to your Clerk app as a social connection, you can use Clerk's prebuilt `<GoogleOneTap />` component to render the One Tap UI in your app. See [the `<GoogleOneTap />` component reference](/docs/components/authentication/google-one-tap) to learn more.
+[Google One Tap](https://developers.google.com/identity/gsi/web/guides/features) enables users to sign up or sign in to your Clerk app with the press of a button. After adding Google to your Clerk app as a social connection, you can use the prebuilt `<GoogleOneTap />` component to render the One Tap UI in your app. See [the `<GoogleOneTap />` component reference](/docs/components/authentication/google-one-tap) to learn more.

docs/authentication/social-connections/oauth.mdx

@@ -8,12 +8,12 @@ Clerk makes it easy to add social connection capabilities to your application. W
 > [!NOTE]
 > When using social connections, the sign-up and sign-in flows are equivalent. If a user doesn't have an account and tries to sign in, an account will be made for them, and vice versa.
 
-The easiest way to add social connections is by using Clerk's [prebuilt components](/docs/components/overview). If you prefer a more custom solution, check out how to [build a completely custom social connection flow](/docs/custom-flows/oauth-connections).
+The easiest way to add social connections to your Clerk app is by using [prebuilt components](/docs/components/overview). If you prefer a more custom solution, check out how to [build a social connection flow using the Clerk API](/docs/custom-flows/oauth-connections).
 
 ## Before you start
 
 - You need to create a Clerk application in your [Clerk Dashboard](https://dashboard.clerk.com/). For more information, check out the [Set up your application](/docs/quickstarts/setup-clerk) guide.
-- You need to install the correct SDK for your application. You can find steps on how to do so through Clerk's [quickstart](/docs/quickstarts/overview) guides.
+- You need to install the correct SDK for your application. You can find steps on how to do so through the [quickstart guides.](/docs/quickstarts/overview)
 
 ## Enable a social connection
 
@@ -128,9 +128,7 @@ export async function GET() {
 
 For each social provider, you can disable the option to sign up and sign in to your application using the provider. This is especially useful for users that want to connect their OAuth account _after_ authentication.
 
-For example, say your application wants to read a user's GitHub repository data but doesn't want to allow the user to authenticate with their GitHub account. The user can sign up with their email and password, or whatever method you choose, and then afterwards, connect their GitHub account to your application.
-
-After sign-up, connections can be made through Clerk's [`<UserProfile/>`](/docs/components/user/user-profile) component, or with a [custom flow](/docs/custom-flows/oauth-connections).
+For example, say your application wants to read a user's GitHub repository data but doesn't want to allow the user to authenticate with their GitHub account. The user can sign up with their email and password, or whatever authentication method you choose, and then afterwards, connect their GitHub account to your application through their user profile. The easiest way to enable this for your users is by using the [`<UserProfile />`](/docs/components/user/user-profile) component. If you prefer to build a custom user interface, see how to [build a social connection flow using the Clerk API](/docs/custom-flows/oauth-connections).
 
 To configure the option for users to sign up and sign in with a social provider:
 
@@ -144,13 +142,13 @@ To configure the option for users to sign up and sign in with a social provider:
 
 When signed in, a user can connect to further social providers. There is no need to perform another sign-up.
 
-When using Clerk's [Account Portal](/docs/customization/account-portal/overview) pages, users can see which providers they have already connected to and which ones they can still connect to on their [user profile page.](/docs/customization/account-portal/overview#user-profile)
+When using the [Account Portal](/docs/customization/account-portal/overview) pages, users can see which providers they have already connected to and which ones they can still connect to on their [user profile page.](/docs/customization/account-portal/overview#user-profile)
 
-When using Clerk's [prebuilt components](/docs/components/overview), you can use the [`<UserProfile/>`](/docs/components/user/user-profile) component to allow users to connect to further social providers.
+When using the [prebuilt components](/docs/components/overview), you can use the [`<UserProfile/>`](/docs/components/user/user-profile) component to allow users to connect to further social providers.
 
 ## OAuth for native applications
 
-Currently, Clerk's prebuilt components are not supported in native applications, but you can use the Clerk API to [build a custom flow for authenticating with social connections.](/docs/custom-flows/oauth-connections)
+Currently, the prebuilt components are not supported in native applications, but you can use the Clerk API to [build a custom flow for authenticating with social connections.](/docs/custom-flows/oauth-connections)
 
 Clerk ensures that security critical nonces are passed only to allowlisted URLs when the OAuth flow is completed in native browsers or webviews. For maximum security in your **production** instances, you need to allowlist your custom redirect URLs via the [Clerk Dashboard](https://dashboard.clerk.com/) or the [Clerk Backend API](/docs/references/backend/redirect-urls/create-redirect-url).
 

docs/backend-requests/handling/manual-jwt.mdx

@@ -7,7 +7,7 @@ Your Clerk-generated [session tokens](/docs/backend-requests/resources/session-t
 
 For every request, you must validate its token to make sure it hasn't expired and it is authentic (i.e. no malicious user tried to tamper with it). If these validations pass, then it means that the user is authenticated to your application and you should consider them signed in.
 
-The `authenticateRequest()` method from Clerk's JavaScript Backend SDK does all of this for you. It accepts the request object and authenticates the session token in it. See the [reference page](/docs/references/backend/authenticate-request) for more information.
+The `authenticateRequest()` method from the JavaScript Backend SDK does all of this for you. It accepts the `request` object and authenticates the session token in it. See the [reference page](/docs/references/backend/authenticate-request) for more information.
 
 ## Networkless token verification
 

docs/backend-requests/making/cross-origin.mdx

@@ -25,9 +25,9 @@ export default function useFetch() {
 }
 ```
 
-## useSWR hook
+## `useSWR()` hook
 
-If you are using React or Next.js and want to use the [`useSWR`](https://swr.vercel.app/) hook, you can create a custom hook by utilizing Clerk's [`useAuth()`](/docs/references/react/use-auth) hook. `useAuth()` returns the asynchronous `getToken` function that can be called to add the session token as a Bearer token in the Authorization header of requests.
+If you are using React or Next.js and want to use SWR's [`useSWR()`](https://swr.vercel.app/) hook, you can create a custom hook by using the [`useAuth()`](/docs/references/react/use-auth) hook. `useAuth()` returns the asynchronous `getToken()` method that can be called to add the session token as a Bearer token in the Authorization header of requests.
 
 ```js
 import useSWR from 'swr'

docs/backend-requests/resources/rate-limits.mdx

@@ -1,6 +1,6 @@
 ---
 title: Rate limits
-description: Learn about rate limiting on Clerk's APIs.
+description: Learn about rate limiting on the Clerk APIs.
 ---
 
 Clerk rate limits certain endpoints to help protect users against brute-force attacks or to stop abuse of Clerk's platform.

docs/components/authentication/google-one-tap.mdx

@@ -322,6 +322,6 @@ See [`authenticateWithGoogleOneTap()` usage](#authenticate-with-google-one-tap-u
 
 ## Limitations
 
-- If your application will use the Google API on behalf of your users, Clerk's `<GoogleOneTap>` component is not recommended, as Google does not provide Clerk with an access or refresh token that you can use.
+- If your application will use the Google API on behalf of your users, the `<GoogleOneTap>` component is not recommended, as Google does not provide Clerk with an access or refresh token that you can use.
 - Users with the 1Password browser extension may not be able to render the Google One Tap UI. They must disable this extension.
 - When testing in development, if you select the `X` button to close the Google One Tap UI, you may encounter [a cooldown](https://developers.google.com/identity/gsi/web/guides/features#exponential_cooldown) that prevents you from rendering it again for a period of time. To bypass the cooldown, remove the `g_state` cookie.

docs/components/authentication/sign-in.mdx

@@ -3,7 +3,7 @@ title: '`<SignIn />` component'
 description: Clerk's <SignIn /> component renders a UI for signing in users.
 ---
 
-![Clerk's \<SignIn /> component renders a UI for signing in users.](/docs/images/ui-components/sign-in.svg)
+![The \<SignIn /> component renders a UI for signing in users.](/docs/images/ui-components/sign-in.svg)
 
 The `<SignIn />` component renders a UI for signing in users. The functionality of the `<SignIn />` component is controlled by the instance settings you specify in your [Clerk Dashboard](https://dashboard.clerk.com), such as [sign-in and sign-up options](/docs/authentication/configuration/sign-up-sign-in-options) and [social connections](/docs/authentication/social-connections/overview). You can further customize your `<SignIn />` component by passing additional [properties](#properties) at the time of rendering.