Integrating Epicor Kinetic to Microsoft Fabric is one of the more API-friendly manufacturing ERP integrations in the mid-market landscape. Epicor built its Open REST API on OData v4, exposes every business object - production orders, BOMs, purchase orders, quality records, inventory transactions - through the same service layer the UI uses, and provides Business Activity Queries (BAQs) as a mechanism for analysts to define and expose precisely the data views they need for external consumption. Named a Leader in the 2025 Gartner Magic Quadrant for Cloud ERP for Product-Centric Enterprises for the third consecutive year, Epicor Kinetic serves 23,000+ customers globally across discrete, mixed-mode, and engineer-to-order manufacturing - making it one of the most common manufacturing ERPs in organisations building Microsoft Fabric analytics estates.

This guide covers every production path for Epicor Kinetic to Microsoft Fabric integration: the OData v4 REST API pipeline, BAQ-based extraction for custom analytical views, direct SQL Server access for on-premises deployments, and CData Sync for automated replication. It also covers the manufacturing-specific analytics use cases that become possible once Epicor data lands in Fabric alongside financial, CRM, and operational data - the cross-functional reports that Epicor's own analytics layer, while capable within its domain, cannot produce alone.

Why Manufacturers Integrate Epicor Kinetic with Microsoft Fabric

Epicor Kinetic is a manufacturing ERP that is genuinely strong at what manufacturing ERPs exist to do: MRP runs, capacity scheduling, BOM management, shop floor control, quality management, and production cost tracking. Its native analytics layer - Kinetic Dashboards - provides real-time operational views on the ERP data for production teams. What it cannot do is answer the cross-functional questions that manufacturing leadership and finance actually need: profitability by product line combining production costs (Epicor) with customer margin (CRM), on-time delivery performance by customer segment combining scheduling data with customer data, supply chain risk combining supplier delivery performance with financial exposure.

These questions require Epicor manufacturing data to be available alongside CRM, financial, and external data in a unified analytics environment. Microsoft Fabric provides that environment. Once Epicor's job costing, inventory movements, production orders, and quality records are in OneLake, they join naturally with sales pipeline data from a CRM, financial actuals from an accounting platform, and supply chain data from procurement systems in a single Power BI semantic model. The manufacturing analytics programmes that create genuine strategic value for mid-market manufacturers - OEE analysis, perfect order rate, cost-to-serve by customer, yield variance by work centre - all require this cross-system view that Epicor's native tools can't produce.

"Epicor Kinetic tells you what happened on the shop floor. Microsoft Fabric tells you what that means for profitability, customer satisfaction, and strategic positioning - because it combines the shop floor data with everything else the business runs on."

Epicor's Integration Architecture: REST API, BAQs, and Deployment Types

Understanding Epicor Kinetic's integration architecture before selecting a Fabric path is important because Epicor has invested significantly in making its system externally accessible - more so than many manufacturing ERPs of comparable market position. Three elements of that architecture are directly relevant to Fabric integration.

Path 1 - OData v4 REST API Pipeline in Fabric Data Factory

The Epicor Kinetic REST API v2's OData v4 compliance means it works directly with the Fabric Data Factory OData connector - making this the closest equivalent to a native connector without requiring a third-party product. Any Epicor business object endpoint is queryable via the Fabric OData connector using standard OData parameters, and the response is a standard JSON OData feed that Fabric can map to a Lakehouse table without custom parsing logic.

Path 2 - BAQ-Based OData Extraction for Analyst-Defined Queries

Business Activity Queries represent a genuinely differentiated capability in Epicor Kinetic's integration architecture. A BAQ is a structured query built in Epicor's no-code query designer that can join multiple Epicor tables, apply business logic, include calculated fields, and filter by parameters - and any published BAQ is automatically available as an OData v4 endpoint. For Fabric integration, this means Epicor analysts can define the exact analytical data view needed (job profitability by work centre, material variance by BOM revision, on-time delivery by customer) and expose it as an OData feed without any additional API development work.

The BAQ endpoint URL format is /api/v2/odata/{CompanyID}/BaqSvc/{BaqId}/Data, and it accepts all standard OData query parameters including $filter, $select, $orderby, and $top/$skip for pagination. Epicor includes over 800 predefined BAQs covering standard manufacturing analytics scenarios - job operations, routing details, capacity utilisation, inventory valuation, purchase order receipt tracking, and more. These predefined BAQs are ready to expose as OData feeds without any analyst customisation.

The BAQ path is especially powerful for organisations where the manufacturing analytics team has deep Epicor knowledge but limited data engineering capacity. Rather than requiring a data engineer to understand Epicor's underlying table structure, the Epicor analyst defines the BAQ in Epicor's familiar interface, publishes it as an external-facing OData service, and the Fabric pipeline simply consumes it as a standard OData feed. This pattern also means the analytical logic lives in Epicor (where the domain expertise is) rather than in a Fabric transformation layer, reducing the risk of incorrect data interpretation during extraction.

Path 3 - Direct SQL Server Access for On-Premises Deployments

For on-premises Epicor Kinetic deployments, direct SQL Server access provides the highest-volume, lowest-latency path to Microsoft Fabric. Epicor Kinetic is built on Microsoft .NET and optimised for SQL Server - the underlying database is a SQL Server instance that Fabric Data Factory's SQL Server connector can reach directly. This path bypasses the Epicor REST API entirely, enabling high-speed bulk extraction without the OData 100-row pagination constraint and without consuming Epicor's application server resources for analytics queries.

Setting up the SQL Server connection

Create a dedicated read-only SQL Server login for Fabric integration with SELECT permissions on the Epicor database. Grant access specifically to the tables required for analytics - not db_datareader on all tables unless the full schema is needed. Configure the Fabric Data Factory SQL Server linked service with the server hostname, Epicor database name, and credentials from Azure Key Vault. For on-premises SQL Server, configure a self-hosted Integration Runtime in Fabric Data Factory to bridge between the corporate network and Fabric's cloud compute.

Key Epicor SQL Server tables for analytics

Epicor Kinetic's SQL Server database uses a consistent naming convention: table names correspond to business object names (e.g. JobHead, JobOper, JobMtl, InvTrans, OrderHed, OrderDtl). Most tables include SysRevID as an auto-incrementing revision key and ChangeDate/ChangeTime for timestamp-based incremental loading. The Company column appears in most tables for multi-company Epicor installations - always filter by company code in extraction queries for multi-company environments.

Path 4 - CData Sync Continuous Replication to OneLake

CData Sync integrates live Epicor Kinetic data into OneLake in Microsoft Fabric, allowing organisations to consolidate all data into a single location for archiving, reporting, analytics, machine learning, artificial intelligence and more. CData Sync connects to Epicor Kinetic via the REST API using the same URL, ERPInstance, user, and password credentials that the API requires, handles pagination automatically (including the 100-row OData limit that catches custom pipelines), manages authentication token refresh, and delivers data to OneLake continuously.

CData Sync's Epicor Kinetic connector covers the full range of Epicor business objects accessible via the REST API, including custom business objects created in Epicor's customisation layer. Schema changes in Epicor - new BAQs published, custom fields added to business objects, new user-defined codes - are detected and propagated to OneLake automatically without manual pipeline updates. For organisations running Epicor Kinetic SaaS where the direct SQL Server path is unavailable, CData Sync is the most operationally complete automated replication path, handling all the API complexity that a custom Fabric Data Factory pipeline would require.

Epicor Kinetic API Reference for Fabric Engineers

Epicor Kinetic to Microsoft Fabric: Full Path Comparison

Manufacturing Analytics on Epicor Kinetic Data in Fabric

Epicor Kinetic's strength is manufacturing depth - its production management, MES, advanced planning and scheduling, quality management, and BOM management capabilities are rated strong by independent ERP analysts. The analytics limitation is not within manufacturing - Epicor's native dashboards and BAQs handle operational manufacturing views well. The limitation is cross-functional: the reports that operations, finance, and leadership actually need span manufacturing data alongside data from other systems.

Once Epicor data is in Fabric OneLake, the manufacturing analytics use cases that unlock include Overall Equipment Effectiveness (OEE) combining Epicor MES production time data with IoT sensor uptime data; cost-to-serve analysis combining Epicor job costing with CRM customer revenue data; on-time delivery performance combining Epicor shipping data with customer-committed dates and CRM account data; supply chain risk assessment combining Epicor purchase order data with supplier financial health data; and yield variance analysis combining Epicor quality records with production order data by work centre and BOM revision.

For Power BI consulting teams building manufacturing analytics on Fabric, Epicor's data model is manufacturing-first and well-structured. The primary fact tables are job operations (labour and machine time), job materials (components issued), inventory transactions (stock movements), and sales order lines (demand). The primary dimensions are part (product), work centre, employee, supplier, customer, BOM revision, and plant. From these core entities, a complete manufacturing analytics model can be built - and Epicor's 800+ predefined BAQs provide a shortcut to many standard manufacturing views without requiring custom SQL or REST API pagination logic.

Common Mistakes in Epicor Kinetic to Fabric Migrations

Missing the API key header. Epicor Kinetic REST API v2 requires both a bearer token AND an API key (x-api-key) on every request. Missing either produces different error messages - a missing API key typically returns a 400 or 403 rather than the 401 that teams expect for authentication failures. Test every endpoint with both headers in Epicor's built-in REST help tool before building the Fabric pipeline.

Not building pagination for the 100-row OData limit. Pipelines that query Epicor OData endpoints without $top/$skip pagination silently return only the first 100 records and succeed with no error. For any production table - jobs, purchase orders, inventory transactions - the actual dataset is typically orders of magnitude larger than 100 records. Every Epicor OData pipeline must implement explicit pagination from the first run.

Using BAQs designed for operational reporting for bulk analytics extraction. Some predefined and custom BAQs in Epicor are designed to return small, filtered datasets for operational screens - they apply implicit filters that make sense for UI display but truncate the data for analytical extraction. Before using a BAQ as a Fabric extraction source, validate that its result set with no parameters applied returns the full population of records you expect, not a filtered subset.

Not filtering by Company in multi-company Epicor implementations. Epicor Kinetic supports multi-company implementations where a single Epicor instance serves multiple legal entities. Most Epicor database tables include a Company column as part of the primary key. Failing to include the company filter in extraction queries either returns data for all companies combined (creating a schema challenge in Fabric) or returns duplicate records if the watermark key is not fully qualified. Always include the Company column as both an extraction filter and a column in the destination Lakehouse table for multi-company environments.

Bypassing the BAQ path for custom analytics views when Epicor analysts are available. Teams with deep data engineering capacity but limited Epicor expertise sometimes build complex SQL or API extraction logic to produce the exact analytical dataset they need - when an Epicor BAQ could produce the same result in a fraction of the time. If there is an Epicor analyst available who understands the data model, the BAQ path is almost always faster and more maintainable than a custom API or SQL pipeline for producing a specific analytical view.

Conclusion

Epicor Kinetic to Microsoft Fabric integration is one of the most API-capable manufacturing ERP integrations available - the OData v4 REST API and BAQ mechanism together provide a clean, well-documented path to OneLake without requiring the custom schema knowledge that Oracle EBS or SAP ECC demand. The 100-row OData pagination limit is the most common gotcha, and it's entirely manageable with correct pipeline design. For on-premises deployments, the SQL Server direct path offers the simplest high-volume architecture. For SaaS and cloud deployments, BAQ-based OData extraction balances engineering simplicity with analytical flexibility. For organisations that want automated replication without pipeline engineering, CData Sync covers Epicor Kinetic to OneLake explicitly.

Once Epicor manufacturing data - jobs, BOM, routings, inventory, quality, shop floor transactions - is in OneLake alongside CRM, financial, and operational data, the cross-functional manufacturing analytics that Epicor's native tools can't produce become tractable Power BI queries. Numlytics delivers Microsoft Fabric migration and data engineering programmes for mid-market manufacturing organisations. Speak with a certified Fabric consultant to scope the right Epicor integration architecture for your deployment.