Backend Integration for Power Apps: Connecting Firebase, Supabase & REST APIs to Microsoft Power Platform

Power Apps rarely lives alone. There is usually an existing system that owns some of the data — a warehouse platform, a booking engine, a customer-facing app on Firebase, a reporting database in Postgres. The question is how to connect them without creating something fragile.

This guide covers the integration options available, when each is appropriate, and the patterns that hold up in production.

The Integration Options

There are four realistic ways to reach an external backend from the Power Platform.

1. Custom Connectors

A custom connector wraps a REST API in a definition (OpenAPI, or built in the connector designer) that Power Apps and Power Automate can call like any built-in connector. This is the standard approach.

• Good for: Any well-behaved REST API you want to call from canvas apps and flows
• Handles: Authentication (OAuth 2.0, API key, basic), request and response shaping, policies
• Limits: Not a data source in the delegable sense — you cannot filter server-side the way you can with Dataverse

2. Power Automate as the Integration Layer

The app calls a flow; the flow talks to the external system. This keeps credentials and logic out of the app and gives you retry policies, error handling, and run history for free.

• Good for: Multi-step operations, anything needing retries, anything you want an audit trail for
• Watch for: Latency. A flow round trip is noticeably slower than a direct connector call — do not put one in a keystroke-level interaction

3. Virtual Tables in Dataverse

Virtual tables surface external data as if it were a Dataverse table, without copying it. Model-driven apps, views, and security behave normally, but the data stays in the source system.

• Good for: Read-heavy scenarios where duplication is unacceptable and the source is authoritative
• Cost: Requires a provider — OData out of the box, or a custom plugin for anything else. Performance is bounded by the external system

4. Scheduled Synchronisation

Copy data into Dataverse on a schedule and let apps work against the local copy.

• Good for: Reference data, anything needing delegable queries over large volumes, offline scenarios
• Cost: Staleness, and a sync process that must handle failure and conflict

Never Put Credentials in the App

This is the single most important rule and the most commonly broken one.

Canvas app formulas are not secret. Anyone who can open the app in Power Apps Studio, or inspect traffic from the client, can see values embedded in the app. An API key placed in a variable, a connection string in a collection, or a service account password in a hidden label is exposed.

What To Do Instead

• Put the secret in Azure Key Vault and reference it from a custom connector's authentication configuration or from a flow
• Use a custom connector with OAuth 2.0 so each user authenticates as themselves and you never handle a shared secret
• If a service must act on behalf of the app, put an Azure Function or API Management in front of it that holds the credential server-side and enforces its own authorisation

Connecting to Supabase

Supabase exposes a PostgREST API over your Postgres schema, which maps cleanly onto a custom connector.

Setup Outline

1. Enable Row Level Security on every table you will expose. Without RLS, the anon key can read everything
2. Write policies that express who may see and change what
3. Create a custom connector pointing at https://<project>.supabase.co/rest/v1
4. Configure authentication — the API key header plus a bearer token
5. Define the operations you need rather than exposing the whole schema

A typical read

GET /rest/v1/orders?select=id,total,created_at,customers(name)&status=eq.open
apikey: <anon key>
Authorization: Bearer <user jwt>

The important part is the JWT. If you pass a user-specific token, RLS applies and the user sees only their rows. If you pass the service role key, RLS is bypassed entirely — that key must never leave a server you control.

Calling It From a Canvas App

ClearCollect(
    colOpenOrders,
    SupabaseConnector.ListOrders({ status: "open" })
);

Note what this does not give you: delegation. The filter runs server-side because you passed it as a parameter, but Power Apps cannot translate an arbitrary Filter() over the result into a server query. Design your connector operations around the queries you actually need, and pass filters as explicit parameters.

Connecting to Firebase

Firestore's REST API is usable but its JSON shape is awkward — every value is wrapped in a type descriptor.

{
  "fields": {
    "total":  { "doubleValue": 249.5 },
    "status": { "stringValue": "open" }
  }
}

Mapping that in and out of Power Apps formulas is tedious and brittle. The pragmatic approach is to put a thin translation layer in front of it.

Recommended Pattern

Write a Cloud Function (or Azure Function) that exposes clean, flat JSON for the specific operations Power Apps needs, and point your custom connector at that. This gives you:

• A stable contract that does not change when your Firestore document shape changes
• A place to enforce authorisation independently of Firestore rules
• Somewhere to hold the service credential securely
• Freedom to aggregate several document reads into one response, which matters because Firestore bills per read

Trying to talk to Firestore's raw REST API directly from canvas formulas is possible and consistently regretted.

Custom REST APIs and GraphQL

REST

If you control the API, a few choices make Power Platform integration much smoother:

• Return flat JSON objects. Deeply nested structures are painful in Power Fx
• Use consistent, predictable field names and types — a field that is sometimes a string and sometimes a number will break the connector schema
• Provide server-side filtering and paging parameters
• Return proper HTTP status codes; flows branch on them
• Publish an OpenAPI definition — the connector can be generated from it directly

GraphQL

GraphQL fits Power Platform poorly. Everything is a POST to one endpoint with the query in the body, so the connector cannot infer operations or response schemas. The workable approach is to define one connector action per query you need, each with a fixed query string and typed variables — effectively rebuilding a REST surface. If you are designing the backend anyway, expose REST for the Power Platform consumer.

Error Handling

External calls fail. Networks time out, tokens expire, rate limits trigger. An app that shows a blank screen when this happens will be reported as broken.

IfError(
    ClearCollect(colOrders, SupabaseConnector.ListOrders({ status: "open" })),
    Notify(
        "Could not load orders. Showing last known data.",
        NotificationType.Warning
    )
);

Three habits that prevent most support tickets:

• Always wrap external calls in IfError and tell the user what happened
• Cache the last successful response so a transient failure degrades rather than blanks the screen
• Put retries in Power Automate, not in the app — flows have proper retry policies and you get run history when something goes wrong

Rate Limits and Throttling

The Power Platform enforces its own API request limits per user, and your external service has limits of its own. The pattern that breaks both is a gallery whose items each trigger a call.

Fetch once into a collection and bind the gallery to that collection. If you need per-row detail, load it on selection rather than on render. For bulk operations, batch them into a single flow invocation rather than looping calls from the app.

A Hybrid Architecture That Works

For most organisations running both a Power Platform estate and a custom product, this shape holds up:

• Dataverse is the system of record for business entities, with security roles and audit
• Model-driven apps serve internal back-office users — no custom code needed
• Canvas apps serve task-focused internal workflows, including mobile
• A custom backend (Supabase or Firebase) serves the customer-facing product, outside the Microsoft licensing boundary
• An integration layer — Power Automate for event-driven sync, a scheduled job for bulk reconciliation — keeps them consistent

The rule that keeps this maintainable: each entity has exactly one owner. Bidirectional sync where both sides can edit the same field is where these architectures go wrong. Decide which system wins, and make the other one read-only for that field.

Conclusion

Successful integration comes down to a few decisions made early: keep secrets server-side, put a purpose-built API layer between Power Apps and anything with an awkward wire format, design connector operations around real queries instead of exposing a whole schema, and give every entity a single owner.

Get those right and the integration becomes unremarkable — which is exactly what you want from infrastructure.