fix: typos

Author: DaveOrDead

src/content/docs/authenticate/auth-guides/pass-params-idp.mdx

@@ -12,10 +12,11 @@ relatedArticles:
 You can pass provider-specific parameters to an Identity Provider (IdP) during authentication. These are also known as 'upstream params'. The values your pass can either be static per connection or dynamic per user.
 
 There's a number of reason why you might want to use upstream params:
+
 - to create a smoother sign in experience - by passing the email through
 - to offer an account switcher (such as the Google account switcher) during sign in
 
-Upstream params are available for OAuth 2.0 connections, e.g. [social connections](/authenticate/social-sign-in/add-social-sign-in/), [Entra ID OAuth 2.0 enterprise connection](/authenticate/enterprise-connections/azure/), and as part of [advanced configurations](/authenticate/enterprise-connections/advanced-saml-configurations/) in SAML connections. 
+Upstream params are available for OAuth 2.0 connections, e.g. [social connections](/authenticate/social-sign-in/add-social-sign-in/), [Entra ID OAuth 2.0 enterprise connection](/authenticate/enterprise-connections/azure/), and as part of [advanced configurations](/authenticate/enterprise-connections/advanced-saml-configurations/) in SAML connections.
 
 ## Limitations
 
@@ -31,28 +32,26 @@ The Upstream parameter field accepts JSON and the structure is as follows:
 
 ```json
 {
- "<param_name_to_pass>": {
+  "<param_name_to_pass>": {
     "value": "<your_hardcoded_value>"
   }
 }
-
 ```
 
 Replace `<param_name_to_pass>` with the name of the parameter you wish to pass upstream to the IDP.
 Replace `<your_hardcoded_value>` with the value of the parameter you wish to pass upstream.
 
 ### Example: Force the google account selector to display on sign in
 
-If you want Google to always show the account selector even if the user is already logged in with a Google account, pass the `prompt=select_account` parameter from Kinde. 
+If you want Google to always show the account selector even if the user is already logged in with a Google account, pass the `prompt=select_account` parameter from Kinde.
 This is how that would look:
 
 ```json
 {
- "prompt": {
+  "prompt": {
     "value": "select_account"
   }
 }
-
 ```
 
 Now, when your user clicks on the Google button and Kinde creates the URL to redirect to Google, it will append`&prompt=select_account`.
@@ -65,34 +64,34 @@ This is the structure.
 
 ```json
 {
- "<param_name_to_pass>": {
+  "<param_name_to_pass>": {
     "alias": "<dynamic_param_name>"
   }
 }
-
 ```
 
 The `alias` keyword tells Kinde which parameter from your auth url to use, and the value to pass upstream to the IDP.
 
 Here is an example where we provide `login_hint` as part of the auth URL, where the email [`&[email protected]`](mailto:&[email protected]) is included on the URL.
 
 ```html
-https://<your_kinde_sudomain>.kinde.com/oauth2/auth
-	?response_type=code
-	&client_id=<your_kinde_client_id>
-	&redirect_uri=<your_app_redirect_url>
-	&scope=openid%20profile%20email
-	&state=abc
-	&[email protected]
+https://<your_kinde_subdomain
+  >.kinde.com/oauth2/auth ?response_type=code &client_id=<your_kinde_client_id>
+    &redirect_uri=<your_app_redirect_url>
+      &scope=openid%20profile%20email &state=abc
+      &[email protected]</your_app_redirect_url
+    ></your_kinde_client_id
+  ></your_kinde_subdomain
+>
 ```
 
 In this case both Kinde and the IDP use the parameter name `login_hint` so the configuration is the same on both sides:
 Add this to the connection configuration:
 
-  }
+}
 }
 
-```
+````
 
 In this case we are saying pass the `login_hint` parameter upstream to the IDP with the value Kinde received in the `login_hint` auth url param. So `&[email protected]` would be passed on to the provider.
 
@@ -104,7 +103,7 @@ Where the `alias` becomes especially powerful is when you want to re-map a param
 		"alias": "login_hint"
 	}
 }
-```
+````
 
 In this case we are saying pass the `username` parameter upstream to the IDP with the value Kinde received in the `login_hint` auth url param. We remap the email value from `login_hint` to `username` and the parameter `&[email protected]` would be passed on to the IDP.
 
@@ -118,9 +117,9 @@ If the user enters `[email protected]` in the Kinde email field with the followi
 
 ```json
 {
-	"login_hint": {
-			"alias": "login_hint"
-	}
+  "login_hint": {
+    "alias": "login_hint"
+  }
 }
 ```
 
@@ -130,14 +129,13 @@ You can send multple parameters this way and mix-and-match between dynamic and s
 
 ```json
 {
-	"prompt": {
-		"value": "login"
-	},
-	"username": {
-		"alias": "login_hint"
-	}
+  "prompt": {
+    "value": "login"
+  },
+  "username": {
+    "alias": "login_hint"
+  }
 }
-
 ```
 
 This would result in `&prompt=login&[email protected]`

src/content/docs/authenticate/custom-configurations/redirect-users.mdx

@@ -64,7 +64,7 @@ Because it is just a string, you can leverage it to store additional information
 3. When you redirect your user to Kinde to complete the authentication flow, include the random string as the `state` param:
 
    ```jsx
-   https://<your_kinde_sudomain>.kinde.com/oauth2/auth
+   https://<your_kinde_subdomain>.kinde.com/oauth2/auth
    	?response_type=code
    	&client_id=<your_kinde_client_id>
    	&redirect_uri=<your_app_redirect_url>

src/content/docs/developer-tools/about/using-kinde-without-an-sdk.mdx

@@ -46,7 +46,7 @@ You will need to use this redirect URL in the following step.
 Your users must be redirected from your product to Kinde to sign up or sign in securely. The redirect URL on your product side would look like the following:
 
 ```markdown
-https://<your_kinde_sudomain>.kinde.com/oauth2/auth
+https://<your_kinde_subdomain>.kinde.com/oauth2/auth
 ?response_type=code
 &client_id=<your_kinde_client_id>
 &redirect_uri=<your_app_redirect_url>
@@ -61,6 +61,7 @@ Kinde supports all the standard OAuth 2 request parameters as well as a few addi
 Kinde also supports the PKCE extension, in which case the `code_challenge` and `code_challenge_method` parameters are also required. This is recommended for mobile apps and single page applications (SPAs).
 
 ## Handling successful auth for desktop and mobile apps
+
 If you offer mobile and desktop apps, as well as access through a browser, you'll need to handle the post-authentication browser state. Rather than leaving a hanging screen, you can show users a success page. To do this, add the `is_use_auth_success_page` parameter to the authorization URL. See the [Request prameters](/developer-tools/about/using-kinde-without-an-sdk/#request-parameters) section below.
 
 ## Handling the callback
@@ -84,7 +85,7 @@ client_id=<your_kinde_client_id>
 &client_secret=<your_kinde_client_secret>
 &grant_type=authorization_code
 &redirect_uri=<your_app_redirect_url>
-&code=<CALLBACK_AUTHORIZATION_CODE> 
+&code=<CALLBACK_AUTHORIZATION_CODE>
 ```
 
 Make sure you replace the `<values>` with your own credentials.

src/content/docs/workflows/testing/preview-workflows.mdx

@@ -35,7 +35,7 @@ The deployment ID is used to identify the workflow deployment you want to test.
 This should be passed as part of the authorization URL:
 
 ```
-https://<your_kinde_sudomain>.kinde.com/oauth2/auth
+https://<your_kinde_subdomain>.kinde.com/oauth2/auth
 ?response_type=code
 &client_id=<your_kinde_client_id>
 &redirect_uri=<your_app_redirect_url>