.png)
Firebase Integration Guide
Integrate Firebase applications and services with enterprise systems through REST APIs, Cloud Functions callbacks, Google authentication, and orchestrated Martini workflows.
Firebase integration options at a glance
Firebase exposes REST APIs for Authentication, Cloud Firestore, Realtime Database, Cloud Messaging, project management, and related Google Cloud services. Firebase Cloud Functions and application code can provide selected event callbacks or HTTP endpoints, although Firebase does not offer a universal webhook for every object change. Cloud Storage supports file and object operations, while Firestore provides batch writes and managed export and import capabilities. Server-side integrations commonly use Google service accounts, OAuth 2.0, IAM, and product-specific tokens. Martini can consume these APIs, receive callbacks, transform data, apply business rules, and coordinate Firebase with enterprise applications.
| Integration point | Supported by Firebase? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Firebase and related Google services expose REST APIs for Authentication, Firestore, Realtime Database, Cloud Messaging, management, and storage-related operations. | Martini can consume REST APIs, manage authentication headers and tokens, map responses, and orchestrate calls across Firebase and enterprise systems. |
| Webhooks / outbound callbacks | Limited | Cloud Functions, Firebase Extensions, or application code can forward selected Firebase events to HTTP endpoints. Coverage depends on the product and trigger type. | Martini can expose an API or consume webhook-style callbacks, validate the event, retrieve current resource data, and apply idempotent processing. |
| Bulk / async / batch APIs | Limited | Firestore supports batch writes, transactions, and managed export/import. Other Firebase services provide product-specific batch or asynchronous operations. | Martini workflows can partition workloads, monitor operation status, retry transient failures, and record partial results. |
| File / object APIs | Yes | Firebase Storage, backed by Google Cloud Storage, supports upload, download, listing, and object metadata operations. | Martini can retrieve or upload objects, validate metadata and generation numbers, transform files, and route them to enterprise applications or databases. |
| Database access | Yes | Firestore and Realtime Database provide programmatic document, collection, path, query, and streaming access through APIs. Firebase does not provide a general SQL connection for these databases. | Martini can consume the relevant REST APIs, handle document and JSON-path models, apply mappings, and maintain synchronization checkpoints. |
| Authentication | Yes | Depending on the product, Firebase uses API keys, Firebase ID tokens, refresh tokens, Google OAuth 2.0, service accounts, IAM, and Security Rules. | Martini can store credentials in secure configuration, attach API keys or bearer tokens, and use least-privilege service-account credentials for server-side workflows. |
| GraphQL APIs | Not confirmed | Firebase does not provide a general first-party GraphQL API. A project may expose GraphQL through custom application code or another Google Cloud service. | Martini can consume a separate GraphQL endpoint when one is supplied, but the endpoint should not be treated as a native Firebase API. |
| SOAP APIs | No | No current Firebase SOAP interface was confirmed; REST, SDK, Google Cloud APIs, and event-based mechanisms are the documented alternatives. | Martini should use Firebase REST APIs or HTTP callbacks rather than a SOAP integration for Firebase. |
How Firebase exposes data and business events
Firebase REST APIs
Firebase and related Google Cloud services expose REST APIs for Authentication, Firestore, Realtime Database, Cloud Messaging, management, and storage-related operations. These APIs are the primary integration mechanism for server-side access.
Martini implementation pattern
Martini implementation pattern: configure the required Firebase or Google Cloud endpoint and credentials, call the API from a workflow, normalize the response, apply business rules, and write the result to the target system. Store tokens and service-account configuration outside workflow payloads.
Implementation sequence
Cloud Functions callbacks
Cloud Functions can respond to selected Firebase or Google Cloud events and can expose HTTP endpoints. Firebase does not provide a universal outbound webhook covering every object change.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini API for the callback, validate the request and event identity, retrieve current Firebase data when necessary, and process the event with idempotency and retry controls.
Implementation sequence
Firestore batch and export operations
Firestore supports batch writes, transactions, and managed export and import through Google Cloud infrastructure. Operation limits and asynchronous behavior depend on the specific service operation.
Martini implementation pattern
Martini implementation pattern: divide large workloads into bounded batches, invoke the relevant API or managed operation, track operation status, and isolate failed items for replay instead of repeating successful writes.
Implementation sequence
Firebase Storage object APIs
Firebase Storage uses Google Cloud Storage object APIs for uploading, downloading, listing, and managing object metadata. Files may be referenced by Firestore or Realtime Database data.
Martini implementation pattern
Martini implementation pattern: receive an object event or identify new objects through a scheduled listing, verify the immutable generation and metadata, retrieve the object, transform it, and route the result to an enterprise destination.
Implementation sequence
Firebase Cloud Messaging API
The Firebase Cloud Messaging HTTP v1 API supports sending messages to device registration tokens, topics, and other supported message targets with Google authentication.
Martini implementation pattern
Martini implementation pattern: consume a business event or application record, determine the audience and notification template, construct the FCM request, send it through the API, and classify delivery or authorization failures.
Implementation sequence
Common Firebase integration patterns
Pattern 1: Synchronize Firebase users with Salesforce
When to use this pattern
Use this pattern when Firebase Authentication users must be represented as contacts, leads, or customer profiles in Salesforce. It supports scheduled retrieval or an application-managed event bridge and preserves the Firebase UID as the stable external identity.
Integration direction
Example Mapping
| Firebase Field | Canonical Field | Target Field |
|---|---|---|
| localId / uid | externalUserId | Firebase_User_ID__c |
| displayName | displayName | Name |
| disabled | activeStatus | Active__c |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated users through the Firebase Authentication REST API, maps provider and status information, validates email and identity rules, and performs create-or-update operations in Salesforce. The workflow stores the UID and checkpoint, skips or routes deleted and disabled users according to policy, and retries transient failures without duplicating profiles.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- scheduled execution
- error handling
Pattern 2: Synchronize Firestore documents with an enterprise application
When to use this pattern
Use this pattern when application documents represent customer, case, order, or operational data that must be synchronized with Salesforce, ServiceNow, or another enterprise platform. Near-real-time processing requires a Cloud Function or application-managed callback because Firebase has no universal webhook for every document change.
Integration direction
Example Mapping
| Firebase Field | Canonical Field | Target Field |
|---|---|---|
| document.name | sourceDocumentId | Correlation ID |
| fields.status | status | State |
| fields.createdAt | createdAt | Opened |
| fields.priority | priority | Priority |
Martini implementation pattern
A Cloud Function can call a Martini API for selected events, while a scheduled workflow provides reconciliation. Martini validates the event, retrieves the current document, maps nested Firestore fields, applies status and priority rules, and writes the target record. Document paths and event IDs provide idempotency keys, while failed messages are retried or routed for replay.
Martini capabilities used
- APIs
- webhook consumption
- workflows
- data mapping
- validation
- idempotency
- error handling
Pattern 3: Process Firebase Storage uploads
When to use this pattern
Use this pattern when users or applications upload CSV, JSON, spreadsheet, or media files to Firebase Storage and the contents must be validated or loaded into a business system or SQL database.
Integration direction
Example Mapping
| Firebase Field | Canonical Field | Target Field |
|---|---|---|
| bucket | storageBucket | source_bucket |
| name | objectPath | file_path |
| generation | objectVersion | source_generation |
| contentType | mediaType | content_type |
Martini implementation pattern
Martini receives a Cloud Function callback or finds new objects through a scheduled listing, checks the object generation and checksum, downloads the file through Cloud Storage APIs, and transforms its contents. Validation rules reject malformed rows or unsupported content types, while successful loads and failed objects are recorded for replay.
Martini capabilities used
- workflows
- API consumption
- file processing
- data mapping
- validation
- business rules
- error handling
Pattern 4: Send business notifications through Firebase Cloud Messaging
When to use this pattern
Use this pattern when enterprise events or application state changes should generate push notifications for device tokens or topics. The pattern centralizes templates, audience rules, auditing, and retry behavior.
Integration direction
Example Mapping
| Firebase Field | Canonical Field | Target Field |
|---|---|---|
| Case.Id | businessEventId | data.eventId |
| Case.Subject | messageTitle | notification.title |
| Case.Status | messageBody | notification.body |
| Contact.DeviceToken | deliveryTarget | message.token |
Martini implementation pattern
Martini receives or retrieves a business event, resolves the recipient or topic, selects a notification template, and calls the FCM HTTP v1 API using Google authentication. The workflow records the relationship between the business event and message request, applies bounded retries for transient failures, and routes invalid tokens or authorization failures for review.
Martini capabilities used
- API consumption
- workflows
- data mapping
- business rules
- OAuth 2.0
- retry handling
- monitoring
Applications commonly integrated with Firebase
Firebase commonly sits alongside application, analytics, commerce, payment, collaboration, and enterprise operations platforms. Martini can coordinate these systems using their documented APIs, callbacks, files, and authentication models rather than requiring a dedicated Firebase connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| BigQuery | Export applicable Firebase event and application data for analytics, segmentation, and reporting. | Firebase → Martini → BigQuery | Use scheduled or event-driven workflows to retrieve or receive Firebase data, normalize event structures, validate required fields, and load approved datasets or results into BigQuery using the relevant Google APIs. |
| Google Analytics for Firebase | Combine application engagement data with operational or customer information for reporting and audience analysis. | Google Analytics for Firebase → Martini → BigQuery | Orchestrate exports and downstream enrichment through API workflows, map event attributes to a canonical analytics model, and route validated data to BigQuery or other reporting processes. |
| Google Cloud Storage | Process application files, exports, backups, and media associated with Firebase applications. | Firebase Storage → Martini → Google Cloud Storage | Receive a Cloud Function callback or poll object metadata, retrieve the object through Cloud Storage APIs, validate its generation and content type, and route the file to downstream processing. |
| Salesforce | Synchronize Firebase Authentication users, application activity, or business events with customer and service processes. | Firebase → Martini → Salesforce | Read Firebase users or Firestore documents, map stable Firebase identifiers to Salesforce fields, apply create-or-update rules, and retry transient API failures without duplicating records. |
| Shopify | Connect storefront activity, customer interactions, or order-related application experiences with Firebase-backed applications. | Shopify → Martini → Firebase | Receive Shopify events or retrieve Shopify resources, transform them into Firebase document or messaging models, and write through Firebase REST APIs with checkpoint and duplicate protection. |
| Stripe | Link payment events and subscription status with Firebase users and application entitlements. | Stripe → Martini → Firebase | Receive Stripe webhook notifications, resolve the related Firebase UID or document path, apply entitlement rules, and update Firestore or Realtime Database with idempotent processing. |
| Slack | Send operational alerts, deployment notifications, and workflow exceptions to delivery and support teams. | Firebase → Martini → Slack | Route selected Firebase errors or business events through a Martini workflow, enrich the message with object and correlation identifiers, and call Slack using its configured API endpoint. |
| ServiceNow | Create incidents or service requests from application failures, security events, or operational conditions. | Firebase → Martini → ServiceNow | Translate Firebase or Cloud Function failure events into ServiceNow incident fields, enforce severity and deduplication rules, and optionally synchronize resolution status back to Firebase. |
How to build a Firebase integration in Martini
Objective
Establish secure access to the Firebase product or Google Cloud API required by the integration.
Instructions in Martini
- Identify whether the target is Authentication, Firestore, Realtime Database, Storage, Cloud Messaging, or a management API.
- Use a least-privilege service account and OAuth 2.0 where appropriate.
- Store service credentials, API keys, refresh tokens, and endpoint configuration in Martini secrets or secure environment configuration.
- Confirm the API-specific authorization model, including IAM, Security Rules, ID tokens, and project permissions.
Objective
Select a trigger that matches the required freshness and Firebase event coverage.
Instructions in Martini
- Use a scheduled workflow for reconciliation or incremental polling.
- Expose a Martini API for callbacks from a Cloud Function or application-managed event bridge.
- Use a Firebase or Google Cloud operation only when the required event is supported by the selected product.
- Define the event identifier, checkpoint, and replay behavior before processing data.
Objective
Read the current Firebase resource or event payload needed for processing.
Instructions in Martini
- Call the relevant REST API and handle page tokens, cursors, document paths, or JSON subtrees.
- Retrieve the current Firestore document or Cloud Storage object when callback payloads contain only event metadata.
- Track asynchronous operation status for exports, imports, or administrative operations.
- Preserve Firebase UIDs, document paths, object generations, message IDs, and correlation identifiers.
Objective
Coordinate Firebase calls, target-system operations, validation, and state management in a Martini workflow.
Instructions in Martini
- Separate source retrieval, transformation, business decisions, target writes, and checkpoint updates into clear workflow stages.
- Use conditional routing for disabled users, invalid files, unsupported document shapes, or non-retryable API responses.
- Use bounded concurrency for quota-sensitive Firebase operations.
- Keep source and target identifiers available for diagnostics and replay.
Objective
Transform Firebase-specific objects into a canonical model and target-system payload.
Instructions in Martini
- Map nested Firestore fields, Realtime Database JSON paths, Authentication user properties, and Storage metadata explicitly.
- Normalize timestamps, numeric types, arrays, null values, provider information, and document references.
- For files, validate content type, size, naming convention, checksum, and object generation before transformation.
- Use stable Firebase identifiers rather than mutable display names or email addresses as the primary key.
Objective
Enforce business, authorization, validation, and duplicate-processing rules before writing results.
Instructions in Martini
- Validate required fields and reject or quarantine incomplete payloads.
- Use document paths, UIDs, object generations, event IDs, or message IDs as idempotency keys.
- Classify permission, authentication, quota, validation, and transient service errors separately.
- Apply product-specific rules for disabled users, deleted resources, notification audiences, and file processing status.
Common Firebase data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Firebase projects | Top-level containers for applications, services, configuration, quotas, and project-level administration. | Google Cloud administration, deployment tooling, configuration repositories | Martini can retrieve or manage selected project information through Firebase and Google Cloud management APIs, subject to IAM permissions. |
| Firebase apps | Registered Android, Apple, or Web applications within a Firebase project. | Application inventories, deployment platforms, configuration services | Martini maps app identifiers and configuration metadata through management APIs and can coordinate provisioning or audit workflows. |
| Firebase Authentication users | User accounts, provider associations, email addresses, display names, disabled status, and Firebase UIDs. | Salesforce, identity platforms, customer databases, data warehouses | Martini retrieves users through the Auth REST API, handles pagination and disabled or deleted accounts, and uses the UID as an external identifier. |
| Firestore collections and documents | Hierarchical document data for application state, profiles, business events, and operational data. | Salesforce, ServiceNow, NetSuite, BigQuery, SQL databases | Martini consumes document APIs, maps nested fields and document paths, applies business rules, and supports callback-driven or scheduled synchronization. |
| Realtime Database instances and data paths | JSON trees accessed by path for application data and selected streaming-style reads. | Application services, operational databases, enterprise applications | Martini reads or writes JSON paths through the REST API and treats returned subtrees and path identifiers explicitly rather than as SQL rows. |
| Cloud Storage buckets and objects | Files, media, exports, backups, and object metadata stored through Firebase Storage and Google Cloud Storage. | File-processing workflows, data warehouses, document systems, SQL databases | Martini validates object names, content type, size, checksum, and generation, then downloads, transforms, uploads, or routes objects. |
Authentication and security considerations
Use product-appropriate authentication
Firebase authentication varies by service. Server-to-server workflows commonly use Google service accounts, OAuth 2.0 bearer tokens, IAM roles, and narrowly scoped permissions. Some Firebase Authentication REST operations use an API key together with user or refresh tokens.
Protect credentials and data
- Store service-account credentials, refresh tokens, API keys, and other secrets in Martini secure configuration.
- Do not treat a Firebase API key as the sole authorization control.
- Keep IAM permissions and service-account roles limited to the required projects and operations.
- Apply appropriate Firebase Security Rules for client access and distinguish them from trusted server-side authorization.
- Do not place tokens, private keys, or sensitive user attributes in workflow logs.
Operational considerations for Firebase integrations
Quotas and retries
Firebase and Google Cloud services apply product-specific quotas and request limits. Use bounded concurrency, exponential backoff, and retry classification for transient responses.
Pagination and incremental processing
Handle page tokens, cursors, document ordering, JSON paths, and service-specific operation status explicitly. Realtime Database reads are path-oriented and are not conventional SQL pagination.
Idempotency
Use Firebase UIDs, document paths, event IDs, Cloud Storage generations, message IDs, or maintained checkpoints to prevent duplicate writes and notifications.
Schema and event coverage
Firestore is schemaless and Realtime Database data is JSON-based, so mappings should handle missing fields, nested structures, type changes, and versioned paths. Confirm that the required event is available through Cloud Functions or use scheduled reconciliation.
Testing and observability
Test permission failures, quota responses, partial batch failures, malformed documents, large files, duplicate callbacks, and changed application schemas. Preserve request identifiers, document paths, object names, and function invocation identifiers while excluding credentials and sensitive data.
Why use Martini instead of scripts or point-to-point integrations?
Coordinate more than one Firebase service
Firebase integrations often span Authentication, Firestore, Realtime Database, Storage, Cloud Messaging, and Google Cloud APIs. Martini provides workflow orchestration for coordinating these calls with enterprise applications and databases.
Centralize transformation and business rules
Martini separates Firebase-specific models from target-system payloads through mappings, validation, conditional routing, and reusable integration logic.
Support reliable processing
Workflows can implement checkpoints, idempotency keys, bounded retries, asynchronous operation tracking, and replay handling instead of leaving these concerns to separate scripts.
Expose controlled APIs
When Firebase event coverage requires a Cloud Function or application bridge, Martini can expose a controlled API that validates callbacks and invokes consistent downstream processing.
Improve maintainability
Centralized configuration, secrets, monitoring, error handling, and deployment practices make Firebase integrations easier to test, operate, and evolve than isolated point-to-point code.
Frequently asked questions
Firebase can be integrated through its REST APIs and related Google Cloud APIs for Authentication, Firestore, Realtime Database, Cloud Storage, Cloud Messaging, and management operations. Selected event-driven flows can use Cloud Functions or application-managed HTTP callbacks. Enterprise workflows typically use Google service accounts and OAuth 2.0 for server-side access, with Martini handling orchestration, transformation, validation, and synchronization.
Yes. Martini can integrate with Firebase by consuming Firebase and Google Cloud REST APIs, receiving HTTP callbacks from Cloud Functions or application code, processing Storage objects, and calling Cloud Messaging. The exact authentication and endpoint depend on the Firebase product being used.
No. A dedicated Firebase connector is not required. Martini can use Firebase’s native REST APIs, Google OAuth 2.0 and service-account authentication, Cloud Functions callbacks, Storage APIs, and other confirmed Google Cloud endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Firebase with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Google or Firebase, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary method for Firebase Authentication, Firestore, Realtime Database, Cloud Storage, Cloud Messaging, and selected management operations. Cloud Functions or application-managed callbacks are appropriate for selected event-driven flows. Batch, export, import, and object APIs can support larger workloads, while GraphQL and SOAP are not confirmed as native Firebase integration methods.
Yes, when a Firebase Cloud Function, Firebase Extension, or application component sends an HTTP request to a Martini API. Event coverage is product-specific and Firebase does not provide a universal webhook for every object change. Where callbacks are unavailable, scheduled API retrieval or reconciliation can be used.
Martini can retrieve Firebase users, documents, JSON paths, or objects; map them into a canonical model; apply validation and business rules; and write them to a target system. Synchronization can use scheduled checkpoints, cursors, event identifiers, document paths, object generations, or application-maintained state. Firestore and Realtime Database should be handled according to their different document and JSON-path semantics.
Martini workflows can classify authentication, permission, quota, validation, and transient service errors, then apply bounded retries with backoff to eligible failures. Stable identifiers such as Firebase UIDs, document paths, object generations, event IDs, and message IDs can provide idempotency. Failed items can be logged and routed for replay without repeating successful operations.
Related Martini documentation
Connect Firebase with your enterprise systems
Use Martini to build maintainable Firebase integrations around REST APIs, Cloud Functions callbacks, secure Google authentication, data transformation, and reliable workflow execution.