How to Connect Shopify to Power BI: 3 Methods

Shopify is not listed in Microsoft's current Power Query connector catalogue. To connect Shopify to Power BI, you therefore choose between three routes: Shopify's GraphQL Admin API, a third-party connector, or a pipeline that lands the data in a warehouse before Power BI reads it. A connector can be enough for a quick single-store report. For reporting that must preserve history, span several stores and reconcile to finance, separating extraction from the Power BI model is the safer production pattern.

This guide was technically reviewed against Microsoft and Shopify documentation on 22 August 2026. Shopify changes its API versions and access rules regularly, so the source links are included beside the decisions they support.

The short answer: the production sequence

For a durable Shopify-to-Power-BI setup:

1. Create or install a Shopify app and grant only the read scopes the reporting needs.
2. Extract orders, line items, products, refunds and transactions with the GraphQL Admin API.
3. Use a GraphQL bulk operation for the initial historical backfill, rather than looping through thousands of API pages.
4. Land the raw response in a warehouse, retaining Shopify IDs, store, timestamps and both shop and presentment currency values.
5. Load new and changed records incrementally, then upsert them by stable Shopify ID.
6. Build a star schema and agreed measures in Power BI.
7. Reconcile sales, discounts, refunds, tax and shipping to a fixed Shopify reporting window before publishing the dashboard.

The connection is not finished when rows arrive in Power BI. It is finished when a documented measure ties back to the source and keeps doing so after the next refund, cancellation and refresh.

The three ways to connect Shopify to Power BI

1. GraphQL Admin API

Power Query's Web connector can read web APIs, so a technical team can prototype a Shopify pull. For a new integration, use GraphQL rather than REST: Shopify has treated the REST Admin API as legacy since 1 October 2024 and directs new apps and integrations to GraphQL.

This route gives you control over the fields and transformation logic. It also makes you responsible for app authentication, scopes, cursor pagination or bulk operations, API-version upgrades, schema changes, retries, secrets and refresh monitoring. Microsoft's Web connector also limits how authenticated POST requests are handled, so prove that the Power BI Service can refresh the exact design unattended before treating a desktop prototype as production.

2. Third-party connector

A connector vendor handles much of the authentication, extraction and table shaping. This is usually the quickest route when you have one store, standard reporting needs and no engineering capacity. Before buying, ask the vendor to demonstrate:

• the exact orders, line items, refunds, transactions, inventory and customer fields included;
• how much history the first sync loads and whether older orders cost extra;
• whether deleted, cancelled and subsequently refunded orders are updated;
• how API-version changes, failed refreshes and backfills are handled;
• how multiple stores and currencies are represented;
• where the copied data is stored, in which region, and how it can be deleted; and
• whether you can export your raw history if you leave.

A fast connector with an incomplete refund table is not a shortcut. It is a faster route to a number finance will reject.

3. Warehouse-first

Use a pipeline or small extraction service to land Shopify data in a warehouse, then connect Power BI to the warehouse. This costs more to establish, but it separates ingestion from reporting, preserves raw history, supports several stores and makes failed loads observable and recoverable. It is the production pattern we recommend when the dashboard will inform stock, margin or board decisions. See how this fits our data integration and warehousing work.

Which method should you choose?

Choose the lightest method that can pass the production test in the final column. If Shopify's own reports still answer the business questions, compare them with Power BI before building a new data stack. Use the free two-minute reporting checklist to identify which parts of your store reporting process need a closer look.

Access and history constraints to settle first

Shopify app tokens carry explicit scopes. A reporting integration normally starts with read_orders and adds only the product, inventory or customer scopes its model genuinely uses. Keep the access token in a server-side secret store, never in a report page or shared workbook.

There is a crucial historical constraint: the orders API exposes only the latest 60 days by default. To retrieve older orders, Shopify says the app needs approved read_all_orders access alongside read_orders. Secure that before promising a multi-year dashboard. If approval or historical access is unavailable, document the actual start date instead of presenting a partial history as complete.

For normal GraphQL queries, Shopify uses cursor pagination and returns at most 250 resources in a page. For a large initial extract, Shopify recommends a bulk query, which performs the work asynchronously and provides a JSONL result. Use standard filtered queries for small incremental loads; use bulk operations for the backfill and deliberate repairs.

A reference data model

Land source-shaped data first, then create reporting tables. A practical minimum is:

Customer data is not automatically required. Add it only if a defined use case such as cohorts or lifetime value justifies the privacy exposure and the relevant Shopify access.

Ecommerce KPIs worth modelling

Connecting the data is only half the job. The value is in a clean model that answers commercial questions. Prioritise:

• Revenue and gross sales split by net of discounts, returns and taxes, so finance and marketing see the same numbers.
• Average order value (AOV) and units per order.
• Conversion rate, where you have session data to pair with orders.
• Customer acquisition versus repeat revenue, using first-order date to cohort customers.
• Customer lifetime value (CLV) by acquisition month or channel.
• Refund and return rate, which quietly erodes apparent revenue.
• Inventory and sell-through, if stock data matters to your buying decisions.

Build these as measures over a star schema rather than as one wide imported table. It keeps definitions reusable and makes it possible to test order lines and refunds independently.

If email performance is part of the same dashboard, connect Klaviyo to Power BI with an agreed attribution definition. Compare its attributed revenue with Shopify order totals while keeping each measure traceable to its own source.

Worked reconciliation example

This is an illustrative control, not a client result. Suppose one reporting day contains £10,000 of gross line sales, £800 of allocated discounts and £350 of subsequently refunded line value. If the agreed definition excludes tax and shipping:

net merchandise revenue = £10,000 - £800 - £350 = £8,850

The Power BI measure should return £8,850 for the same store, timezone and order-status filter. Then test the components separately: gross sales £10,000, discount £800 and refund £350. A matching net total alone can hide two offsetting errors. Record whether the metric uses order date or refund date, and do not compare it with a Shopify card using a different date basis.

Common pitfalls

Discounts, taxes and shipping. Shopify exposes several monetary fields, and mixing them produces revenue numbers that do not reconcile to finance. Decide your definition of revenue up front and apply it consistently.

Time zones and currency. Shopify timestamps and multi-currency stores need normalising, or your daily trends and totals will be subtly wrong.

REST examples copied from old tutorials. REST Admin API code can still appear to work, but Shopify now classifies it as legacy. Start new work on GraphQL so the design is not obsolete on day one.

The 60-day default mistaken for full history. A successful order query does not prove that all historical orders were returned. Verify the oldest expected order and the granted scopes before signing off a backfill.

API limits on refresh. Direct queries slow down as orders accumulate and can leave you with failed or partial refreshes. Use cursor pagination deliberately, or a bulk operation for large volumes, and alert on incomplete loads.

Multiple stores. Calling each store's API separately inside Power BI becomes brittle. Consolidate into one warehouse with a store identifier so you model once and slice by store.

Getting it done properly

Before commissioning a build, write down five facts: number of stores, oldest order required, approximate order-line volume, currencies, and the systems that must reconcile with Shopify. Those facts determine whether a connector is enough or a warehouse is warranted.

Our Power BI consultants in the UK can turn that into a scoped architecture and governed model. A typical engagement starts with a fixed-scope Trusted Numbers Review (£2,000–£4,000 as of 2026, confirm current pricing) followed by a scope-locked build. For the reporting layer, see the ecommerce dashboard guide; if payment data also needs blending, see connecting Stripe to Power BI.

Book a Trusted Numbers Review with those five facts and we will tell you whether the light connector route is sufficient or whether the reporting genuinely needs an owned pipeline.

Primary technical sources

• Microsoft: current Power Query connector catalogue
• Microsoft: Power Query Web connector capabilities and constraints
• Shopify: GraphQL Admin API orders query
• Shopify: app access scopes and older-order permission
• Shopify: GraphQL pagination
• Shopify: GraphQL bulk query operations
• Shopify: REST Admin API legacy status