Application developers building on Fabric data have historically had two options for programmatic data access: the Fabric REST APIs for platform management operations, and direct SQL or DAX connections to Fabric Warehouse and Lakehouse SQL endpoints for data queries. Both work, but both impose constraints REST APIs are designed for administrative operations, not data retrieval; SQL and DAX connections require the application to manage schema knowledge, connection strings, and the complexity of joining data from multiple Fabric items. The Microsoft Fabric API for GraphQL addresses these constraints by providing a managed GraphQL endpoint over Fabric data sources giving application developers a strongly typed, schema-driven, single-endpoint API for retrieving precisely the data they need from Lakehouse, Warehouse, and SQL database sources, without SQL connection management or knowledge of Fabric's internal storage structure.

What GraphQL Is and Why It Matters for Data APIs

GraphQL is a query language and runtime for APIs developed by Meta (Facebook) and open-sourced in 2015. Unlike REST APIs, which expose fixed endpoints that return predefined data shapes - GraphQL exposes a single endpoint and a typed schema, and clients specify exactly which fields they need in each request. The server returns precisely those fields, nothing more.

This distinction has two practical benefits for data-intensive applications. First, it eliminates over-fetching a REST endpoint that returns a full customer record including 40 fields when the application only needs 4 fields wastes bandwidth and processing. A GraphQL query returns exactly those 4 fields. Second, it eliminates under-fetching a REST-based application that needs data from three different endpoints must make three separate HTTP calls and join the results client-side. A GraphQL query can request fields from multiple related entities in a single call, with the GraphQL runtime handling the joining server-side.

For Fabric data specifically, the over-fetching and under-fetching problems are significant. Fabric data sources are high-volume columnar stores, Lakehouse Delta tables and Fabric Warehouse tables can have dozens of columns. An application that wants a customer summary view needs customer-level data joined with order-level data and with product-level data across potentially three separate Fabric tables. GraphQL makes this a single structured query rather than three round trips with client-side joining.

"GraphQL is the API paradigm for applications that know exactly what data they need. Instead of adapting the application to what the API returns, GraphQL adapts the API response to what the application asks for. Over Fabric's rich data estate, this is a meaningful architecture improvement."

How Fabric's API for GraphQL Works

The Microsoft Fabric API for GraphQL is a managed Fabric item created within a Fabric workspace, associated with one or more Fabric data sources (Lakehouse, Warehouse, Fabric SQL database, or Azure SQL database), and exposed as an HTTPS GraphQL endpoint. Creating the GraphQL API item generates a schema based on the tables and views in the connected data source, translating the relational structure into a GraphQL type system automatically.

Applications authenticate to the GraphQL endpoint using Entra ID tokens the same OAuth 2.0 authentication used across Fabric's REST APIs. The GraphQL API respects the data permissions defined in the underlying Fabric data source: a user whose Entra ID account has access to only a subset of tables in the connected Lakehouse will be able to query only those tables through the GraphQL API. Row-Level Security defined at the Fabric Warehouse or SQL database layer is enforced at the GraphQL layer transparently the API does not bypass any access controls defined in the underlying source.

The GraphQL API supports both query operations (read data) and mutation operations (write data to Fabric SQL databases and Warehouse tables that support DML). For Fabric Lakehouse Delta tables, which are append-optimised for analytics, mutations are typically scoped to append-only inserts rather than arbitrary updates consistent with the Lakehouse's data engineering purpose rather than an OLTP purpose.

A GraphQL Query Against Fabric Data: What It Looks Like

A concrete query example illustrates why GraphQL's field selection matters for Fabric data access. The following query retrieves selected customer and order fields from a Fabric Warehouse, in a single API call:

query GetCustomerOrders {
  customers(where: { region: { eq: "EMEA" } }, first: 50) {
    items {
      customerId
      customerName
      accountManager
      orders(orderBy: { orderDate: DESC }, first: 10) {
        items {
          orderId
          orderDate
          totalValue
          status
          product {
            productName
            category
          }
        }
      }
    }
  }
}

This single GraphQL call retrieves 50 EMEA customers, each with their 10 most recent orders and the product details for each order data that spans three tables in the Fabric Warehouse (customers, orders, products). The same result via REST and SQL would require either a complex SQL join query (exposing the SQL interface to the application) or three separate REST calls with client-side joining. The GraphQL response contains exactly the fields requested no additional columns, no unnecessary joins, no over-fetching of data the application does not use.

Update 1 - Azure SQL and Fabric SQL Database Support

The first major update to the Fabric API for GraphQL is the addition of Azure SQL Database and Fabric SQL Database as supported data sources, alongside the previously supported Fabric Lakehouse and Fabric Warehouse. This expansion significantly broadens the range of data that can be served through the GraphQL API without requiring data to first be moved into a Fabric Lakehouse or Warehouse.

For enterprise organisations that maintain operational data in Azure SQL Database customer records, product catalogues, order management systems this means the operational SQL data and the analytical Fabric data can be accessed through the same GraphQL endpoint, with the GraphQL schema abstracting the distinction between transactional and analytical data sources from the application layer. An application querying customer data (from Azure SQL) and customer lifetime value metrics (from Fabric Warehouse) can join them in a single GraphQL query rather than managing two separate connections.

Fabric SQL Database specifically benefits from one-click API creation when creating a GraphQL API item and connecting it to a Fabric SQL database, the schema is generated from the database structure automatically, and a working GraphQL endpoint is available within minutes without any manual schema definition. This dramatically lowers the barrier to exposing Fabric SQL data through a type-safe API.

Update 2 - Saved Credentials for Secure Backend Access

The Saved Credentials feature addresses one of the most common governance concerns in enterprise API deployments: how the API connects to backend data sources without exposing sensitive connection credentials to each requesting application.

Before Saved Credentials, the Fabric GraphQL API used pass-through authentication the requesting user's Entra ID token was used to authenticate to the backend data source, which meant every user of the GraphQL API needed direct access to the underlying Fabric data source. This is appropriate for internal developer tooling but is not appropriate for application patterns where a service account should own the database connection and the application's user-facing access control layer governs what each user can request.

Saved Credentials allow the GraphQL API to maintain a pre-configured, securely stored credential set for the backend data source connection — a service principal or managed identity that the GraphQL runtime uses to connect to Fabric, independent of the identity of the requesting user. Applications authenticate to the GraphQL endpoint with their own tokens (or with application-level OAuth tokens), and the GraphQL API handles the backend connection with the saved credential. This separation is the standard security pattern for production API deployments and makes the Fabric GraphQL API suitable for customer-facing or partner-facing application scenarios where end users should not require direct Fabric data source access.

Update 3 - Monitoring Dashboard and Request Logging

The API monitoring dashboard provides visibility into GraphQL API usage and performance within the Fabric workspace. The dashboard surfaces aggregate metrics total request counts, error rates, average response times, and request volume trends over configurable time periods, alongside detailed request logs that show individual API calls with their query structure, response time, status code, and user identity.

For enterprise API governance, the monitoring dashboard enables three specific operational requirements. Performance monitoring identifies slow queries typically GraphQL queries that request deeply nested entity hierarchies or that filter on non-indexed columns in the underlying data source enabling targeted optimisation of the GraphQL schema or the underlying table indexing. Usage attribution shows which applications and users are generating API traffic, which is essential for capacity planning and for identifying unexpectedly high consumption patterns. Error tracking surfaces recurring error types — schema validation errors that indicate a client application is using an outdated schema, timeout errors that indicate query complexity issues, and authorisation errors that indicate credential or permission configuration problems.

Update 4 - CI/CD Support: Git Integration and Deployment Pipelines

The CI/CD support for Fabric's GraphQL API aligns it with the rest of Fabric's developer experience where Fabric items (Lakehouses, Notebooks, Data Pipelines) can be version-controlled in Git and deployed across environments through Fabric's deployment pipelines. GraphQL API items are now included in this framework.

Git integration means the GraphQL API definition the schema, the data source connections, and the API configuration is stored as a versioned file in the connected Git repository (GitHub or Azure DevOps). Changes to the API schema go through the same pull request and review process as changes to Notebook code or pipeline definitions, enabling the same code review, change history, and rollback capability that development teams expect for any production-grade software artefact.

Deployment pipelines extend this to environment promotion a GraphQL API definition validated in the Development workspace can be promoted to Test and then to Production through Fabric's deployment pipeline mechanism, with the environment-specific data source connections (pointing to the development, test, or production database) resolved at deployment time. This eliminates the manual effort of recreating API configurations in each environment and reduces the risk of environment drift where the production API silently diverges from the tested development version.

GraphQL vs REST for Fabric Data Access: Decision Guide

Next Steps for Enterprise Application Developers

For enterprise development teams building applications on Fabric data, the Microsoft Fabric API for GraphQL is now production-ready with the four updates covered in this guide. The recommended starting point is creating a GraphQL API item in a development Fabric workspace, connecting it to an existing Fabric SQL database or Warehouse, and generating the initial schema. The one-click schema generation for Fabric SQL databases makes this a sub-10-minute process from API creation to a working endpoint with a usable schema.

The CI/CD setup connecting the workspace to a Git repository before building the API configuration should be established at the outset rather than retrofitted after the API is built. Setting up the Git connection first means every change to the API definition is version-controlled from day one, and the deployment pipeline to Test and Production environments can be configured before the API reaches the point where it needs to be promoted.

For development teams evaluating whether GraphQL is the right interface for a specific Fabric data access requirement, the decision guide above covers the main scenario categories. If your team is building a data-intensive application on Microsoft Fabric and needs guidance on API design, GraphQL schema optimisation, or the broader Fabric application architecture that the GraphQL API fits into, speak with a certified Microsoft Fabric developer at Numlytics. For the Fabric data platform context that the GraphQL API sits on top of, see our posts on migrating to Microsoft Fabric and Cosmos DB in Microsoft Fabric.