Firebase FAQ

Have other challenges or don't see your issue outlined below? Please report a bug or request a feature and join the Stack Overflow discussions.

A Firebase project is the top-level entity for Firebase. In a project, you can register your Apple, Android, or web apps. After you register your apps with Firebase, you can add the product-specific Firebase SDKs to your app, like Analytics, Cloud Firestore, Crashlytics, or Remote Config.

You should register your Apple, Android, and web app variants within a single Firebase project. You can use multiple Firebase projects to support multiple environments, such as development, staging, and production.

Here are some resources for learning more about Firebase projects:

  • Understand Firebase projects — provides brief overviews of several important concepts about Firebase projects, including their relationship with Google Cloud and the basic hierarchy of a project and its apps and resources.
  • General best practices for setting up Firebase projects — provides general, high-level best practices for setting up Firebase projects and registering your apps with a project so that you have a clear development workflow that uses distinct environments.

Note that for all Firebase projects, Firebase automatically adds a label of firebase:enabled within the Labels page for your project in the Google Cloud console. Learn more about this label in our FAQ.

A Google Cloud organization is a container for Google Cloud projects (including Firebase projects). This hierarchy enables better organization, access management, and auditing of your Google Cloud and Firebase projects. For more information, refer to Creating and Managing Organizations.

You may have existing Google Cloud projects managed through the Google Cloud console or the Google APIs console.

You can add Firebase to these existing Google Cloud projects using any of the following options:

Learn more details about adding Firebase to a Google Cloud project.

Firebase is deeply integrated with Google Cloud. Projects are shared between Firebase and Google Cloud, so projects can have Firebase services and Google Cloud services enabled. You can access the same project from the Firebase console or the Google Cloud console. Specifically:

  • Certain Firebase products are backed directly by Google Cloud, such as Cloud Storage for Firebase. The list of products backed by Google Cloud will continue to grow over time.
  • Many of your settings, including collaborators and billing information, are shared by Firebase and Google Cloud. Your usage of both Firebase and Google Cloud appears on the same bill.

In addition, when you upgrade to the Blaze plan, you can use any of Google Cloud's world-class Infrastructure-as-a-Service and APIs directly inside your Firebase project, at standard Google Cloud pricing. You can also export data from Google Cloud directly to BigQuery for analysis. To learn more, see Link BigQuery with Firebase.

There are many security-enhancing, latency-improving, and time-saving benefits to using Google Cloud with Firebase (versus other, cloud services that are not co-located). Check out the Google Cloud site for more details.

In the Labels page for your project in the Google Cloud console, you may see a label of firebase:enabled (specifically, a Key of firebase with a Value of enabled).

Firebase automatically added this label because your project is a Firebase project, which means that your project has Firebase-specific configurations and services enabled for it. Learn more about the relationship between Firebase projects and Google Cloud.

We strongly recommend that you don't modify or delete this label. This label is used by Firebase and Google Cloud to list your Firebase projects (for example, using the REST API projects.list endpoint or in menus within the Firebase console).

Be aware that manually adding this label to your list of project labels does NOT enable Firebase-specific configurations and services for your Google Cloud project. To do that, you need to add Firebase using the Firebase console (or, for advanced use cases, using the Firebase Management REST API or the Firebase CLI).

This FAQ is applicable if you don't see your Firebase project in the following places:

  • In a list of projects that you're viewing within the Firebase console
  • In the response from calling the REST API projects.list endpoint
  • In the response from running the Firebase CLI command firebase projects:list

Try these troubleshooting steps:

  1. First, try accessing your project by visiting the project's URL directly. Use the following format:
    https://console.firebase.google.com/project/PROJECT_ID/overview
  2. If you can't access the project or receive permissions errors, check the following:
    • Make sure that you're signed into Firebase using the same Google account that has access to the project. You can sign in and out of the Firebase console via your account avatar in the top-right corner of the console.
    • Check if you can view the project in the Google Cloud console.
    • Make sure that your project has the label firebase:enabled in the Labels page for your project in the Google Cloud console. Firebase and Google Cloud use this label to list your Firebase projects. If you do not see this label but the Firebase Management API is enabled for your project, then manually add the label (specifically, a Key of firebase with a Value of enabled).
    • Make sure that you're assigned one of the basic IAM roles (Owner, Editor, Viewer) or a role that has Firebase-related permissions in it, for example a Firebase predefined role. You can view your role(s) in the IAM page of the Google Cloud console.
    • If your project belongs to a Google Cloud organization, you may require additional permissions to see the project listed in the Firebase console. Contact the person who manages your Google Cloud organization to give you the appropriate role to view the project, for example the Browser role.

If none of the troubleshooting steps above enable you to see your project in a list of Firebase projects, contact Firebase Support.

  • Spark pricing plan: Project-creation quota is limited to a small number of projects (usually around 5-10).
  • Blaze pricing plan: Project-creation quota is still limited, but it may increase with the linking of a Cloud Billing account in good standing.

The limit on project-creation quota is rarely a concern for most developers, but if needed, you can request an increase in project quota.

Be aware that the complete deletion of a project requires 30 days and counts toward project quota until the project is fully deleted.

A Firebase project is a container for Firebase Apps across Apple, Android, and web. Firebase restricts the total number of Firebase Apps within a Firebase project to 30.

After this number, performance starts to degrade (especially for Google Analytics) and eventually, at a higher number of apps, some product functionality stops working. Additionally, if you use Google sign-in as an authentication provider, an underlying OAuth 2.0 client ID is created for each app in your project. There's a limit of around 30 client IDs that can be created within a single project.

You should ensure that all Firebase Apps within a single Firebase project are platform variants of the same application from an end-user perspective. For example, if you develop a white label application, each independently labeled app should have its own Firebase project, but the Apple and Android versions of that label can be in the same project. Read more detailed guidance in our general best practices for setting up Firebase projects.

In the rare case your project requires more than 30 apps, you can request an app limit increase. Your project must be on the Blaze pricing plan to make this request. Visit the Google Cloud console to make your request and have it evaluated. Learn more about quota management in the Google Cloud documentation.

In the Firebase console, you can tag your Firebase projects with their environment type, either as Production or Unspecified (non-prod) environments.

Tagging your project as an environment type has no effect on how your Firebase project works or its features. However, the tagging can help you and your team manage your various Firebase projects for the app lifecycle.

If you tag your project as a production environment, we add a brightly colored Prod tag to the project in the Firebase console, reminding you that any changes could affect your associated production apps. In the future, we might add more features and safeguards for Firebase projects tagged as production environments.

To change the environment type of your Firebase project, go to Project settings > General, then in the Your project card under Environment, click to change the environment type.

In the Firebase console, go to your Project settings. Scroll down to the Your apps card, then click on the desired Firebase App to view the app's information, including its App ID.

Here are some example App ID values:

  • Firebase iOS Apps: 1:1234567890:ios:321abc456def7890
  • Firebase Android Apps: 1:1234567890:android:321abc456def7890
  • Firebase Web Apps: 1:1234567890:web:321abc456def7890
  • For linking your Google Play account, you need the following:
    • Either of the following Firebase roles: Owner or Firebase Admin
      and
    • Either of the following Google Play access levels: account Owner or Admin
  • For linking your AdMob app, you need to be both a Firebase project owner and an AdMob administrator.
  • For linking your AdWords account, you need to be both a Firebase project owner and an AdWords administrator.
  • For linking your BigQuery project, you need to be the Firebase project owner.

On Apple platforms, the Firebase pod contains a NOTICES file which includes the relevant entries. The Firebase Android SDK contains a helper Activity for showing license information.

Permissions and access to Firebase projects

To manage the role(s) assigned to each project member, you must be an Owner of the Firebase project (or be assigned a role with the permission resourcemanager.projects.setIamPolicy).

Here are the places where you can assign and manage roles:

  • The Firebase console offers a simplified way to assign roles to project members in the Users and permissions tab of > Project settings. In the Firebase console, you can assign any of the basic roles (Owner, Editor, Viewer), the Firebase Admin/Viewer roles, or any of the Firebase predefined product-category roles.
  • The Google Cloud console offers an expansive set of tools to assign roles to project members in the IAM page. In the Cloud console, you can also create and manage custom roles, as well as give service accounts access to your project.

    Note that in the Google Cloud console, project members are called principals.

If the Owner of your project can no longer perform the tasks of an Owner (for example, the person left your company) and your project isn't managed via a Google Cloud organization (see next paragraph), you can contact Firebase Support and check with them about how to request access to the Firebase project.

Note that if a Firebase project is part of a Google Cloud organization, it may not have an Owner. If you're unable to find an Owner for your Firebase project, contact the person who manages your Google Cloud organization to assign an Owner for the project.

You can view project members and their roles in the following places:

  • If you have access to the project in the Firebase console, you can view the list of project members, including Owners, in the Users and permissions page of the Firebase console.
  • If you do not have access to the project in the Firebase console, check if you have access to the project in the Google Cloud console. You can view the list of project members, including Owners, in the IAM page of the Google Cloud console.

If the Owner of your project can no longer perform the tasks of an Owner (for example, the person left your company) and your project isn't managed via a Google Cloud organization (see next paragraph), you can contact Firebase Support to have a temporary Owner assigned.

Note that if a Firebase project is part of a Google Cloud organization, it may not have an Owner. Instead, the person who manages your Google Cloud organization can perform many tasks that an Owner can do. However, to perform several Owner-specific tasks (like assigning roles or managing Google Analytics properties), the administrator may need to assign themselves the actual Owner role to perform those tasks. If you're unable to find an Owner for your Firebase project, contact the person who manages your Google Cloud organization to assign an Owner for the project.

To ensure proper management of a Firebase project, it must have an Owner. A project's Owner is the person who can perform several important administrative actions (like assigning roles and managing Google Analytics properties), and Firebase Support can only fulfill administrative requests from demonstrated project Owners.

After you set up the Owner(s) for a Firebase project, it's important to keep those assignments up-to-date.

Note that if a Firebase project is part of a Google Cloud organization, the person who manages your Google Cloud organization can perform many tasks that an Owner can do. However, for several Owner-specific tasks (like assigning roles or managing Google Analytics properties), the administrator may need to assign themselves the actual Owner role to perform those tasks.

The email you received should contain a link to open your Firebase project. Clicking the link in the email should open the project in the Firebase console.

If you're not able to open the project in the link, make sure that you're signed into Firebase using the same Google account that received the email about the project. You can sign in and out of the Firebase console via your account avatar in the top-right corner of the console.

Note that if you're the administrator of a Google Cloud organization, you may be notified about changes to Firebase projects inside your organization. However, you may not have sufficient permissions to open the Firebase project. In these cases, the simplest solution is to assign yourself the actual Owner role to open the project and perform the required actions. Learn more about why and when to assign the Owner role.



Platforms and frameworks

Visit the platform-specific troubleshooting & FAQ pages for helpful tips and answers for more FAQ.



Firebase console

The Firebase console can be accessed from recent versions of popular desktop browsers such as Chrome, Firefox, Safari and Edge. Mobile browsers are currently not fully supported.

This FAQ is applicable if you're experiencing either of the following issues:

  • The Firebase console returns an error page that says your project may not exist or that you don't have access to the project.
  • The Firebase console doesn't display your project even when you enter its project ID or project name in the console's search field.

Try these troubleshooting steps:

  1. First, try accessing your project by visiting the project's URL directly. Use the following format:
    https://console.firebase.google.com/project/PROJECT-ID/overview
  2. If you still can't access the project or receive permissions errors, check the following:
    • Make sure that you're signed into Firebase using the same Google account that has access to the project. You can sign in and out of the Firebase console via your account avatar in the top-right corner of the console.
    • Make sure that the Firebase Management API is enabled for the project.
    • Make sure that you're assigned one of the basic IAM roles (Owner, Editor, Viewer) or a role that has Firebase-related permissions in it, for example a Firebase predefined role. You can view your role(s) in the IAM page of the Google Cloud console.
    • If your project belongs to a Google Cloud organization, you may require additional permissions to see the project listed in the Firebase console. Contact the person who manages your Google Cloud organization to give you the appropriate role to view the project, for example the Browser role.

If none of the troubleshooting steps above enable you to find or access your project, contact Firebase Support.

This FAQ is applicable if you're experiencing any of the following issues:

  • A page in the Firebase console never finishes loading.
  • Data within a page doesn't load as expected.
  • You receive browser error messages when loading the Firebase console.

Try these troubleshooting steps:

  1. Check the Console row of the Firebase Status Dashboard for any possible service interruptions.
  2. Make sure that you're using a supported browser.
  3. Try to load the Firebase console in an incognito or private window.
  4. Disable all browser extensions.
  5. Verify that the network connection is not blocked by ad blocker, antivirus, proxy, firewall, or other software.
  6. Try loading the Firebase console using a different network or device.
  7. If using Chrome, check the Developer Tools Console for any errors.

If none of the troubleshooting steps above resolve the issue, contact Firebase Support.

The language setting for the Firebase console is based on the language selected in your Google account settings.

To change your language preference, see Change language.

The Firebase console supports the following languages:

  • English
  • Brazilian Portuguese
  • French
  • German
  • Indonesian
  • Japanese
  • Korean
  • Russian
  • Simplified Chinese
  • Spanish
  • Traditional Chinese

The Firebase console and Google Cloud console use the same underlying roles and permissions. Learn more about roles and permissions in the Firebase IAM documentation.

Firebase supports the fundamental (basic) roles of Owner, Editor, and Viewer:

  • A project Owner can add other members to the project, set up integrations (project linking to services like BigQuery or Slack), and has full edit access for the project.
  • A project Editor has full edit access for the project.
  • A project Viewer has only read access for the project. Note that the Firebase console currently does not hide/disable edit UI controls from project Viewers, but these operations will fail for project members assigned the Viewer role.

Firebase also supports:

  • Firebase predefined roles — Curated Firebase-specific roles that enable more granular access control than the basic roles of Owner, Editor, and Viewer.
  • Custom roles — Fully customized IAM roles that you create to tailor a set of permissions that meet the specific requirements of your organization.



Firebase Local Emulator Suite

This message means the Emulator Suite has detected it may be running a particular product emulator using different project IDs. This may indicate a misconfiguration, and can cause issues when emulators try to communicate with one another, and when you try to interact with emulators from your code. If project IDs don't match, it often appears that data is missing, since data stored in emulators is keyed to projectID, and interoperability depends on matching project IDs.

This has been a common source of confusion among developers, so by default the Local Emulator Suite will now only allow running with a single project ID, unless you specify otherwise in the firebase.json configuration file. If an emulator detects more than one project ID, it will log a warning and potentially throw a fatal error.

Check your project ID declaration(s) for mismatches in:

  • The default project set at the command line. By default, the project ID will be taken on startup from the project selected with firebase init or firebase use. To view the list of projects (and see which one is selected) use firebase projects:list.
  • Unit tests. The project ID is often specified in calls to the Rules Unit Testing library methods initializeTestEnvironment or initializeTestApp. Other testing code may initialize with initializeApp(config).
  • The command line --project flag. Passing the Firebase CLI --project flag overrides the default project. You'll need to ensure the value of the flag matches the project ID in unit tests and app initialization.

Platform-specific places to check:

Web The projectId property in your JavaScript firebaseConfig object, used in initializeApp.
Android The project_id property inside the google-services.json configuration file.
Apple platforms The PROJECT_ID property in the GoogleService-Info.plist configuration file.

To disable single project mode, update firebase.json with the singleProjectMode key:

{
  "firestore": {
    ...
  },
  "functions": {
    ...
  },
  "hosting": {
    ...
  },
  "emulators": {
    "singleProjectMode": false,
    "auth": {
      "port": 9099
    },
    "functions": {
      "port": 5001
    },
    ...
  }
}



Pricing

For pricing FAQs specific to a product, see the product's section on this page or within its dedicated product documentation.

Firebase's paid infrastructure products are the Realtime Database, Cloud Storage for Firebase, Cloud Functions, Hosting, Test Lab, and phone authentication. We offer a no-cost tier for all of these features.

Firebase also has many no-cost products: Analytics, Cloud Messaging, the Notifications composer, Remote Config, App Indexing, Dynamic Links, and Crash Reporting. Use of these products is subject only to the product's traffic control policies (e.g. quotas, fair access and other service protections) in all plans, including our no-cost Spark plan. In addition, all Authentication features beyond phone authentication are no-cost.

Firebase paid services can be used under the Google Cloud Free Trial. New Google Cloud and Firebase users can take advantage of a 90-day trial period that includes $300 in free Cloud Billing credits to explore and evaluate Google Cloud and Firebase products and services.

During the Google Cloud Free Trial period, you'll be provided a Free Trial Cloud Billing account. Any Firebase project that uses that billing account will be on the Blaze pricing plan during the free trial period.

Don't worry, setting up this Free Trial Cloud Billing account does not enable us to charge you. You are not charged unless you explicitly enable billing by upgrading your Free Trial Cloud Billing account to a paid account. You can upgrade to a paid account at any time during the trial. After you've upgraded, you can still use any remaining credits (within the 90-day period).

Once the free trial expires, you'll need to either downgrade your project to the Spark pricing plan or set up the Blaze pricing plan in the Firebase console to continue using your Firebase project.

Learn more about the Google Cloud Free Trial.

Spark pricing plan

Our Spark plan is a great place to develop your app at no cost. You get all the no-cost Firebase features (Analytics, the Notifications composer, Crashlytics, and so on) and generous amounts of our paid infrastructure features. However, if you exceed your Spark plan resources in a calendar month, your app will be shut off for the remainder of that month. In addition, Google Cloud features are not available when using the Spark plan.

Blaze pricing plan

Our Blaze plan is designed for production apps. The Blaze plan also allows you to extend your app with paid Google Cloud features. You pay only for the resources that you consume, allowing you to scale with demand. We strive to make our Blaze plan prices competitive with industry-leading cloud providers.

Yes, you can upgrade, downgrade, or cancel at any time. Note that we don't provide prorated refunds for downgrades or cancellations. This means that if you downgrade or cancel before the end of your billing period, you still pay for the remainder of the month.

No-cost usage on the Blaze plan is calculated daily. Usage limits also differ from the Spark plan for Cloud Functions, phone authentication, and Test Lab.

For Cloud Functions, no-cost usage on the Blaze plan is calculated at the Cloud Billing account level, not the project level and has the following limits:

  • 2M invocations/month
  • 400K GB-seconds/month
  • 200K CPU-seconds/month
  • 5 GB of networking egress/month

For phone authentication, no-cost usage on the Blaze plan is calculated monthly.

For Test Lab, no-cost usage on the Blaze plan has the following limits:

  • 30 physical device minutes/day
  • 60 virtual device minutes/day

No-cost usage from the Spark plan is included in the Blaze plan. No-cost usage does not reset when moving to a Blaze plan.

If a Cloud Billing account is added to a project in the Google Cloud console, the same project will automatically be upgraded to the Firebase Blaze plan if that project is currently on the Spark plan.

In contrast, if an existing active Cloud Billing account is removed from a project in the Google Cloud console, that project will be downgraded to the Firebase Spark plan.

You can track your usage of project resources in the Firebase console on any of the following dashboards:

No, you cannot currently cap your Blaze plan usage. We are evaluating options for supporting caps on Blaze plan usage.

Blaze users can define a budget for their project or account, and receive alerts as their spending approaches those limits. Learn how to set up budget alerts.

All Firebase apps, including those using no-cost plans, come with email support from Firebase staff during US Pacific business hours. All accounts have unlimited support for billing-related issues, account-related issues, technical (troubleshooting) questions, and incident reports.

Our Spark plan can be used by any type of individual or organization, including nonprofits, schools, and open-source projects. Since these plans already include generous quotas, we don't offer any special discounts or plans for open-source, nonprofit, or educational projects.

Our Blaze plan is suitable for enterprises of all sizes, and our SLA meets or exceeds the industry standard for cloud infrastructure. However, we do not currently offer enterprise contracts, pricing, or support, nor do we offer dedicated infrastructure hosting (that is, on-premises installations) for services like our Realtime Database. We are hard at work adding some of these features.

We offer ad-hoc pricing in the Blaze plan, where you pay only for the features you use.

The Firebase pricing plans are separate from Ads, so there are no advertising credits without cost. As a Firebase developer, you are able to "link" your Ads account to Firebase to support conversion tracking.

All ads campaigns are managed directly in Ads, and Ads billing is managed from the Ads console.

In January 2020, the Flame pricing plan ($25/mo of additional quota) was removed as an option for new sign-ups. Existing plan users were granted a grace period to migrate their projects off the Flame plan. In February 2022, the remaining projects on the Flame pricing plan were downgraded to the Spark pricing plan.
Accordingly,

  • Existing Spark and Blaze plan projects and any new projects can no longer switch to or sign up for the Flame plan.
  • If you moved an existing Flame plan project to a different pricing plan, the project cannot return to the Flame plan.
  • Projects downgraded to the Spark plan can be upgraded to the Blaze plan to resume additional paid services.
  • References to the Flame plan have been removed from documentation.

Do you have more questions about the Flame plan retirement? Read some of the additional FAQs below.

Want to learn about the other pricing plans offered by Firebase? Visit our Firebase pricing page! If you'd like to start moving any existing projects to another pricing plan, you can do that in the Firebase console for your project.

Additional FAQs about the Flame plan retirement

Sign up for the Blaze pricing plan, and make sure to set budget alerts.

No, Firebase isn't offering special access for projects to switch to or sign-up for the Flame plan.

Switching to the Flame plan is no longer possible. For access to services provided by the Flame plan, make sure that you're using the Blaze pricing plan, and consider setting up budget alerts for your project.

If your project requires additional quota beyond what is provided with the Spark plan, you'll need to upgrade your project to the Blaze pricing plan.

Over the years, we've seen declining usage of the Flame plan, and most projects that use the plan are not consuming its full value. Maintaining this pricing plan is generally not cost-effective, and we feel that we can serve everyone better if resources went to other Firebase initiatives.



Privacy

Check out the page Privacy and Security in Firebase.

Yes. This is currently iOS-only, but may change in the future. The Firebase Apple platforms SDK includes the FirebaseCoreDiagnostics framework by default. This framework is used by Firebase to collect SDK usage and diagnostics information to help prioritize future product enhancements. FirebaseCoreDiagnostics is optional, so if you would like to opt out of sending Firebase diagnostic logs, you can do so by unlinking the library from your application. You can browse the full source, including logged values, on GitHub



A/B Testing

You are allowed up to 300 experiments per project, which could consist of up to 24 running experiments, with the rest as draft or completed.

Linking to a different Google Analytics property will cause you to lose access to experiments created beforehand. To regain access to a previous experiment, re-link your project to the Google Analytics property that was linked when the experiment was created.

If you've already linked Firebase and Google Analytics, but still see a message that Google Analytics is not linked, make sure that an Analytics stream exists for all apps in your project. Currently, all apps in a project must be connected to a Google Analytics stream to use A/B Testing.

You can find the list of all active streams on the Google Analytics integration details page within the Firebase console, accessed from Project Settings Integrations Google Analytics Manage.

Creating a Google Analytics stream for any app that does not have one should resolve the issue. There are a few ways to create streams for missing apps:

  • If you only have one or two apps missing an associated Google Analytics stream, you can choose one of the following methods to add a Google Analytics stream:
    • Delete and re-add any app without an active stream in the Firebase console.
    • From the Google Analytics console, select Admin, click Data Streams, then click Add stream, add the missing app's details, and click Register app.
  • If you have more than a few missing app streams, unlinking and relinking your Google Analytics property is the fastest and most efficient way to create the missing app streams:
    1. From Project Settings, select Integrations.
    2. Within the Google Analytics card, click Manage to access Firebase and Google Analytics settings.
    3. Make a note of the Google Analytics Property ID and the Linked Google Analytics account.
    4. Click More and select Unlink Analytics from this project.
    5. Review the warning that appears (don't worry here; you will relink the same property in the next step), then click Unlink Google Analytics.

      When unlinking is complete, you'll be redirected to the Integrations page.
    6. Within the Google Analytics card, click Enable to begin the relinking process.
    7. Select your Analytics account from the Select account list.
    8. Next to Automatically create a new property in this account, click Edit and, from the Analytics property list that appears, select your property ID.

      A list of all apps in your project appears. Existing stream mappings for each app are listed, and apps that do not have a stream will have one created for them.
    9. Click Enable Google Analytics to relink the property.
    10. Click Finish.

If you still receive an error creating A/B Tests with Remote Config after performing these steps, contact Firebase Support.



AdMob

No, Windows apps are not currently supported.

You can link an AdMob app to a Firebase app via the AdMob console. Learn how.

In order to do this linking, you need the following access:

  • AdMob: You need to be an AdMob admin.
  • Firebase: You must have the firebase.links.create permission, which is included in the Owner role and the Firebase Admin role.
  • Google Analytics: You must have the Edit role or Manage Users role for the property associated with the Firebase project. Learn more.

For multi-user AdMob accounts, the user who created the first Firebase link and accepted the Firebase Terms of Service is the only user who can create new links between AdMob apps and Firebase apps.

To use AdMob, always use the Google Mobile Ads SDK as described in this FAQ. Additionally and optionally, if you want to collect user metrics for AdMob, then include the Firebase SDK for Google Analytics in your app.




Analytics

Google Analytics is a free and unlimited analytics solution that works with Firebase features to deliver powerful insights. It enables you to view event logs in Crashlytics, notification effectiveness in FCM, deep link performance for Dynamic Links, and in-app purchase data from Google Play. It powers advanced audience targeting in Remote Config, Remote Config personalization, and more.

Google Analytics acts as a layer of intelligence in the Firebase console to provide you with more actionable insights about how to develop a high quality app, grow your user base, and earn more money.

To get started, read the documentation.

By default, your Google Analytics data is used to enhance other Firebase and Google features. You can control how your Google Analytics data is shared in your project settings anytime. Learn more about Data sharing settings.

From the Admin page in your Google Analytics property, you can update your property settings, such as:

  • Data sharing settings
  • Data retention settings
  • Time zone and currency settings

To update your property settings, follow these steps:

  1. In the Firebase console, go to your > Project settings.
  2. Go to the Integrations tab, and then in the Google Analytics card, click Manage or View link.
  3. Click the link for your Google Analytics account to open the account and property settings.

Yes. See the Configure Data Collection and Usage page for more details.

You can find a summary of these changes in the Firebase Help Center article New Google Analytics 4 functionality in Google Analytics for Firebase.

Analytics data resides within the Google Analytics property — not within the Firebase project. If you delete or unlink the property, then the Analytics data will not be accessible to Firebase and you'll see an empty Analytics dashboard in the Firebase console. Note that since the data still resides in the previously linked property, you can always relink the property to Firebase and see the Analytics data in the Firebase console.

Linking a brand new Google Analytics account (and thus a new Google Analytics property) to your Firebase project will result in an empty Analytics dashboard in the Firebase console. However, if your previously linked property still exists, then you can move the existing data from the old property to the new property.

No. If your property has been deleted, it isn't possible to undelete the property or retrieve the previously collected Analytics data stored in that property.

If you'd like to start using Google Analytics again, you can link either a new property or an existing property to your Firebase project. You can do this linking in either the Firebase console or the Google Analytics UI. Learn more about linking a Google Analytics property to your Firebase project.

If you'd like to start using Google Analytics again, you can link either a new property or an existing property to your Firebase project. You can do this linking in either the Firebase console or the Google Analytics UI. Learn more about linking a Google Analytics property to your Firebase project.

Note that since all Analytics data is stored in the property (not the Firebase project), the previously collected Analytics data cannot be retrieved.

Several Firebase products rely on the Google Analytics integration. If your Analytics property and its data are deleted, the following will happen if you use the following products:

  • Crashlytics — You can no longer see crash-free users, breadcrumb logs, and/or velocity alerts.
  • Cloud Messaging and In-App Messaging — You can no longer use targeting, campaign metrics, audience segmentation, and analytics labels.
  • Remote Config — You can no longer use targeted configurations or Personalization.
  • A/B Testing — You can no longer use A/B Testing since the experiment measurement is supplied by Google Analytics.
  • Dynamic Links — Any feature that relies on data from Google Analytics will be disrupted.

In addition, the following integrations will be affected:

You can reframe the problem by "negatively targeting" these users. For example, reframe the problem as "Don't show ads to people who have bought something", and form an audience of those users to target.

Your audiences and user properties will be synced. For some features, you'll need to use the Google Analytics interface, such as segmentation and closed funnels. You can access the Google Analytics interface directly via deep-links from the Firebase console.

Any changes you make from the Firebase console can also be performed in Google Analytics, and those changes will be reflected in Firebase.



Authentication

Firebase Authentication supports phone number verification globally, but not all networks reliably deliver verification messages. The following regions have good rates of delivery, and should be expected to work well for phone authentication. Where noted, some carriers are unavailable in a region due to poor delivery success rates.

Region Code
ADAndorra
AEUnited Arab Emirates
AFAfghanistan
AGAntigua and Barbuda
ALAlbania
AMArmenia
AOAngola
ARArgentina
ASAmerican Samoa
ATAustria
AUAustralia
AWAruba
AZAzerbaijan
BABosnia and Herzegovina
BBBarbados
BDBangladesh
BEBelgium
BFBurkina Faso
BGBulgaria
BJBenin
BMBermuda
BNBrunei Darussalam
BOBolivia
BRBrazil
BSBahamas
BTBhutan
BWBotswana
BYBelarus
BZBelize
CACanada
CDCongo, (Kinshasa)
CFCentral African Republic
CGCongo (Brazzaville)
CHSwitzerland
CICôte d'Ivoire
CKCook Islands
CLChile
CMCameroon
COColombia
CRCosta Rica
CVCape Verde
CWCuraçao
CYCyprus
CZCzech Republic
DEGermany
DJDjibouti
DKDenmark
DMDominica
DODominican Republic
DZAlgeria
ECEcuador
EGEgypt
ESSpain
ETEthiopia
FIFinland
FJFiji
FKFalkland Islands (Malvinas)
FMMicronesia, Federated States of
FOFaroe Islands
FRFrance
GAGabon
GBUnited Kingdom
GDGrenada
GEGeorgia
GFFrench Guiana
GGGuernsey
GHGhana
GIGibraltar
GLGreenland
GMGambia
GPGuadeloupe
GQEquatorial Guinea
GRGreece
GTGuatemala
GYGuyana
HKHong Kong, SAR China
HNHonduras
HRCroatia
HTHaiti
HUHungary
IDIndonesia
IEIreland
ILIsrael
IMIsle of Man
INIndia
IQIraq
ITItaly
JEJersey
JMJamaica
JOJordan
JPJapan
KEKenya
KGKyrgyzstan
KHCambodia
KMComoros
KNSaint Kitts and Nevis
KRKorea (South)
KWKuwait
KYCayman Islands
KZKazakhstan
LALao PDR
LBLebanon
LCSaint Lucia
LILiechtenstein
LKSri Lanka
LSLesotho
LTLithuania
LULuxembourg
LVLatvia
LYLibya
MAMorocco
MDMoldova
MEMontenegro
MFSaint-Martin (French part)
MGMadagascar
MKMacedonia, Republic of
MMMyanmar
MNMongolia
MOMacao, SAR China
MSMontserrat
MTMalta
MUMauritius
MWMalawi
MXMexico
MYMalaysia
MZMozambique
NANamibia
NCNew Caledonia
NENiger
NFNorfolk Island
NGNigeria
NINicaragua
NLNetherlands
NONorway
NPNepal
NZNew Zealand
OMOman
PAPanama
PEPeru
PGPapua New Guinea
PHPhilippines
PKPakistan
PLPoland
PMSaint Pierre and Miquelon
PRPuerto Rico
PSPalestinian Territory
PTPortugal
PYParaguay
QAQatar
RERéunion
RORomania
RSSerbia
RURussian Federation
RWRwanda
SASaudi Arabia
SCSeychelles
SESweden
SGSingapore
SHSaint Helena
SISlovenia
SKSlovakia
SLSierra Leone
SNSenegal
SRSuriname
STSao Tome and Principe
SVEl Salvador
SZSwaziland
TCTurks and Caicos Islands
TGTogo
THThailand
TLTimor-Leste
TMTurkmenistan
TOTonga
TRTurkey
TTTrinidad and Tobago
TWTaiwan, Republic of China
TZTanzania, United Republic of
UAUkraine
UGUganda
USUnited States of America
UYUruguay
UZUzbekistan
VCSaint Vincent and Grenadines
VEVenezuela (Bolivarian Republic)
VGBritish Virgin Islands
VIVirgin Islands, US
VNViet Nam
WSSamoa
YEYemen
YTMayotte
ZASouth Africa
ZMZambia
ZWZimbabwe

Starting September 2024, to improve the security and service quality of Phone Authentication, Firebase projects must be linked to a Cloud Billing account to enable and use the SMS Service.

To help protect your project from SMS traffic pumping and API abuse, take the following steps:

Consider setting an SMS region policy
  1. View your regional SMS usage.

    Look for regions with a very high number of sent SMS and a very low number (or zero) of verified SMS. The ratio of verified/sent is your success rate. Healthy success rates are commonly in the 70-85% range since SMS is not a guaranteed delivery protocol, and some regions may experience abuse. Success rates below 50% imply many sent SMS but few successful logins, which is a common indicator of bad actors and SMS traffic pumping.

  2. Use SMS Region Policy to either deny SMS regions with low success rates, or only allow certain regions if your app is only intended for distribution in certain markets.

Limit your authorized authentication domains

Use the Authentication settings dashboard to manage authorized domains. The localhost domain is added by default to the approved authentication domains to simplify development. Consider removing localhost from the authorized domains in your production project to prevent bad actors from running code on their localhost to access your production project.

Enable and enforce App Check

Enable App Check to help protect your project from API abuse by attesting that requests only come from applications associated with your project.

To use App Check with Firebase Authentication, you must upgrade to Firebase Authentication with Identity Platform.

Remember that you need to enforce App Check for Authentication in the Firebase console (consider monitoring traffic before enforcing). Also, double check your reCAPTCHA Enterprise approved sites list to validate that it only contains your production sites, and that the list of applications registered to your project in App Check is accurate.

Note that App Check helps protect against automated attacks by asserting that the call comes from one of your registered applications. It does not prevent users from using your app in unintended ways (for example, starting then never finishing login flows to generate sent SMS).

At this time, numbers ported between carriers will result in all SMS becoming undeliverable for those end users. There is no workaround, and Firebase is working on this issue.

Follow the troubleshooting steps in this FAQ if you're getting the following error:

GoogleFragment: Google sign in failed
    com.google.android.gms.common.api.ApiException: 13: Unable to get token.
        at
com.google.android.gms.internal.auth-api.zbay.getSignInCredentialFromIntent(com.google.android.gms:play-services-auth@@20.3.0:6)
  1. Make sure that Google sign-in is properly enabled as an authentication provider:

    1. In the Firebase console, open the Authentication section.

    2. Within the Sign in method tab, disable and then re-enable the Google sign-in method (even if it's already enabled):

      1. Open the Google sign-in method, disable it, and then click Save.

      2. Re-open the Google sign-in method, enable it, and then click Save.

  2. Make sure that your app is using its up-to-date Firebase configuration file (google-services.json).
    Obtain your app's config file.

  3. Check if you're still getting the error. If you are, continue to the next troubleshooting step.

  4. Make sure the required underlying OAuth 2.0 clients are present.

    1. In the Credentials page of the Google Cloud console, look in the OAuth 2.0 Client IDs section.

    2. If OAuth 2.0 clients are not present (and you've done all the troubleshooting steps above), then contact Support.

Follow the troubleshooting steps in this FAQ if you're getting the following error:

You must specify |clientID| in |GIDConfiguration|
  1. Make sure that Google sign-in is properly enabled as an authentication provider:

    1. In the Firebase console, open the Authentication section.

    2. Within the Sign in method tab, disable and then re-enable the Google sign-in method (even if it's already enabled):

      1. Open the Google sign-in method, disable it, and then click Save.

      2. Re-open the Google sign-in method, enable it, and then click Save.

  2. Make sure that your app is using its up-to-date Firebase configuration file (GoogleService-Info.plist).
    Obtain your app's config file.

  3. Check if you're still getting the error. If you are, continue to the next troubleshooting step.

  4. Make sure the required underlying OAuth 2.0 clients are present.

    1. In the Credentials page of the Google Cloud console, look in the OAuth 2.0 Client IDs section.

    2. If OAuth 2.0 clients are not present (and you've done all the troubleshooting steps above), then contact Support.

Follow the troubleshooting steps in this FAQ if you're getting the following error:

AuthErrorCode.INVALID_OAUTH_CLIENT_ID
  1. Make sure that Google sign-in is properly enabled as an authentication provider:

    1. In the Firebase console, open the Authentication section.

    2. Within the Sign in method tab, disable and then re-enable the Google sign-in method (even if it's already enabled):

      1. Open the Google sign-in method, disable it, and then click Save.

      2. Re-open the Google sign-in method, enable it, and then click Save.

  2. Also, in the Google sign-in provider configuration of the Authentication section, make sure that the OAuth client ID and secret match the web client displayed in the Credentials page of the Google Cloud console (look in the OAuth 2.0 Client IDs section).

Follow the troubleshooting steps in this FAQ if you're getting the following error:

This domain YOUR_REDIRECT_DOMAIN is not authorized to run this operation.

This error is most likely caused because your redirect domain isn't listed as a authorized domain for Firebase Authentication, or the API key that you use with the Firebase Authentication Service is invalid.

First make sure that YOUR_REDIRECT_DOMAIN is in the list of authorized domains for your Firebase project. If your redirect domain is already listed there, continue to troubleshoot an invalid API key.

By default, Firebase Authentication JS SDK relies on the API key for your Firebase project that's labeled as the Browser key, and it uses this key to verify that a sign-in redirect URL is valid according to the list of authorized domains. Authentication gets this API key depending on how you access the Authentication SDK:

  • If you use Hosting-provided Auth helpers to log users in with the Authentication JS SDK, then Firebase automatically obtains your API key with the rest of your Firebase configuration each time you deploy to Firebase Hosting. Make sure that the authDomain in your web app firebaseConfig is properly configured to use one of the domains for that Hosting site. You can verify this by going to https://authDomain__/firebase/init.json, and checking that the projectId matches that from your firebaseConfig.

  • If you self-host the sign-in code, then you can use a __/firebase/init.json file to provide the Firebase configuration to the self-hosted Authentication JS SDK Redirect helper. The API key and the projectId listed in this config file should match your web app firebaseConfig.

Check to make sure this API key hasn't been deleted: Go to the APIs & Services > Credentials panel in the Google Cloud console where all the API keys for your project are listed.

  • If the Browser key has not been deleted, check the following:

    • Make sure the Firebase Authentication API is in the list of allowed APIs for the key to access (learn more about API restrictions for API keys).

    • If you self-host the sign-in code, make sure the API key listed in your __/firebase/init.json file matches the API key in the Cloud console. Correct the key in the file, if necessary, then redeploy your app.

    • If the Browser key has been deleted, you can have Firebase generate a new API key for you: In the Firebase console, go to > Project settings, then in the Your apps section, click on your web app. This action automatically creates an API key that you can see in the SDK setup and configuration section for your web app.

    Note that in the Cloud console this new API key will not be called Browser key; instead, it will be the same name as your Firebase Web App's nickname. If you decide to add API restrictions to this new API key, make sure the Firebase Authentication API is in the list of allowed APIs.

    Once your new API key is created, complete the applicable steps below:

    • If you use reserved Hosting URLs, then redeploy your app to Firebase so that it can automatically obtain the new API key with the rest of your Firebase configuration.

    • If you self-host the sign-in code, copy the new API key and add it to your __/firebase/init.json file, then redeploy your app.

  1. Open the Credentials page of the Google Cloud console.

  2. At the top of the page, select Create credentials > OAuth client ID.

  3. If you're prompted to configure your consent screen, follow the on-screen instructions, and then continue with the following steps of this FAQ.

  4. Create the OAuth web client:

    1. For the Application Type, select Web application.

    2. For the Authorized JavaScript Origins, add the following:

      • http://localhost
      • http://localhost:5000
      • https://PROJECT_ID.firebaseapp.com
      • https://PROJECT_ID.web.app
    3. For the Authorized Redirect URIs, add the following:

      • https://PROJECT_ID.firebaseapp.com/__/auth/handler
      • https://PROJECT_ID.web.app/__/auth/handler
    4. Save the OAuth client.

  5. Copy the new OAuth client ID and client secret to your clipboard.

  6. In the Firebase console, open the Authentication section.

  7. Within the Sign in method tab, open the Google sign-in provider, and then paste the web server client ID and secret you just constructed and copied from the Google Cloud console. Click Save.

Before December 2022, the %APP_NAME% in the email template was populated with the OAuth brand name that was automatically provisioned whenever an Android app was registered in the Firebase project. Now, since the OAuth brand is provisioned only when Google sign-in is enabled, the following describes how %APP_NAME% is determined:

  • If the OAuth brand name is available, then the %APP_NAME% in the email template will be the OAuth brand name (same as pre-December 2022 behavior).

  • If the OAuth brand name is not available, here's how the %APP_NAME% in the email template is determined:

    • For web apps, the %APP_NAME% will be the default Firebase Hosting site name (the value preceding .firebaseapp.com and .web.app and usually the Firebase project ID).

    • For mobile apps:

      • If the Android package name or iOS bundle ID is present in the request, then the %APP_NAME% will be the app name used in the Play Store or App Store (respectively).

      • Otherwise, the %APP_NAME% will be the default Firebase Hosting site name (the value preceding .firebaseapp.com and .web.app and usually the Firebase project ID).

    Note that if the lookup of the default Firebase Hosting site name fails, then the final fallback is to use the Firebase project ID as the %APP_NAME%.



Cloud Functions

Cloud Functions runtime support

  1. Make sure you're on the Blaze pricing plan.
  2. Make sure you are using the latest version of the Firebase CLI.
  3. Update the engines field in your functions' package.json.
  4. Optionally, test your changes using the Firebase Local Emulator Suite.
  5. Redeploy all functions.

In the Firebase console, go to the functions dashboard, select a function, and check the function's language under Additional details.

Yes. Since extensions use Cloud Functions, the runtime of your extensions will need to be updated on the same timeline as Cloud Functions.

We recommend that you periodically update to the latest version of each extension installed in your project. You can upgrade your projects' extensions via the Firebase console or Firebase CLI.

Cloud Functions pricing

Cloud Functions for Firebase relies on some paid Google services. New function deployments with Firebase CLI 11.2.0 and higher rely on Cloud Build and Artifact Registry. Deployments to older versions use Cloud Build in the same way, but rely on Container Registry and Cloud Storage for storage instead of Artifact Registry. Usage of these services will be billed in addition to existing pricing.

Storage space for Firebase CLI 11.2.0 and newer versions

Artifact Registry provides the containers in which functions run. Artifact Registry provides the first 500MB at no cost, so your first function deployments may not incur any fees. Above that threshold, each additional GB of storage is billed at $0.10 per month.

Storage space for Firebase CLI 11.1.x and prior versions

For functions deployed to older versions, Container Registry, provides the containers in which functions run. You'll be billed for each container required to deploy a function. You may notice small charges for each container stored—for example, 1GB of storage is billed at $0.026 per month.

To understand more about how your bill might change, please review the following

Yes. On the Blaze plan, Cloud Functions provides a no-cost tier for invocations, compute time, and internet traffic. The first 2,000,000 invocations, 400,000 GB-sec, 200,000 CPU-sec, and 5 GB of Internet egress traffic is provided at no cost each month. You'll be charged only for usage above those thresholds.

After the first 500MB of no-cost storage, each deployment operation will incur small-scale charges for the storage space used for the function's container. If your development process depends on deploying functions for testing, you can further minimize costs by using the Firebase Local Emulator Suite during development.

See Firebase Pricing plans and the Cloud Functions Pricing example scenarios.

No. There are no plans to change the quotas except for the removal of a maximum build time limit; instead of receiving errors or warnings when the daily build quota of 120 minutes is reached, you'll be billed under the terms of the Blaze pricing plan. See Quotas and limits.

Yes, you can create a Cloud Billing account in the Google Cloud console to get the $300 credit, then link that Cloud Billing account to a Firebase project.

More about the Google Cloud credit here.

Note that if you do this, you have to then set up the Blaze pricing plan in the Firebase console in order for your project to continue working after the $300 credit is exhausted.

No, sorry. You can use the Firebase emulator for development without having a Cloud Billing account. Alternatively, try applying for a Google Cloud free trial. If you're still having trouble paying your bill because of this change, contact Firebase Support.

You can set up budget alerts in the Google Cloud console to help control costs. Also, you can set limits on the number of billed instances created for each of your functions. To get an idea of costing for typical scenarios, see the Cloud Functions Pricing examples.

View the Usage and billing dashboard in the Firebase console.

Yes. Since extensions use Cloud Functions, extensions will be subject to the same charges as other functions.

To use extensions, you will need to upgrade to the Blaze pricing plan. You will be charged a small amount (typically around $0.01 per month for the Firebase resources required by each extension you install (even if they are not used), in addition to any charges associated with your use of Firebase services.



Cloud Messaging

Firebase Cloud Messaging provides a complete set of messaging capabilities through its client SDKs and HTTP and XMPP server protocols. For deployments with more complex messaging requirements, FCM is the right choice.

The Notifications composer is a lightweight, serverless messaging solution built on Firebase Cloud Messaging. With a user-friendly graphical console and reduced coding requirements, the Notifications composer lets users easily send messages to reengage and retain users, foster app growth, and support marketing campaigns.

Capabilities Notifications composer Cloud Messaging
Target Single device
Clients subscribed to topics (i. e. weather)
Clients in predefined user segment (app, version, language)
Clients in specified analytics audiences
Clients in device groups
Upstream from client to server
Message Type      Notifications up to 2kb
Data messages up to 4kb
Delivery Immediate
Future client device local time
Analytics Built-in Notifications analytics collection and funnel analytics

No. Firebase Cloud Messaging switched to the HTTP/2-based APNs protocol in 2017. If you are using FCM to send notifications to iOS devices, there should be no action required on your part.

You can use Firebase Cloud Messaging as a standalone component, in the same manner as you did with GCM, without using other Firebase services.

FCM is the new version of GCM under the Firebase brand. It inherits GCM’s core infrastructure, with new SDKs to make Cloud Messaging development easier.

Benefits of upgrading to FCM SDK include:

  • Simpler client development. You no longer have to write your own registration or subscription retry logic.
  • An out-of-the-box notification solution. You can use the Notifications composer, a serverless notifications solution with a web console that lets anyone send notifications to target specific audiences based on insights from Google Analytics.

To upgrade from GCM SDKs to FCM SDKs, see the guides for migrating Android and iOS apps.

When it looks like devices haven't successfully received messages, check first for these two potential causes:

Foreground message handling for notification messages. Client apps need to add message handling logic to handle notification messages when the app is in the foreground on the device. See the details for iOS and Android.

Network firewall restrictions. If your organization has a firewall that restricts the traffic to or from the Internet, you need to configure it to allow connectivity with FCM in order for your Firebase Cloud Messaging client apps to receive messages. The ports to open are:

  • 5228
  • 5229
  • 5230

FCM usually uses 5228, but it sometimes uses 5229 and 5230. FCM does not provide specific IPs, so you should allow your firewall to accept outgoing connections to all IP addresses contained in the IP blocks listed in Google's ASN of 15169.

When your app is in the background, notification messages are displayed in the system tray, and onMessageReceived is not called. For notification messages with a data payload, the notification message is displayed in the system tray, and the data that was included with the notification message can be retrieved from the intent launched when the user taps on the notification.

For more information, see Receive and handle messages.

The Notifications composer is a lightweight, serverless messaging solution built on Firebase Cloud Messaging. With a user-friendly graphical console and reduced coding requirements, the Notifications composer lets users easily send messages to reengage and retain users, foster app growth, and support marketing campaigns.

Firebase Cloud Messaging provides a complete set of messaging capabilities through its client SDKs and HTTP and XMPP server protocols. For deployments with more complex messaging requirements, FCM is the right choice.

Here's a comparison of the messaging capabilities provided by Firebase Cloud Messaging and the Notifications composer:

Capabilities Notifications composer Cloud Messaging
Target Single device
Clients subscribed to topics (i. e. weather)
Clients in predefined user segment (app, version, language)
Clients in specified analytics audiences
Clients in device groups
Upstream from client to server
Message Type      Notifications up to 2kb
Data messages up to 4kb
Delivery Immediate
Future client device local time
Analytics Built-in Notifications analytics collection and funnel analytics

The Notifications composer is an out-of-the-box solution that lets anyone send notifications to target specific audiences based on insights from Google Analytics. Also, the Notifications composer provides funnel analysis for every message, allowing easy evaluation of notification effectiveness.

If you are an existing GCM developer, to use the Notifications composer you have to upgrade from GCM SDKs to FCM SDKs. See the guides for migrating Android and iOS apps.

FCM features deprecated in June 2023

The following APIs/SDKs will be affected by the deprecation:

Server APIs

API Name API Endpoint Impact on users Action Required
Legacy HTTP protocol https://fcm.googleapis.com/fcm/send Requests to the endpoint will start failing after 6/21/2024. Migrate to the HTTP v1 API.
Legacy XMPP protocol fcm-xmpp.googleapis.com:5235 Requests to the endpoint will start failing after 6/21/2024. Migrate to the HTTP v1 API.
Instance ID server APIs https://iid.googleapis.com/v1/web/iid Requests to the endpoint will start failing after 6/21/2024. Use the Web JS SDK to create FCM web registrations.
https://iid.googleapis.com/iid/* The endpoints will continue to work but they won’t support authentication using static server keys after 6/21/2024. Use an OAuth 2.0 access token derived from a service account.
Device group management API https://fcm.googleapis.com/fcm/notification The endpoint will continue to work but it won’t support authentication using static server keys after 6/21/2024. Use an OAuth 2.0 access token derived from a service account.
Upstream messaging via XMPP fcm-xmpp.googleapis.com:5235 API calls to FirebaseMessaging.send in the app won’t trigger upstream messages to the app server after 6/21/2024. Implement this functionality in your server logic. For example, some developers implement their own HTTP/gRPC endpoint and call the endpoint directly to send messages from their clients to the app server. See this gRPC Quick start for an example implementation of upstream messaging using gRPC.
Batch Send API https://fcm.googleapis.com/batch Requests to the endpoint will start failing after 6/21/2024. Migrate to the standard HTTP v1 API send method, which supports HTTP/2 for multiplexing.

Firebase Admin SDK APIs

API Name API Language Impact on users Action Required
sendToDevice() Node.js The API will stop working after 6/21/2024 because it calls the legacy HTTP send API. Use the send() method.
sendToDeviceGroup() Node.js The API will stop working after 6/21/2024 because it calls the legacy HTTP send API. Use the send() method.
sendToTopic() Node.js The API will stop working after 6/21/2024 because it calls the legacy HTTP send API. Use the send() method.
sendToCondition() Node.js The API will stop working after 6/21/2024 because it calls the legacy HTTP send API. Use the send() method.
sendAll()/sendAllAsync()/send_all()/sendMulticast()/SendMulticastAsync()/send_multicast() Node.js, Java, Python, Go, C# These APIs will stop working after 6/21/2024 because they call the batch send API . Upgrade to the latest Firebase Admin SDK and use the new APIs instead: sendEach()/ sendEachAsync()/send_each()/sendEachForMulticast()/sendEachForMulticastAsync()/ send_each_for_multicast().

Note that the new APIs no longer call the deprecated batch send API, and for this reason they may create more concurrent HTTP connections than the old APIs.

Client SDKs

SDK versions Impact on users Action Required
GCM SDKs (deprecated in 2018) Apps using GCM SDKs will not be able to register tokens nor receive messages from FCM after 6/21/2024. Upgrade your Android SDK to the latest Firebase SDK if you haven’t already done so.
JS SDKs version <7.0.0 (breaking change at version 7.0.0 in 2019) Web apps using older JS SDKs will not be able to register tokens after 6/21/2024. Upgrade your Firebase Web SDK to the latest version.

No. You have 12 months (06/20/2023 - 06/21/2024) to migrate from the old APIs to new APIs without any service downgrade. We strongly recommend you to plan the migration as early as possible so you won’t be impacted by the decommissioning of the APIs in June 2024.

After June 2024, you may see increased errors or lack of functionality when using the APIs/SDKs listed above (see the next FAQ for more information).

FCM will start a gradual shutdown of deprecated APIs around July 22nd, 2024. After this date, deprecated services will be subject to a "flickering" process in which increasing numbers of requests will return error responses. During the gradual ramp-down period you can expect the following behavior and error responses to increase in frequency over time:

Category What to expect
Legacy HTTP protocol Requests being rejected with HTTP code 301.
Legacy XMPP protocol Requests being rejected with error code 302.
FCM Upstream Messages being silently dropped by FCM backend.
Batch Send API Requests being rejected with error code UNIMPLEMENTED and the error message "The API is deprecated."
GCM SDKs - Register Tokens Requests being rejected with HTTP code 301.
GCM SDKs - Send Messages Requests being rejected with error code 400 and the error message "V3 token has been deprecated."
JS SDKs version < 7.0.0 Requests being rejected with HTTP code 501.
Using server key to access Instance ID and device group management APIs Requests being rejected with HTTP code 401.

An OAuth 2.0 token is a short-lived token derived from a service account. It’s Google’s standard auth model and it’s more secure than static server keys.

See Use credentials to mint access tokens for guidance on using the Google Auth Library to obtain tokens.

Note that the request headers differ when you use OAuth 2.0 tokens for requests to different endpoints.

  • HTTP v1 API: Authorization: Bearer $oauth_token
  • Instance ID server API and Device group management API: Authorization: Bearer $oauth_token
    access_token_auth: true

We recommend that you slowly ramp up your traffic to the new API. If you expect to send more than 600,000 messages/min on a regular basis, contact Firebase support for instructions on how to increase quota or get recommendations on how to spread out traffic.

Topics: you don’t need to add the "/topics/" prefix to your topic target when you use the v1 API.

Device groups: You can use a group token as a token target in the HTTP v1 API. However, the HTTP v1 API doesn’t return the success/failure counts in the response. We recommend that you use FCM topics or manage your device groups by yourself.

No. This feature, called "multicast" in legacy HTTP APIs, is not supported by the HTTP v1 API, which is better designed for scalability.

For use cases where end-to-end latency is critical, or where total fanout size is small (fewer than 1 million), Google recommends sending multiple separate requests using the HTTP v1 API. The HTTP v1 API over HTTP/2 performs similarly for 99.9% of multicast requests (sending < 100 tokens). For outlier use cases (sending 1000 tokens), it achieves up to a third of the throughput rate, so additional concurrency is needed to optimize for this atypical use case. Users can experience more reliability and availability with the HTTP v1 API than with legacy multicast.

For use cases where throughput and egress bandwidth are prioritized or where total fanout size is large (greater than 1 million), Google recommends topic messaging. While topic messaging requires a one-time action to subscribe recipients to a topic, it offers up to a 10,000 QPS per project fanout rate without a maximum limit on topic size.

Platform Firebase Admin SDK version
Node.js >=11.7.0
Python >=6.2.0
Java >=9.2.0
Go >=4.12.0
.NET >=2.4.0

The FCM batch send API uses the same message format and authentication mechanism as the HTTP v1 API. However, it uses a different endpoint. If you want to improve efficiency, you should consider using HTTP/2 to send multiple requests over the same HTTP connection to the HTTP v1 API.

Please reach out to the Google Cloud support team for help.

No. Starting from 5/20/2024, new projects will no longer be allowed to enable our legacy APIs.

Once you are sure that you have fully migrated to the HTTP v1 API, you can disable the legacy Cloud Messaging API (the page may fail to load if the API has already been disabled).

FCM quotas and limits

Unfortunately, this use case cannot be supported. You must spread your traffic out over 5 minutes.

Unfortunately, we cannot grant quota increases for this reason. You must spread your traffic out over 5 minutes.

We recommend that you start sending the notifications at least 5 minutes prior to the event.

This depends a bit on your use of FCM. In any case, you can expect an answer in a few business days. In some cases, there may be some back-and-forth regarding your usage of FCM and various circumstances, which can prolong the process. If all requirements are met, most requests will be handled within 2 weeks.

See Google Cloud guidance on how to chart and monitor quota metrics.

While we understand that quota limits can be challenging, quotas are vital to keeping the service reliable and we can't grant exemptions.

You may request additional quota to support an event lasting up to 1 month. File the request at least 1 month in advance of the event and with clear details on when the event starts and ends, and FCM will make every practical effort to fulfill the request (no increase can be guaranteed). These quota increases will be reverted after the event's end date.

While Google will not do so lightly, quotas may be changed as needed to protect the integrity of the system. When possible, Google will notify you in advance of such changes.



Cloud Storage for Firebase

Go to the Cloud Storage documentation to learn more about the Changes for the default Cloud Storage bucket.

Cloud Storage for Firebase creates a default bucket in the App Engine no-cost tier. This allows you to quickly get up and running with Firebase and Cloud Storage for Firebase, without having to put in a credit card or enable a Cloud Billing account. It also allows you to easily share data between Firebase and a Google Cloud project.

There are, however, two known cases where this bucket cannot be created and you will be unable to use Cloud Storage for Firebase:

  • A project imported from Google Cloud which had a App Engine Master/Slave Datastore application.
  • A project imported from Google Cloud which has domain prefixed projects. For example: domain.com:project-1234.

There are currently no workarounds to these issues, and we recommend that you create a new project in the Firebase console and enable Cloud Storage for Firebase in that project.

It's likely you're getting 412 error codes either because the Cloud Storage for Firebase API is not enabled for your project or a necessary service account is missing the required permissions.

See the related FAQ.

For no-cost (Spark) plan projects, Firebase blocks uploads and hosting of certain executable file types for Windows, Android and Apple by Cloud Storage for Firebase and Firebase Hosting. This policy exists to prevent abuse on our platform.

Serving, hosting and file uploads of disallowed files are blocked for all Spark projects created on or after Sept 28th, 2023. For existing Spark projects with files uploaded before that date, such files can still be uploaded and hosted.

This restriction applies to Spark plan projects. Projects on the pay as you go (Blaze) plan are not affected.

The following file types cannot be hosted on Firebase Hosting and Cloud Storage for Firebase:

  • Windows files with .exe, .dll and .bat extensions
  • Android files with .apk extension
  • Apple platform files with .ipa extension

What do I need to do?

If you still want to host these file types after September 28th, 2023:

  • For Hosting: upgrade to the Blaze plan before you can deploy these file types to Firebase Hosting via the firebase deploy command.
  • For Storage: upgrade to the Blaze plan to upload these file types to the bucket of your choice using the GCS CLI, the Firebase console, or Google Cloud console.

Use Firebase tools to manage your Firebase Hosting and Cloud Storage resources.

  • For managing resources in Firebase Hosting, use the Firebase console to delete releases according to this guide.
  • For managing resources in Cloud Storage, navigate to the Storage product page in your project.
    1. On the Files tab, locate disallowed files to delete in your folder hierarchy, then select them using the checkbox next to the filename(s) on the left-hand side of the panel.
    2. Click Delete, and confirm the files were deleted.

Please refer to our documentation for additional information on managing Hosting resources with Firebase tools and Cloud Storage for Firebase buckets with client libraries.

Previously, download and upload requests to the Cloud Storage for Firebase API were not being counted properly. We have taken steps to fix this issue, starting from September 15, 2023.

For Blaze users, upload and download operations will start counting towards your monthly bill. For Spark users, they will start counting towards your monthly free limit.

We recommend monitoring your Usage page for any increases that may count towards your limits.

Firebase uses service accounts to operate and manage services without sharing user credentials. When you create a Firebase project, you might notice that a number of service accounts are already available in your project.

The service account that Cloud Storage for Firebase uses is scoped to your project and is named
service-PROJECT_NUMBER@gcp-sa-firebasestorage.iam.gserviceaccount.com.

If you used Cloud Storage for Firebase before September 19, 2022, you may see an additional service account on previously-linked Cloud Storage buckets named firebase-storage@system.gserviceaccount.com. As of September 19, 2022, this service account is no longer supported.

You can view all service accounts associated with your project in the Firebase console, on the Service accounts tab.

Adding the new service account

If you removed the service account previously or the service account is not present in your project, you may do one of the following to add the account.

  • (Recommended) Automated: Use the AddFirebase REST endpoint to re-import your bucket into Firebase. You will only need to call this endpoint once, not once for each linked bucket.
  • Manual: Follow the steps in Creating and managing service accounts. Following that guide, add a service account with the IAM roleCloud Storage for Firebase Service Agent, and service account name
    service-PROJECT_NUMBER@gcp-sa-firebasestorage.iam.gserviceaccount.com.
Removing the new service account

We strongly discourage you from removing the service account because this may block access to your Cloud Storage buckets from your apps. To remove the service account from your project, follow the instructions in Disabling a service account.

Cloud Storage for Firebase pricing

Go to the Cloud Storage documentation to learn more about the Changes for pricing plan requirements for Cloud Storage.

Visit the Firebase Pricing page and use the Blaze plan calculator. The calculator lists all the usage types for Cloud Storage for Firebase.

Use the sliders to input the expected usage of your Storage bucket. The calculator will estimate your monthly bill.

When you exceed limits for Cloud Storage in a project on the Spark plan, the result depends on the type of limit that you exceed:

  • If you exceed the GB stored limit, you will not be able to store any more data in that project unless you remove some of the data stored or upgrade to a plan that provides more storage space, or unlimited storage space.
  • If you exceed the GB downloaded limit, your app will not be able to download more data until the next day (starting at midnight, US Pacific Time), unless you upgrade to a plan with less restrictive limits, or with no limits.
  • If you exceed the upload or download operations limit, your app will not be able to upload or download more data until the next day (starting at midnight, US Pacific Time), unless you upgrade to a plan with less restrictive limits, or with no limits.



Crashlytics

Visit the Crashlytics troubleshooting & FAQ page for helpful tips and answers to more FAQs.



See Dynamic Links FAQ.

The getInvitation API clears the saved Dynamic Link to prevent it from being accessed twice. Be sure to call this API with the autoLaunchDeepLink parameter set to false in each of the deep link activities to clear it for the case when the activity is triggered outside the main activity.



Hosting

For no-cost (Spark) plan projects, Firebase blocks uploads and hosting of certain executable file types for Windows, Android and Apple by Cloud Storage for Firebase and Firebase Hosting. This policy exists to prevent abuse on our platform.

Serving, hosting and file uploads of disallowed files are blocked for all Spark projects created on or after Sept 28th, 2023. For existing Spark projects with files uploaded before that date, such files can still be uploaded and hosted.

This restriction applies to Spark plan projects. Projects on the pay as you go (Blaze) plan are not affected.

The following file types cannot be hosted on Firebase Hosting and Cloud Storage for Firebase:

  • Windows files with .exe, .dll and .bat extensions
  • Android files with .apk extension
  • Apple platform files with .ipa extension

What do I need to do?

If you still want to host these file types after September 28th, 2023:

  • For Hosting: upgrade to the Blaze plan before you can deploy these file types to Firebase Hosting via the firebase deploy command.
  • For Storage: upgrade to the Blaze plan to upload these file types to the bucket of your choice using the GCS CLI, the Firebase console, or Google Cloud console.

Use Firebase tools to manage your Firebase Hosting and Cloud Storage resources.

  • For managing resources in Firebase Hosting, use the Firebase console to delete releases according to this guide.
  • For managing resources in Cloud Storage, navigate to the Storage product page in your project.
    1. On the Files tab, locate disallowed files to delete in your folder hierarchy, then select them using the checkbox next to the filename(s) on the left-hand side of the panel.
    2. Click Delete, and confirm the files were deleted.

Please refer to our documentation for additional information on managing Hosting resources with Firebase tools and Cloud Storage for Firebase buckets with client libraries.

Firebase automatically adds extra files containing metadata about the Hosting site, and these files are included in the total file count for the release.

Hosting has a maximum size limit of 2 GB for individual files.

We recommend storing larger files using Cloud Storage, which offers a maximum size limit in the terabyte range for individual objects.

The Firebase Hosting multisite feature supports a maximum of 36 sites per project.



Performance Monitoring

Visit the Performance Monitoring troubleshooting & FAQ page for helpful tips and answers to more FAQs.

You can create up to 400 total custom URL patterns per app and up to 100 custom URL patterns per domain for that app.

To view real time performance data, make sure that your app uses a Performance Monitoring SDK version that's compatible with real time data processing.

  • iOS — v7.3.0 or later
  • tvOS — v8.9.0 or later
  • Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
  • Web — v7.14.0 or later

Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.



Realtime Database

A simultaneous connection is equivalent to one mobile device, browser tab, or server app connected to the database. Firebase imposes hard limits on the number of simultaneous connections to your app's database. These limits are in place to protect both Firebase and our users from abuse.

The Spark plan limit is 100 and cannot be raised. The Flame and Blaze plans have a limit of 200,000 simultaneous connections per database.

This limit isn't the same as the total number of users of your app, because your users don't all connect at once. If you need more than 200,000 simultaneous connections, please read Scale with Multiple Databases.

Each Realtime Database instance has limits on the number of write operations per second. For small writes, this limit is approximately 1000 write operations per second. If you are approaching this limit, batching operations using multi-path updates can help you achieve higher throughput.

In addition, each database instance has a cap on the number of simultaneous database connections. Our default limits are large enough for most applications. If you are building an app that requires additional scale, you may need to shard your application across multiple database instances for added scale. You may also consider Cloud Firestore as an alternative database.

If you've received an email alert or notification in the Firebase console that you've exceeded your Realtime Database usage limits, you can address it based on the usage limit you've exceeded. To see your Realtime Database usage, go to the Realtime Database Usage dashboard in the Firebase console.

If you're over your download limit, you can upgrade your Firebase pricing plan or wait until your download limit resets at the start of your next billing cycle. To decrease your downloads, try the following steps:

  • Add queries to limit the data that your listen operations return.
  • Check for unindexed queries.
  • Use listeners that only download updates to data — for example, on() instead of once().
  • Use security rules to block unauthorized downloads.

If you're over your storage limit, upgrade your pricing plan to avoid service disruptions. To reduce the amount of data in your database, try the following steps:

  • Run periodic cleanup jobs.
  • Reduce any duplicate data in your database.

Note that it may take some time to see any data deletions reflected in your storage allotment.

If you're over your simultaneous database connections limit, upgrade your plan to avoid any service disruptions. To manage simultaneous connections to your database, try connecting via users via the REST API if they don't require a realtime connection.

To provide you with a predictable price, the resources available to you in the Spark plans are capped. This means that when you exceed any plan limit in any month, your app will be turned off to prevent any further resource usage and additional charges.

When your app reaches its concurrency limit on the Spark plan, any subsequent connections will be rejected until some of the existing connections are closed. The app will continue to work for users who are connected.

Automated backups are an advanced feature for customers on our Blaze pricing plan that backs up your Firebase Realtime Database data once a day and uploads it to Google Cloud Storage.

We do not offer hourly backups.

For our bandwidth calculations, we normally include SSL encryption overhead (based on layer 5 of the OSI model). However, in September 2016, we introduced a bug that caused our bandwidth reporting to ignore encryption overhead. This might have resulted in artificially low reported bandwidth and bills on your account for a few months.

We released a fix for the bug in late March 2017, returning bandwidth reporting and billing to their normal levels.



Remote Config

Unless you fetch values with fetchAndActivate(), values are stored locally but not activated. To activate fetched values so that they can take effect, call activate. This design lets you control when the behavior and appearance of your app changes, because you can choose when to call activate. After you call activate, your app source code determines when updated parameter values are used.

For example, you could fetch values and then activate them the next time a user starts your app, which removes the need to delay app startup while your app waits for fetched values from the service. Changes to your app's behavior and appearance then occur when your app uses the updated parameter values.

To learn more about the Remote Config API and usage model, see Remote Config API Overview.

During app development, you might want to fetch and activate configs very frequently (many times per hour) to let you rapidly iterate as you develop and test your app. To accommodate rapid iteration on a project with up to 10 developers, you can temporarily set a FirebaseRemoteConfigSettings object with a low minimum fetch interval (setMinimumFetchIntervalInSeconds) in your app.

Devices usually receive fetched values in less than a second, and often receive fetched values in milliseconds. The Remote Config service handles fetch requests within milliseconds, but the time required to complete a fetch request will depend on the network speed of the device and the latency of the network connection used by the device.

If your goal is to make fetched values take effect in your app as soon as possible, but without creating a jarring user experience, consider adding calls to fetchAndActivate each time that your app does a full screen refresh.



Test Lab

Visit the Test Lab troubleshooting page for helpful tips and answers to FAQs.



Firebase User Segmentation Storage

Firebase User Segmentation Storage stores Firebase installation IDs and related attributes and segments as well as audience lists you've created to provide targeting information to other Firebase services that use them, such as Crashlytics, FCM, Remote Config personalization, and more.