diff --git a/v2/emailpassword/common-customizations/multiple-clients.mdx b/v2/emailpassword/common-customizations/multiple-clients.mdx
index ba7a5d182..09f699b2c 100644
--- a/v2/emailpassword/common-customizations/multiple-clients.mdx
+++ b/v2/emailpassword/common-customizations/multiple-clients.mdx
@@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b
 
 In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https).
 
-All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
+All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
 
 ## Step 1: Define a dynamic origin on the backend
 
diff --git a/v2/passwordless/common-customizations/multiple-clients.mdx b/v2/passwordless/common-customizations/multiple-clients.mdx
index ba7a5d182..09f699b2c 100644
--- a/v2/passwordless/common-customizations/multiple-clients.mdx
+++ b/v2/passwordless/common-customizations/multiple-clients.mdx
@@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b
 
 In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https).
 
-All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
+All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
 
 ## Step 1: Define a dynamic origin on the backend
 
diff --git a/v2/thirdparty/common-customizations/multiple-clients.mdx b/v2/thirdparty/common-customizations/multiple-clients.mdx
index ba7a5d182..09f699b2c 100644
--- a/v2/thirdparty/common-customizations/multiple-clients.mdx
+++ b/v2/thirdparty/common-customizations/multiple-clients.mdx
@@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b
 
 In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https).
 
-All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
+All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
 
 ## Step 1: Define a dynamic origin on the backend
 
diff --git a/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx b/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx
index 23bbc6369..85caa184e 100644
--- a/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx
+++ b/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx
@@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b
 
 In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https).
 
-All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
+All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
 
 ## Step 1: Define a dynamic origin on the backend
 
diff --git a/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx b/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx
index ba7a5d182..09f699b2c 100644
--- a/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx
+++ b/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx
@@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b
 
 In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https).
 
-All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
+All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`.
 
 ## Step 1: Define a dynamic origin on the backend