FlutterFlow · PoojaB26 · Jun 13, 2025 · May 26, 2025 · May 26, 2025 · May 27, 2025
diff --git a/docs/assets/20250430121149388590.png b/docs/assets/20250430121149388590.png
diff --git a/docs/assets/20250430121149749937.png b/docs/assets/20250430121149749937.png
diff --git a/docs/assets/20250430121259958091.png b/docs/assets/20250430121259958091.png
diff --git a/docs/assets/20250430121300291232.png b/docs/assets/20250430121300291232.png
diff --git a/docs/assets/20250430121300291238.png b/docs/assets/20250430121300291238.png
diff --git a/docs/assets/20250430121300815719.png b/docs/assets/20250430121300815719.png
diff --git a/docs/assets/20250430121301101693.png b/docs/assets/20250430121301101693.png
diff --git a/docs/assets/20250430121439158816.png b/docs/assets/20250430121439158816.png
diff --git a/docs/assets/20250430121439605476.png b/docs/assets/20250430121439605476.png
diff --git a/docs/assets/20250430121440000724.png b/docs/assets/20250430121440000724.png
diff --git a/docs/assets/20250430121440426479.png b/docs/assets/20250430121440426479.png
diff --git a/docs/assets/20250430121440906814.png b/docs/assets/20250430121440906814.png
diff --git a/docs/assets/20250430121441325585.png b/docs/assets/20250430121441325585.png
diff --git a/docs/assets/20250430121441664549.png b/docs/assets/20250430121441664549.png
diff --git a/docs/assets/20250430121442125737.png b/docs/assets/20250430121442125737.png
diff --git a/docs/assets/20250430121442525774.png b/docs/assets/20250430121442525774.png
diff --git a/docs/assets/20250430121442863891.png b/docs/assets/20250430121442863891.png
diff --git a/docs/assets/20250430121443139294.png b/docs/assets/20250430121443139294.png
diff --git a/docs/assets/20250430121443525154.png b/docs/assets/20250430121443525154.png
diff --git a/docs/troubleshooting/authentication/_category_.json b/docs/troubleshooting/authentication/_category_.json
@@ -0,0 +1,3 @@
+{
+  "label": "Authentication"
+}
diff --git a/...cation/code_403_the_caller_does_not_have_permission_status_permission_denied.md b/...cation/code_403_the_caller_does_not_have_permission_status_permission_denied.md
@@ -0,0 +1,40 @@
+---
+keywords: ['permission', 'permission_denied', 'code']
+slug: /code-403-the-caller-does-not-have-permission-status-permission-denied
+title: 'Code: 403, The caller does not have permission. status: PERMISSION_DENIED'
+---
+# Code: 403, The caller does not have permission. status: PERMISSION_DENIED
+
+This error typically occurs when your application or service account does not have the required permissions to access a resource in Google Cloud or Firebase.
+
+## What does this error mean?
+
+You may encounter this error due to one or more of the following reasons:
+
+- **Invalid or misconfigured service account JSON file**
+- **Insufficient permissions** assigned to the service account
+- **Missing or incorrect IAM roles** for the service account
+- **API not enabled** in the Google Cloud project
+
+## Example Full Error Message
+
+```
+Code: 403, The caller does not have permission. status: PERMISSION_DENIED
+```
+
+## How to Fix
+
+1. **Check your service account JSON file**
+   - Ensure you are using the correct file and it is not corrupted.
+2. **Verify IAM roles and permissions**
+   - Make sure the service account has the necessary roles (e.g., Editor, Owner, or specific roles required for your use case).
+3. **Enable required APIs**
+   - Go to the [Google Cloud Console](https://console.cloud.google.com/apis/library) and ensure all necessary APIs are enabled for your project.
+4. **Regenerate service account keys if needed**
+   - If you suspect the key is invalid, generate a new one and update your application configuration.
+
+:::tip[Pro Tip: Always Use Least Privilege Principle]
+When assigning IAM roles to your service account, follow the **principle of least privilege**—only grant the minimum permissions necessary for the task. This not only reduces the risk of misconfiguration but also enhances the overall security posture of your app.
+:::
+
+If you continue to experience issues, consult the [Google Cloud IAM documentation](https://cloud.google.com/iam/docs/troubleshooting-access) or contact support for further assistance.
diff --git a/docs/troubleshooting/authentication/custom_authentication_in_flutterFlow.md b/docs/troubleshooting/authentication/custom_authentication_in_flutterFlow.md
@@ -0,0 +1,79 @@
+---
+keywords: ['authentication', 'api', 'configuration']
+slug: /custom-authentication-in-flutterflow
+title: Custom Authentication in FlutterFlow
+---
+# Custom Authentication in FlutterFlow
+
+**Pre-Requisites to Enabling Custom Authentication:**
+
+Ensure you have a **custom server** with login and sign-up endpoints that return a JWT token upon success
+
+**Custom authentication** must be enabled in FlutterFlow, with entry and logged-in pages correctly set
+
+Here's an example: 
+
+![](../../assets/20250430121149388590.png)
+
+**Checklist for Troubleshooting**
+
+**Verify Server and API Endpoints**
+
+Confirm that your server is correctly returning JWT tokens for login and sign-up requests. The server's response should include the authentication token, refresh token, expiration time, and user ID (UID).
+
+Double-check the API endpoint configurations in FlutterFlow to match your server's requirements.
+
+**FlutterFlow Configuration**
+
+Make sure custom authentication is enabled in the project settings.
+
+Verify that the entry point and logged-in pages are set correctly.
+
+**UI Configuration**
+
+To facilitate the authentication flow, ensure your app has at least three pages: 
+
+Login
+
+Sign Up
+
+Home Page (i.e. the landing page when a user successfully authenticates)
+
+**API Integration and Authentication Flow**
+
+Test API calls from FlutterFlow to your server and ensure responses are received as expected.
+
+Upon successful authentication, use the backend FlutterFlow action to call the API. Then, utilize the response data to perform a "custom login" action within FlutterFlow.
+
+**Handling Tokens and User Data**
+
+Set up your FlutterFlow actions to correctly parse the API response, capturing the auth token, refresh token, expiration time, and user ID (UID). This data is crucial for managing user sessions.
+
+![](../../assets/20250430121149749937.png)
+**Navigation**
+
+If automatic navigation after login or sign-up is not working, you can disable it. 
+
+Then, opt for manual navigation to ensure users are directed to the correct page after authentication.
+
+**General Tips**
+
+Utilize logging both on your server and within FlutterFlow (snack bars, alerts) actions to track the authentication flow and identify any points of failure.
+
+Test the entire authentication flow, from entering credentials to accessing protected pages after login, to ensure there are no breaks in the process.
+
+By carefully following this guide, you should be able to troubleshoot and resolve common issues encountered when setting up custom authentication in FlutterFlow.
+
+:::tip[Pro Tip: Use Test Credentials First]
+Before integrating real user data, test your custom authentication flow using **dummy credentials** on your server. This allows you to debug token handling, API responses, and navigation logic safely—without risking user experience or exposing sensitive data.
+:::
+
+
+**More resources:**
+
+https://www.youtube.com/watch?v=hnX3CvBtGvI
+
+**Sample project:** https://app.flutterflow.io/project/custom-auth-checklist-fdjkno
+
+https://docs.flutterflow.io/data-and-backend/custom-authentication
+
diff --git a/docs/troubleshooting/authentication/delete_user_action_is_not_working_properly.md b/docs/troubleshooting/authentication/delete_user_action_is_not_working_properly.md
@@ -0,0 +1,25 @@
+---
+keywords: ['properly', 'delete', 'working']
+slug: /delete-user-action-is-not-working-properly
+title: Delete user action is not working properly
+---
+# Delete user action is not working properly!
+
+![](../../assets/20250430121300815719.png)
+
+When a user attempts to delete their account, they may find that the delete action doesn't work as expected. Here are some tips for troubleshooting this issue:
+
+Understand that the delete action in Firebase is designed to delete the user from the auth table only. This means that the user's document in the database will not be affected. If you want to delete the user's document from the database as well, you'll need to create a custom action with some custom code.
+
+After you've completed the delete action, it's important to log out the user. This is because there is no longer a user connected to the authenticated user in the app. Logging out will ensure that the user is routed back to the login page, which is the initial page of your project.
+
+:::tip[Pro Tip: Delete Related Data Before Deleting the User]
+Before calling the delete user action, make sure to first delete any related data (e.g., Firestore documents, Storage files) associated with the user. Once the user is deleted from Firebase Auth, their UID will no longer be accessible in the app session, making it difficult to reference their data afterward.
+:::
+
+
+Keep in mind that if the same user uses the same signup method to log in again, Firebase will create a new document in the database for them. This is because Firebase will connect the new login information to the old user document. 
+
+![](../../assets/20250430121301101693.png)Note: the action we do in Flutterflow is exactly the same action we can do manually to delete a user from the authentication table in Firebase.
+
+
diff --git a/docs/troubleshooting/authentication/google_sign_in_troubleshooting.md b/docs/troubleshooting/authentication/google_sign_in_troubleshooting.md
@@ -0,0 +1,64 @@
+---
+keywords: ['firebase', 'deployment', 'android']
+slug: /google-sign-in-troubleshooting
+title: Google Sign-In Troubleshooting
+---
+# Google Sign-In Troubleshooting
+
+If you face any issues while using the Google Sign-in feature from the exported app, then follow the given instructions to resolve them:
+
+**If App is Pushed to Play Store from FlutterFlow by using CodeMagic deployment:**
+
+Deploy the application to Google Play Store by using the CodeMagic Integration in FlutterFlow.
+![](../../assets/20250430121439158816.png)
+
+After this step, head over to the **Google Play Console**. Here open the app from the **All apps** list.
+![](../../assets/20250430121439605476.png)
+
+After opening the app dashboard, click on the **App Integrity **option under the **Setup** menu present on the left side of the screen**.**
+![](../../assets/20250430121440000724.png)
+
+After opening the **App Integrity **section, click on the **App Signing **tab. Here you'll find the** SHA-1 certificate fingerprint. **Copy this key by clicking on the **Copy** Icon. 
+![](../../assets/20250430121440426479.png)
+
+After completing the above steps, head over to the **Firebase console** and open the project settings of the same project.
+
+![](../../assets/20250430121440906814.png)
+
+Here, scroll down to the find **Your Apps **section. Select the **Android app** and click on **Add fingerprint. **You'll need to paste the copied SHA-1 Fingerprint here and then hit **Save.**
+![](../../assets/20250430121441325585.png)
+
+After this, you'll need to Regenerate the config files from FlutterFlow. To do this, open your app in **FlutterFlow** and then click on **Settings** **&gt;** **Firebase**.
+![](../../assets/20250430121441664549.png)
+
+Here, Click on the **Regenerate Config Files **button and then Click on **Generate Files.**
+![](../../assets/20250430121442125737.png)
+
+This issue should now be resolved. You can now re-test to confirm that the issue has been fixed.
+**If you have not yet pushed to the play store or are self-signing your app**
+If you're not using Play Store App Signing or have not deployed yet, follow the instructions in our documentation to use Keytool or Gradle's Signing Report to get your SHA-1.
+
+After manually generating the SHA-1 please make sure to update it in Firebase and then regenerate the config files in FlutterFlow using these instructions:
+
+Head over to the **Firebase console** and open the project settings of your project.
+
+![](../../assets/20250430121442525774.png)
+
+Here, scroll down to the find **Your Apps **section. Select the **Android app** and click on **Add fingerprint. **You'll need to paste the copied SHA-1 Fingerprint here and then hit **Save.**
+![](../../assets/20250430121442863891.png)
+
+After this, you'll need to Regenerate the config files from FlutterFlow. To do this, open your app in **FlutterFlow** and then click on **Settings** **&gt;** **Firebase**.
+![](../../assets/20250430121443139294.png)
+
+Here, Click on the **Regenerate Config Files **button and then Click on **Generate Files.**
+![](../../assets/20250430121443525154.png)
+* *
+This issue should now be resolved. You can now re-test to confirm that the issue has been fixed.
+
+*You can also refer to the **Google Play Services** documentation for more information.*
+
+:::tip[Pro Tip]
+If you're testing Google Sign-In inside FlutterFlow or using the app before deploying to the Play Store, make sure to **add your debug SHA-1 fingerprint** to Firebase. Without this, authentication won't work during development.
+
+After adding it, don't forget to **regenerate your Firebase config files in FlutterFlow** under `Settings → Firebase → Regenerate Config Files → Generate Files`.
+:::
diff --git a/...ion/how_to_retrieve_the_authenticated_type_from_firebase_auth_in_flutterflow.md b/...ion/how_to_retrieve_the_authenticated_type_from_firebase_auth_in_flutterflow.md
@@ -0,0 +1,49 @@
+---
+keywords: ['firebase', 'auth', 'authenticated']
+slug: /how-to-retrieve-the-authenticated-type-from-firebase-auth-in-flutterflow
+title: How to retrieve the authenticated type from Firebase auth in Flutterflow
+---
+# How to retrieve the authenticated type from Firebase auth in Flutterflow
+
+Understanding which authentication method a user has used can be useful for several reasons. For example, it can be leveraged for analytics, user support, and to customize the user's experience based on their login method. This method, however, is specific to Firebase Authentication.
+
+In our Flutter app, we can find out which method a user used to authenticate by leveraging Firebase's User.providerData property. Let's take a closer look at how this works in the code:
+
+```
+import 'package:firebase_auth/firebase_auth.dart';String getUserSignInMethod() {  final user = FirebaseAuth.instance.currentUser;  String signInMethod;  for (var info in user.providerData) {    signInMethod = info.providerId;  }  return signInMethod;}
+```
+
+Here's a breakdown of the code:
+
+We first import the FirebaseAuth package which gives us access to Firebase's authentication methods.
+
+Next, we define a function **`getUserSignInMethod`**. This function will return a string indicating the sign-in method the user used.
+
+Inside the function, we obtain the current user from FirebaseAuth using **`FirebaseAuth.instance.currentUser`**.
+
+We then declare a string **`signInMethod`** that will store the name of the provider used for sign-in.
+
+**`user.providerData`** is an iterable that provides UserInfo for each sign-in method used by the user. We loop over this iterable using a **`for`** loop.
+
+In each iteration, we assign the **`providerId`** to our **`signInMethod`** string. The **`providerId`** can be 'google.com' for Google, 'facebook.com' for Facebook, and 'password' for email and password.
+
+After the loop is done, the function returns **`signInMethod`** string which indicates the sign-in method the user used.
+
+The function **`getUserSignInMethod()`** returns a String value which corresponds to the providerId of the user's sign-in method.
+Here are examples of how the return value might look:
+
+If the user has signed in using Google, the function will return: **`'google.com'`**
+
+If the user has signed in using Facebook, the function will return: **`'facebook.com'`**
+
+If the user has signed in using Email and Password, the function will return: **`'password'`**
+
+These are the identifiers used by Firebase to represent different sign-in methods.Please, thoroughly test this function to ensure it fits your specific requirements.
+
+:::tip[Pro Tip]
+In FlutterFlow, if you want to display or use the user's sign-in method in your UI logic (e.g., showing different UIs for Google vs. email login), you can create a custom function using the `providerId` approach shown in the article and **connect it to a custom action**. This allows you to make dynamic decisions inside your app based on how the user authenticated.
+
+Remember to return the result from the custom function and store it in an App State variable for easy access throughout your app.
+:::
+
+For more details, you can refer to Firebase's official documentation, as well as our **documentation**, **community tutorials**, **Youtube channel**, **blog**, and **intercom articles**.
diff --git a/...ation/my_app_is_starting_from_homepage_after_logging_in_once_in_the_run_mode.md b/...ation/my_app_is_starting_from_homepage_after_logging_in_once_in_the_run_mode.md
@@ -0,0 +1,25 @@
+---
+keywords: ['homepage', 'mode', 'after']
+slug: /my-app-is-starting-from-homepage-after-logging-in-once-in-the-run-mode
+title: My app is starting from HomePage after logging in once in the Run Mode
+---
+# My app is starting from HomePage after logging in once in the Run Mode
+
+If your app always starts from the HomePage after logging in once (especially in Run Mode), this is likely due to cached authentication or session data in your browser.
+
+## Troubleshooting Steps
+
+- **Clear your browser cache and history.**
+
+![](../../assets/20250430121300291232.png)
+
+- **Try a different browser** or use **incognito/private browsing mode** to see if the issue persists.
+
+If the problem continues, consider checking your authentication flow and session management in your app settings.
+
+:::tip[Pro Tip]
+When testing in Run Mode, **FlutterFlow retains your authentication state across sessions** unless explicitly reset. To simulate a real first-time user experience, consider adding a **"Log Out" button** on your HomePage that calls the `Sign Out` action. This ensures that the next time you run the app, it starts from the login screen rather than using stored session data.
+:::
+
+
+
diff --git a/...ubleshooting/authentication/safetynet_phone_sign-in_issue_on_android_devices.md b/...ubleshooting/authentication/safetynet_phone_sign-in_issue_on_android_devices.md
@@ -0,0 +1,40 @@
+---
+keywords: ['android', 'signing', 'release']
+slug: /safetynet-phone-sign-in-issue-on-android-devices
+title: SafetyNet phone sign-in issue on android devices
+---
+# SafetyNet phone sign-in issue on android devices
+
+It looks like you are experiencing an issue with using the Firebase Phone Authentication method. To troubleshoot this issue, there are a few things you can try:
+
+Make sure you have correctly configured the Firebase Phone Authentication method in your app. This includes setting up a project in the Firebase console and adding the necessary dependencies to your app.
+
+Check that you have properly implemented the phone authentication flow in your app. This includes prompting the user to enter their phone number, sending a verification code to the user's phone, and verifying the code that the user enters.
+
+Make sure that you have correctly configured the safety net and reCAPTCHA checks in your app. This may involve adding the necessary dependencies and configuring the keys in your app.
+
+If you are using an emulator to test your app, try testing on a physical device instead. Emulators may not always behave the same as physical devices, and this could be causing the issue you are experiencing.
+
+If you are still experiencing issues, try reviewing the documentation and tutorials provided by Firebase to ensure that you have correctly implemented the phone authentication flow in your app.
+
+Solution: Read more information here
+![](../../assets/20250430121259958091.png)
+To use phone number authentication, Firebase must be able to verify that phone number sign-in requests are coming from your app. There are two ways Firebase Authentication accomplishes this:
+**1- SafetyNet**:If a user has a device with Google Play Services installed, and Firebase Authentication can verify the device as legitimate with Android SafetyNet, phone number sign-in can proceed.
+To enable SafetyNet for use with Firebase Authentication:
+
+In the Google Cloud Console, enable the Android Device Verification (DEPRECATED) API for your project. The default Firebase API Key will be used, and needs to be allowed to access the DeviceCheck API.
+
+If you haven't yet specified your app's SHA-256 fingerprint, do so from the Settings Page of the Firebase console. Refer to Authenticating Your Client for details on how to get your app's SHA-256 fingerprint.
+
+The SafetyNet Attestation API is deprecated and has been replaced by the Play Integrity API. We are working on a migration path to the Play Integrity API, which we expect to make available within the SafetyNet deprecation timeline. After 31 January 2023, you will not be able to enable the Android Device Verification (SafetyNet) API in the Google Cloud Console. To enable the Android Device Verification (SafetyNet) API in a new project after Jan 31, 2023, submit the SafetyNet Attestation API Onboarding form.
+SafetyNet has a default quota that is sufficient for most apps. See SafetyNet Quota Monitoring for more information.
+2- **reCAPTCHA verification**:In the event that SafetyNet cannot be used, such as when the user does not have Google Play Services support, or when testing your app on an emulator, Firebase Authentication uses a reCAPTCHA verification to complete the phone sign-in flow. The reCAPTCHA challenge can often be completed without the user having to solve anything. Please note that this flow requires that a SHA-1 is associated with your application. This flow also requires your API Key to be unrestricted or allow listed for "your-project-name.firebaseapp.com".
+The reCAPTCHA flow will only be triggered when SafetyNet is unavailable or your device does not pass suspicion checks. Nonetheless, you should ensure that both scenarios are working correctly.
+
+Next:
+**Release mode**If you're releasing your app to the Play Store, you must add the SHA certificate fingerprints from the Play Console To get the keys for the release app, navigate to **Play Store Console &gt; Your project &gt; Release Management –&gt; App Signing** and copy the **SHA-1** and **SHA-256** keys.
+
+
+
+![](../../assets/20250430121300291238.png)