adds a caution block to access token blacklisting

Author: rishabhpoddar

v2/emailpassword/common-customizations/sessions/access-token-blacklisting.mdx

@@ -22,6 +22,13 @@ If you want session verifications to fail immediately after the session has revo
 
 This feature works by passing the `checkDatabase` option when verifying the session as shown below.
 
+:::caution
+For managed service users, please check [our rate limit policy](../../rate-limits) before implementing this feature. If you suspect that you will breach the free limit you can:
+- [Email us](mailto:[email protected]) to increase your rate limit.
+- Use the `checkDatabase` flag only on certain important APIs. For example, omit using it in any `GET` API as those are not state changing.
+- Implement your own method for keeping track of revoked access tokens by using a cache like Redis.
+:::
+
 ## Using the `verifySession` middleware
 
 <BackendSDKTabs>

v2/passwordless/common-customizations/sessions/access-token-blacklisting.mdx

@@ -22,6 +22,13 @@ If you want session verifications to fail immediately after the session has revo
 
 This feature works by passing the `checkDatabase` option when verifying the session as shown below.
 
+:::caution
+For managed service users, please check [our rate limit policy](../../rate-limits) before implementing this feature. If you suspect that you will breach the free limit you can:
+- [Email us](mailto:[email protected]) to increase your rate limit.
+- Use the `checkDatabase` flag only on certain important APIs. For example, omit using it in any `GET` API as those are not state changing.
+- Implement your own method for keeping track of revoked access tokens by using a cache like Redis.
+:::
+
 ## Using the `verifySession` middleware
 
 <BackendSDKTabs>

v2/session/common-customizations/sessions/access-token-blacklisting.mdx

@@ -22,6 +22,13 @@ If you want session verifications to fail immediately after the session has revo
 
 This feature works by passing the `checkDatabase` option when verifying the session as shown below.
 
+:::caution
+For managed service users, please check [our rate limit policy](../../rate-limits) before implementing this feature. If you suspect that you will breach the free limit you can:
+- [Email us](mailto:[email protected]) to increase your rate limit.
+- Use the `checkDatabase` flag only on certain important APIs. For example, omit using it in any `GET` API as those are not state changing.
+- Implement your own method for keeping track of revoked access tokens by using a cache like Redis.
+:::
+
 ## Using the `verifySession` middleware
 
 <BackendSDKTabs>

v2/thirdparty/common-customizations/sessions/access-token-blacklisting.mdx

@@ -22,6 +22,13 @@ If you want session verifications to fail immediately after the session has revo
 
 This feature works by passing the `checkDatabase` option when verifying the session as shown below.
 
+:::caution
+For managed service users, please check [our rate limit policy](../../rate-limits) before implementing this feature. If you suspect that you will breach the free limit you can:
+- [Email us](mailto:[email protected]) to increase your rate limit.
+- Use the `checkDatabase` flag only on certain important APIs. For example, omit using it in any `GET` API as those are not state changing.
+- Implement your own method for keeping track of revoked access tokens by using a cache like Redis.
+:::
+
 ## Using the `verifySession` middleware
 
 <BackendSDKTabs>

v2/thirdpartyemailpassword/common-customizations/sessions/access-token-blacklisting.mdx

@@ -22,6 +22,13 @@ If you want session verifications to fail immediately after the session has revo
 
 This feature works by passing the `checkDatabase` option when verifying the session as shown below.
 
+:::caution
+For managed service users, please check [our rate limit policy](../../rate-limits) before implementing this feature. If you suspect that you will breach the free limit you can:
+- [Email us](mailto:[email protected]) to increase your rate limit.
+- Use the `checkDatabase` flag only on certain important APIs. For example, omit using it in any `GET` API as those are not state changing.
+- Implement your own method for keeping track of revoked access tokens by using a cache like Redis.
+:::
+
 ## Using the `verifySession` middleware
 
 <BackendSDKTabs>

v2/thirdpartypasswordless/common-customizations/sessions/access-token-blacklisting.mdx

@@ -22,6 +22,13 @@ If you want session verifications to fail immediately after the session has revo
 
 This feature works by passing the `checkDatabase` option when verifying the session as shown below.
 
+:::caution
+For managed service users, please check [our rate limit policy](../../rate-limits) before implementing this feature. If you suspect that you will breach the free limit you can:
+- [Email us](mailto:[email protected]) to increase your rate limit.
+- Use the `checkDatabase` flag only on certain important APIs. For example, omit using it in any `GET` API as those are not state changing.
+- Implement your own method for keeping track of revoked access tokens by using a cache like Redis.
+:::
+
 ## Using the `verifySession` middleware
 
 <BackendSDKTabs>