# Firebase Destination Config Reference


> Complete Rudder CLI reference for the Firebase destination config keys, event filtering, and mobile device mode source types.



[Firebase](https://www.rudderstack.com/docs/destinations/streaming-destinations/firebase/) is a mobile analytics destination that runs only in device mode. RudderStack's mobile SDKs load the Firebase SDK in the app and log `identify`, `track`, and `screen` calls to Google Analytics for Firebase from there, mapping `track` events to Firebase's standard events where they match.

In a Firebase destination spec:

- `type: firebase`
- `definition_version: 1`

## Sample configuration

```yaml
version: rudder/v1
kind: destination
metadata:
  name: firebase-prod
spec:
  id: firebase-prod
  display_name: Firebase Production
  type: firebase
  definition_version: 1
  enabled: true
  config:
    event_filtering:
      blacklist:
        - Application Backgrounded
        - Debug Event

    connection_mode:
      android_kotlin: device
      ios_swift: device
    consent_management:
      android_kotlin:
        - provider: oneTrust
          consents:
            - analytics
```

The above example connects Kotlin and Swift apps. The Firebase project itself isn't configured here — the app bundles it, in the `google-services.json` or `GoogleService-Info.plist` file Firebase generates — so `event_filtering` is the only Firebase-specific key. See [Event filtering](#event-filtering).

## Config keys

`config` accepts only the keys listed below. The [shared config key rules](https://www.rudderstack.com/docs/rudder-cli/destination-types/#config-key-rules) cover unknown keys, defaults, and immutability.

**Info:** Firebase runs only in `device` mode. The mobile SDKs send it `identify`, `track`, and `screen` calls from the app, so every key below configures what the SDK does in the app.

### Event filtering

Every source connects to Firebase in `device` mode, where the SDK applies the filter, so [client-side event filtering](https://www.rudderstack.com/docs/sources/event-streams/sdks/event-filtering/) applies to `track` events from every source.

<div class="rs-ckeys">
<div class="rs-ckey" id="event_filtering">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">event_filtering</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Restricts which <code>track</code> events the SDK passes to Firebase, by event name.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li><code>whitelist</code> — array of event names to allow; every other <code>track</code> event is dropped.</li>
<li><code>blacklist</code> — array of event names to drop; every other <code>track</code> event is allowed.</li>
<li>The two are mutually exclusive, and Rudder CLI enforces it — setting both fails validation.</li>
<li>Each name is at most 100 characters, or a <code>{{ path || fallback }}</code> template.</li>
<li>Omit the block entirely to filter nothing.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">event_filtering:
  whitelist:
    - Order Completed
    - Product Added</code></pre></div>
</div>
</div>

</div>

</div>

### Per-source keys

Both keys are objects keyed by the local source type — the tokens listed under [Source types](#source-types). A key naming a source type this destination doesn't support fails validation.

<div class="rs-ckeys">
<div class="rs-ckey" id="connection_mode">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">connection_mode</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Maps each source type you connect to the mode its events reach Firebase in. Firebase accepts only <code>device</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>An entry is required for each source type you connect — see <a href="#connect-a-source" >Connect a source</a>.</li>
<li>Any other mode fails validation — for example <code>cloud</code> for <code>android</code>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">connection_mode:
  android: device
  ios: device
  react_native: device</code></pre></div>
</div>
</div>

</div>

<div class="rs-ckey" id="consent_management">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">consent_management</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Consent provider configuration per source type. The entry shape, accepted providers, and the rules on <code>resolution_strategy</code> and <code>consents</code> are shared across all destination types — see <a href="https://www.rudderstack.com/docs/rudder-cli/destination-types/#consent-management" >Consent management</a>.
</p>

</div>

</div>

## Source types

Firebase accepts events from these source types in the mentioned connection modes:

| Source type | Connection mode |
| :-----| :-----|
| `android` | `device` |
| `android_kotlin` | `device` |
| `ios` | `device` |
| `ios_swift` | `device` |
| `unity` | `device` |
| `react_native` | `device` |
| `flutter` | `device` |

Firebase accepts only mobile SDK sources, and only in `device` mode — the SDK loads Firebase in the app, and no events pass through RudderStack's servers. It doesn't accept `web`, `cordova`, or `cloud` sources. See [Add device mode integration](https://www.rudderstack.com/docs/destinations/streaming-destinations/firebase/#add-device-mode-integration).

## Connect a source

An event stream connection to this destination is checked against two rules at `validate` time.

**The source's type must be supported.** Firebase accepts the types the mobile SDK sources resolve to. A JavaScript source resolves to `web`, a Cordova source to `cordova`, and webhook and server-side SDK sources to `cloud` — none of which Firebase accepts — and reports, for example:

```text
destination 'firebase-prod' (type 'firebase') does not support source 'my-web-app':
source type 'web' is not among supported source types: android, android_kotlin, ios, ios_swift, unity, react_native, flutter
```

**The destination config must carry a `connection_mode` entry for that source type.** This lives on the destination spec, not on the [connection spec](https://www.rudderstack.com/docs/rudder-cli/yaml-connections/). Without it:

```text
destination 'firebase-prod' config has no 'connection_mode' entry for source type 'android'
```

Firebase needs no additional config keys to connect a source of any supported type.

## Secrets

Firebase has no secret keys, and no credentials in its config at all. The app authenticates to Firebase with the configuration file it bundles.

## Changes by release

<p>No changes since this type became available.</p>

For changes across every destination type, see [Destination Type Changes by Release](https://www.rudderstack.com/docs/rudder-cli/destination-types/changes/).

## See more

- [Firebase Destination](https://www.rudderstack.com/docs/destinations/streaming-destinations/firebase/) for adding the Firebase SDK to your app, and the event and property mappings
- [Destination Type Reference for Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/destination-types/) for the rules shared across destination types
- [Destination YAML Reference](https://www.rudderstack.com/docs/rudder-cli/yaml-destinations/) for the spec envelope