Odoo to Microsoft Fabric: Open-Source ERP Integration Guide
Odoo's three deployment types - Online (SaaS), Odoo.sh, and self-hosted - each enable different integration paths to Microsoft Fabric. The right architecture depends on whether you have direct PostgreSQL access and which API generation your Odoo version uses.
Integrating Odoo to Microsoft Fabric is one of the more deployment-sensitive problems in the ERP analytics landscape, because the right integration path depends fundamentally on which of Odoo's three hosting models you're running - Online SaaS, Odoo.sh, or self-hosted. Self-hosted Odoo runs on a PostgreSQL database your organisation controls, which means Fabric's standard PostgreSQL connector can reach it directly. Odoo Online and Odoo.sh restrict database access to varying degrees, requiring extraction through the Odoo API. And that API is in the middle of its most significant architectural transition in a decade: XML-RPC and JSON-RPC, the foundations of virtually every existing Odoo integration built before late 2025, are deprecated as of Odoo 19 and scheduled for removal on Odoo Online by winter 2027 and on self-hosted by fall 2028. The replacement is the JSON-2 External API, introduced in Odoo 19, authenticated with bearer API keys rather than username and password.
This guide covers every viable production path for Odoo to Microsoft Fabric integration - the direct PostgreSQL path for self-hosted environments, the JSON-2 API pipeline for cloud deployments, CData Sync for automated replication, and the Odoo App Store native connectors - with the specific facts about the API deprecation timeline that every architect building or maintaining an Odoo Fabric integration must understand.
As of July 2026, Microsoft Fabric Data Factory does not include a native first-party Odoo connector. Odoo's XML-RPC and JSON-RPC APIs are deprecated as of Odoo 19 (September 2025), with removal on Odoo Online scheduled for winter 2027 and on self-hosted for fall 2028. The replacement is the External JSON-2 API, available now in Odoo 19+ including Community Edition, using bearer API key authentication. New Odoo Fabric integrations should target JSON-2, not XML-RPC or legacy JSON-RPC.
Odoo's Three Deployment Types and What Each Enables
Understanding Odoo's deployment options is the prerequisite for any Fabric integration architecture decision. Each deployment type grants different levels of database and API access, which directly determines which integration paths are available.
The Critical API Deprecation: XML-RPC, JSON-RPC, and the JSON-2 Transition
The most important fact for any organisation building or maintaining an Odoo Fabric integration in 2026 is the API deprecation timeline. Odoo 19, released September 2025, formally deprecated the XML-RPC and JSON-RPC endpoints that power virtually every existing Odoo integration built before late 2025. The removal schedule from Odoo's official documentation is clear:
XML-RPC (/xmlrpc, /xmlrpc/2) and JSON-RPC (/jsonrpc) endpoints are deprecated in Odoo 19 (September 2025). Removal is scheduled on Odoo Online 21.1 (winter 2027) and on Odoo 22 self-hosted (fall 2028). The replacement is the External JSON-2 API at /json/2/<model>/<method>, available in Odoo 19+ including Community Edition, authenticated with bearer API keys. Any Odoo Fabric pipeline built on XML-RPC or legacy JSON-RPC is a migration you are scheduling for 2027 or 2028. New integrations should target JSON-2 exclusively.
The practical implication is direct: any Fabric pipeline or third-party connector that calls Odoo's legacy XML-RPC or JSON-RPC endpoints has a defined expiry date. On Odoo Online, that date is winter 2027. On self-hosted, it is fall 2028. Teams running existing Odoo Fabric integrations should audit whether those integrations use /xmlrpc/2 or /jsonrpc endpoints, and begin the migration to JSON-2 architecture while those legacy endpoints still respond - not after they've gone dark. The JSON-2 API is available today in Odoo 19 Community Edition and Enterprise, requires no additional licence beyond the Custom plan for external API access on Online, and uses bearer API key authentication rather than username and password.
"Every XML-RPC Odoo connector built before Odoo 19 is running on borrowed time. Odoo Online removes it in winter 2027. Build against JSON-2 now - the migration will happen regardless, and doing it proactively is cheaper than an emergency migration when legacy endpoints stop responding."
Path 1 - Direct PostgreSQL Access (Self-Hosted and Odoo.sh Dedicated)
For self-hosted Odoo and Odoo.sh on dedicated hosting, direct PostgreSQL access is the most architecturally efficient path to Microsoft Fabric. The Fabric Data Factory PostgreSQL connector reads directly from the Odoo PostgreSQL database without going through Odoo's API layer, which means no API rate limits, no authentication complexity, and extraction performance that scales with the database rather than the API concurrency ceiling.
crm_lead, invoices in account_move and account_move_line, sales orders in sale_order and sale_order_line, inventory in stock_move, purchasing in purchase_order, HR in hr_employee. Most Odoo tables include write_date as an update timestamp - use this as the watermark field for incremental extraction. Build a configuration table in Fabric storing the table name, watermark column (write_date), and last extracted value. A ForEach activity iterates over the configuration table, executes parameterised Copy Activities per Odoo table, and lands data in the Lakehouse Bronze layer as Delta Parquet.partner_id, product_id, user_id) and Many2many junction tables. Raw extraction lands these as integer IDs rather than descriptive values. In the Fabric Silver layer, join Odoo tables on their IDs to resolve foreign keys into readable dimensions. Many2many relationships - such as tags on CRM leads or attributes on products - are stored in junction tables (e.g. crm_lead_tag_rel) that require explicit joins. Build the Odoo data model in the Fabric Gold layer as a clean star schema for Power BI, with fact tables (sales order lines, invoice lines, stock moves) and dimension tables (partners, products, employees, accounts).Odoo's open-source architecture means most implementations have custom modules that add tables, columns, or modify standard table structures. Direct PostgreSQL extraction picks up custom tables automatically - but your Fabric data model needs to know about them. Before finalising the pipeline configuration table, run a discovery query against the Odoo database to identify all non-standard tables (those not in the standard Odoo module set) and decide which carry analytical value worth including in the extraction. Custom field columns on standard tables are also common - these appear as standard columns in the Odoo PostgreSQL schema and are included in any SELECT * extraction.
Path 2 - JSON-2 API Pipeline in Fabric Data Factory
For Odoo Online and Odoo.sh non-dedicated deployments where direct PostgreSQL access is unavailable, the External JSON-2 API is the correct extraction mechanism for new integrations. The JSON-2 API is available in Odoo 19+ (including Community Edition), authenticated with bearer API keys generated in Settings → Users → API Keys, and accessed at /json/2/<model>/<method>.
Authentication and API key setup
Generate an API key in the Odoo UI under Settings → Users → your integration service user → API Keys. The JSON-2 API uses this key as a bearer token in the Authorization: Bearer {api_key} header. Unlike the legacy XML-RPC approach that required separate authenticate and execute calls, JSON-2 uses the API key directly in the request - simpler and more secure. Store the API key in Azure Key Vault. Create a dedicated integration service user in Odoo with the minimum read permissions required for the modules you're extracting - never use an admin account for API pipelines.
Reading data with JSON-2: search_read pattern
The core data extraction pattern in JSON-2 is equivalent to the legacy execute_kw search_read call but at the new endpoint. Use POST /json/2/{model}/search_read with a JSON body specifying domain filters, fields, limit, and offset. For incremental loading, include a domain filter: [["write_date", ">", "{watermark}"]]. Use a batch size of 500–1,000 records per request to balance throughput against API responsiveness. For large tables with millions of records, schedule extractions during off-peak hours and consider using read_group for aggregate-only use cases (e.g. sales totals by month) to reduce API call count significantly compared to record-by-record extraction.
Webhooks for near real-time updates
Odoo 17 introduced native webhooks, and Odoo 18 made them a practical option for event-driven Fabric integration. Configure webhooks in Odoo for specific model events - sales order confirmed, invoice posted, inventory transaction created - to trigger a Fabric pipeline run via an Azure Logic Apps or Power Automate webhook receiver. This pattern provides near real-time Odoo data in Fabric without continuous API polling, and is particularly valuable for use cases where freshness matters - live sales dashboards, real-time inventory tracking, cash collection status. A polling fallback covering models not supported by webhooks is still required for comprehensive coverage.
Path 3 - CData Sync Continuous Replication to OneLake
CData Sync provides automated, continuous, customizable Odoo data replication to OneLake in Microsoft Fabric, integrating live data from both Odoo API 8.0+ and Odoo.sh Cloud ERP. CData Sync handles the Odoo API's relational complexity - many-to-one, one-to-many, and many-to-many data properties - intelligently without requiring custom transformation logic in Fabric pipelines. The connector manages API authentication, rate limiting, incremental change detection, and schema evolution automatically.
A specific strength of CData Sync for Odoo is its handling of Odoo's multi-value column types - the Many2one, One2many, and Many2many fields that store relational data as arrays or nested objects in the Odoo API response. CData's driver decodes these relational values into a flat, replicable structure suitable for OneLake storage without requiring custom transformation code. For organisations with heavily customised Odoo implementations where the API returns non-standard field structures, CData Sync's intelligent schema handling reduces the transformation work significantly compared to a custom pipeline.
CData Sync covers both Odoo API 8.0+ (the legacy XML-RPC/JSON-RPC generation) and Odoo.sh Cloud ERP, meaning it handles the current API generation while the transition to JSON-2 plays out across Odoo versions. As CData updates its connector for JSON-2, existing Sync configurations will benefit without requiring manual migration of the pipeline architecture.
Path 4 - Odoo App Store Fabric Connectors
The Odoo App Store includes purpose-built Microsoft Fabric connector modules that install directly into Odoo and establish data sync pipelines without requiring external pipeline engineering.
The Niyu Labs Microsoft Fabric Connector (discussed in technical architecture analysis from April 2026) addresses the performance problem with direct API queries at scale through a middleware buffer pattern: data is collected inside Odoo via an installed module, staged in a warehouse layer, and Microsoft Fabric queries the middleware rather than Odoo directly - preventing heavy analytical extraction from impacting Odoo's live operational responsiveness. The connector includes intelligent schema mapping (selecting specific models and columns before transmission), advanced domain filtering (e.g. only "Done" stock moves or "Posted" invoices), and buffer-layer architecture that decouples Fabric's read patterns from Odoo's write patterns.
A second module, the Microsoft Fabric Connector for Odoo (available for Odoo 17–19 in the App Store), creates a data pipeline using REST APIs to fetch data from Odoo into Microsoft Fabric and supports Odoo versions 17.0 through 19.0, covering the version range most commonly seen in active mid-market deployments. A third module, sh_odoo_fabric_connector, provides seamless integration for Odoo 17 with Microsoft Fabric for advanced analytics and reporting.
App Store connectors carry the advantage of being Odoo-native - they install like any other Odoo module, leverage Odoo's own security model, and can be configured by Odoo administrators without separate pipeline engineering. The trade-off is dependency on the module vendor's maintenance cycle and the risk that a module doesn't survive the Odoo version upgrade that includes JSON-2 removal of the legacy API. Verify connector compatibility with your current Odoo version and the module vendor's roadmap for JSON-2 support before committing to an App Store path for production.
Odoo API Reference for Fabric Engineers
POST /json/2/{model}/{method}. Authentication: bearer API key in Authorization: Bearer {api_key} header. API keys generated in Settings → Users → API Keys. Available in Odoo 19+ including Community Edition. External API access on Odoo Online requires Custom pricing plan (not available on One App Free or Standard)./xmlrpc, /xmlrpc/2) and JSON-RPC (/jsonrpc) deprecated in Odoo 19. Removal on Odoo Online 21.1 (winter 2027). Removal on self-hosted Odoo 22 (fall 2028). The db service was removed in Odoo 20. common and object services scheduled for removal in Odoo 22. Legacy endpoints may be re-enabled on self-managed instances via module reinstall as a temporary measure - not recommended for production.search_read: retrieve records with domain filter, field selection, limit, offset. Use for primary data extraction. read_group: aggregate records by group - use for aggregate-only queries (monthly sales totals, inventory by category) to dramatically reduce API call count vs record-level extraction. search_count: count records matching a domain - use before large extractions to estimate volume and plan batching. Avoid "search in loops" - use domain filters and aggregation patterns instead.write_date as an update timestamp. Use domain filter [["write_date", ">", "{watermark}"]] for incremental extraction. Deleted records are not surfaced by the standard API - they require querying Odoo's mail.message tracking or implementing custom deletion tracking in an installed Odoo module. For PostgreSQL path, query the standard Odoo ir.logging or custom deletion logs if delete propagation to Fabric is required.Odoo to Microsoft Fabric: Full Path Comparison
| Dimension | Direct PostgreSQL | JSON-2 API Pipeline | CData Sync | App Store Connector |
|---|---|---|---|---|
| Deployment compatibility | Self-hosted; Odoo.sh dedicated only | All deployments (Custom plan required for Online) | All deployments (API 8.0+ and Odoo.sh) | All deployments (module installed in Odoo) |
| API deprecation risk | ✓ None - PostgreSQL not affected | ✓ None - JSON-2 is the forward path | ◑ Depends on CData update cadence for JSON-2 | ◑ Depends on module vendor roadmap |
| Engineering effort | Medium - pipeline + medallion schema design | High - auth, pagination, watermark, batching | Low - configure and run | Low - install module and configure |
| Customisation coverage | ✓ All tables including custom | ✓ All models including custom | ✓ Handled automatically | ◑ Varies by connector module |
| Relational complexity handling | Manual - join FKs in Silver layer | Manual - flatten Many2x fields in pipeline | ✓ Intelligent handling built-in | ◑ Varies by connector |
| Production impact on Odoo | ✓ None - read-only analytics user | ◑ API calls consume Odoo server resources | ◑ API-based, managed throttling | ✓ Middleware buffer decouples Fabric reads |
| Connector cost | ✓ None beyond Fabric DF | ✓ None beyond Fabric DF | CData Sync licence | Odoo App Store module licence |
| Best for | Self-hosted; highest volume; fastest extraction | Odoo Online / Odoo.sh non-dedicated; full control | Any deployment; no pipeline engineering | Odoo admins without data engineering capacity |
Odoo Modules and Key Data Models for Analytics
Odoo's modular architecture means the tables and models available for extraction depend on which modules are installed. The following are the core models most commonly included in an Odoo to Fabric analytics programme, mapped to their PostgreSQL table names for the direct database path and their API model names for the JSON-2 path.
sale_order, sale_order_line) are the primary revenue fact. CRM leads and opportunities (crm_lead) provide pipeline data. API models: sale.order, sale.order.line, crm.lead. Join on partner_id to res_partner (customers) and product_id to product_product (products).account_move (header) and account_move_line (lines). Filter by move_type to separate invoice types (out_invoice, in_invoice, out_refund, in_refund). API model: account.move. The chart of accounts is in account_account. Payments are in account_payment.stock_move) are the primary inventory fact - every goods-in, goods-out, and transfer creates a stock move record. Current stock levels are in stock_quant. Products: product_product (variants) joins to product_template (templates with shared attributes). Warehouses and locations: stock_warehouse, stock_location.purchase_order, purchase_order_line) provide AP and procurement analytics. Join to res_partner on partner_id for supplier data. API model: purchase.order.hr_employee), leave requests (hr_leave), and payslips (hr_payslip, hr_payslip_line) if HR and Payroll modules are installed. HR data often has row-level security in Odoo - verify the integration service user has appropriate permissions before extracting HR tables.Power BI Reporting on Odoo Data in Fabric
Once Odoo data lands in a Fabric Lakehouse, Power BI in DirectLake mode queries OneLake directly - enabling large-scale Odoo reporting without import latency or refresh windows. The most valuable Power BI use cases on Odoo data in Fabric are precisely the cross-module reports that Odoo's native reporting can't produce: sales pipeline combined with actual invoiced revenue and open AR aging; inventory valuation combined with purchase costs and landed cost adjustments; gross margin by product category combining invoice line revenue with inventory cost-of-goods data.
Odoo's native reporting is strong within individual modules - the Sales Analysis, Inventory Valuation, and Financial Reports dashboards are well-designed. The limitation is the module boundary: a report that combines CRM pipeline data with invoice revenue with stock availability requires manual export from three Odoo views and manual join in Excel. In Fabric, these are single Power BI queries against the star schema built from Odoo's underlying tables. For Power BI consulting teams, the Odoo data model in PostgreSQL is normalised and well-structured - the star schema design for Odoo analytics is tractable from the underlying tables without requiring significant denormalisation logic.
Common Mistakes in Odoo to Microsoft Fabric Integrations
Building new integrations on XML-RPC or legacy JSON-RPC. The most consequential mistake for any new Odoo Fabric pipeline started in 2026 is targeting the deprecated API endpoints. XML-RPC integrations built today will require migration by winter 2027 (Odoo Online) or fall 2028 (self-hosted). Build against JSON-2 now.
Using the Odoo admin user for the API integration service account. The Odoo admin account has access to every model and every record. Using it for a Fabric pipeline creates an unnecessarily broad permission surface and a security risk if the API key is compromised. Create a dedicated integration user with only the read permissions required for the modules being extracted.
Querying Odoo's API directly with live analytical workloads without a buffer layer. High-frequency API polling for large Odoo models - especially during business hours - consumes Odoo server resources and can degrade operational responsiveness for users. Schedule large API extractions during off-peak hours, use the Niyu Labs or similar middleware buffer architecture for continuous sync, or use the PostgreSQL direct path (where available) to separate the analytical load from Odoo's operational compute.
Not planning for deleted records. The Odoo API's search_read with a write_date watermark does not surface deleted records - deleted records are no longer in the model and won't appear in any API response. For use cases where deletion propagation matters (customer records deleted, sales orders cancelled and removed), implement Odoo's native deletion tracking via the mail.message chatter log or install a custom module that logs deletions before they occur. On the PostgreSQL direct path, the same constraint applies unless Odoo is configured to soft-delete rather than hard-delete.
Ignoring Odoo's Many2many table structure in the PostgreSQL schema. Many2many relationships in Odoo are stored in junction tables (e.g. sale_order_tag_rel, res_partner_category_rel). Teams that extract only the primary tables and miss the junction tables produce a Fabric model with missing dimensions - reports on tag-based or category-based segmentation fail because those attributes weren't extracted. Include junction tables in the pipeline configuration table for any Many2many relationship relevant to your analytics use case.
/json/2/{model}/{method} with bearer API key authentication.write_date as the incremental watermark, build a dedicated read-only analytics user, and handle Many2x relationships in the Fabric Silver layer.Conclusion
Odoo to Microsoft Fabric integration is straightforward for self-hosted environments - direct PostgreSQL access provides the fastest, most complete data extraction path available for any ERP in this guide. For Odoo Online and Odoo.sh, the JSON-2 API introduced in Odoo 19 is the correct forward path, replacing the deprecated XML-RPC and JSON-RPC endpoints that still function today but have a defined removal date. The architectural decision is primarily shaped by deployment type and API generation: self-hosted organisations should use the PostgreSQL path; cloud deployments should build against JSON-2 now rather than legacy RPC.
The open-source architecture of Odoo - with its predictable PostgreSQL schema, well-documented API, modular data model, and active App Store connector ecosystem - makes it one of the more tractable ERP analytics integration problems in the mid-market. Once Odoo data lands in Fabric OneLake, the cross-module analytics that Odoo's native module-bounded reporting can't produce - margin by customer across sales and accounting, inventory risk across stock and procurement, project profitability across manufacturing and HR - become natural Power BI queries against a unified data model. Numlytics delivers Microsoft Fabric migration and data engineering programmes across mid-market ERP platforms. Speak with a certified Fabric consultant to scope the right Odoo integration architecture for your deployment.