# Odoo and Magento, connected: map your ERP product data before you import it > A working Odoo to Magento connection we built and proved for a retailer: secure sign-in, live field discovery, drag-and-drop mapping and data previews. URL: https://magento.zip/case-studies/erp-integration-odoo · Generated: 2026-10-30 03:28 UTC A multi-location retailer running its storefront on Magento wanted to find out whether it could work with **Odoo** as its ERP. Before anyone committed to that, they needed to know whether the two systems could really talk to each other, and how messy the product data would be on the way across. We built a working connection between Magento and Odoo, plus the admin tools to explore and map Odoo's product data, and proved it against a live Odoo database. To be clear from the start: **this integration was built and tested, but it did not go into production.** The automated product import was planned as a second phase that was never started. This page describes what was built and proved. ### The challenge ERP projects usually fail at the boring part: the data. An ERP holds products with its own field names, its own types (text, numbers, links to other records, selection lists), and years of half-filled fields. Magento has its own attribute model. Before a single product moves, someone has to answer: - **Can we connect at all?** Securely, with a dedicated service account, without putting passwords in code. - **What is actually in the ERP?** Which fields exist, what type each one is, and what real records look like. - **Where does each field go?** Which Odoo field becomes which Magento attribute, and what happens when a value is empty. - **Which products are in scope?** Not every ERP record belongs on the website. - **Can we test safely?** Against a test Odoo database first, without touching the live one. Normally those questions get answered in spreadsheets and email threads between the ERP consultant and the web developer. We wanted the answers inside the Magento admin, against live data, where the people doing the mapping could see them. ### What we built A set of four small Magento modules, each with one job: - **The connector.** One shared, secure connection to Odoo that every other piece uses. It handles sign-in, sends requests, reports errors clearly and keeps a log with the credentials masked out. - **The product field mapper.** An admin screen that reads Odoo's product fields live and lets you drag each one onto a Magento attribute, with default values, required flags and an order of processing. - **The query tool.** An admin "workbench" for Odoo data: browse the models, see their fields, run searches and counts, and save the queries you use often. - **A shared core.** A small service layer that gives other modules a single, cached list of the store's active locations, so later integration work had one place to ask. Everything runs inside the normal Magento admin, behind Magento's own role permissions. Viewing the query tool, running queries and saving them are separate permissions, so a merchandiser can look without being able to run anything heavy. ### How it works - **Configure the connection.** In the store configuration, an admin enters the Odoo address, the database name, and the service user and API key. The credentials are stored encrypted by Magento, never in code or files. - **Pick a mode.** A switch chooses between a *production* and a *developer* Odoo instance, each with its own address and database. Testing happens against the developer instance; flipping one setting points the store at the real one. - **Fetch the user and test.** One button signs in to Odoo and stores the service user's ID. A second button runs a full check: is everything filled in, does sign-in work, and can we read a real record? The result names the step that failed, so "it doesn't connect" becomes "the API key is wrong" or "sign-in works but this user can't read contacts". - **Discover the product fields.** The mapper asks Odoo to describe its product model and lists every field, grouped by type, with its label and help text. Next to it is the list of Magento product attributes. - **Map field to attribute.** Drag an Odoo field onto a Magento attribute, set a fallback value for when the ERP field is empty, mark it required if the product can't go live without it, and drag the mappings into the order they should be processed. - **Set the scope.** Filters (for example "active products only", or one product category) decide which Odoo products are in scope. A count button shows how many products match before anything is imported. - **Preview real data.** A preview pulls a handful of real Odoo records with only the mapped fields, so you see what the data really looks like, empty fields and odd values included, before writing an import. - **Explore anything else.** When a question goes beyond products (orders, customers, stock), the query tool runs the same kind of search against any Odoo model and keeps useful queries for next time. Mappings and filters are saved per Magento website, so a business with several storefronts can point each one at its own Odoo instance or use different mappings. ### Under the hood - **Magento / Mage-OS 2.4** on PHP 8.3, admin-side only. Nothing on the storefront changes, so the integration adds no weight to the pages customers see. - **Odoo's standard external API** (JSON-RPC), which Odoo 14 and newer support. No custom Odoo add-on is needed, so the ERP side stays a standard Odoo install that its own partner can upgrade. - **Odoo's own building blocks**: its field-description call to discover the product model, its search-and-read and count calls for previews and scoping, and Odoo's own filter syntax, so ERP people and web people speak the same language. - **Magento's configuration system** for the settings, with encrypted storage for the credentials and a scope per website. - **Magento database tables** for the field mappings and saved queries, added through Magento's declarative schema, so they install and upgrade cleanly. - **Service contracts**: each module talks to the connector through an interface, so the later import job, a cron task or a queue consumer can reuse the same connection and mappings without new plumbing. - **Verified connections**: every request checks the ERP's SSL certificate, and the log masks credentials. ### What it changed Because this never went into production, we won't quote time saved or sales gained. Here is what was proven, and what it made possible: - **The connection worked.** Sign-in, field discovery, product counts and record previews ran against a live Odoo database from inside the Magento admin. - **The data question had an answer.** Instead of guessing from documentation, the team could see the real Odoo product fields and real records, and decide which ones mattered. - **The mapping became a saved, reviewable thing** in the admin, not a spreadsheet. It was ready to drive the import job planned for phase two. - **The code was reviewed.** All four modules went through our code audit and had no open critical or high findings after the fixes. - **The decision could be made on facts.** The retailer could judge an Odoo move knowing what the web side would take, with working code instead of an estimate. What was *not* built: the automated product import itself, value transformations (for example turning ERP codes into Magento options), and syncing orders or stock back the other way. Those were the planned second phase. ### Could this work for you? This kind of groundwork pays off if you are: - **Moving to Odoo** and want to know, before you sign, what your product data looks like from the web side. - **Already on Odoo** with a Magento store kept up to date by hand or by CSV exports. - **Replatforming your store** and want the ERP connection designed in from day one, not bolted on later. - **Running several storefronts** that need different product data from the same ERP. The connector and mapper are a solid base: the next step on a new project is the import job that turns saved mappings into Magento products on a schedule, then stock and orders, one direction at a time. See our development services, or if a platform move is part of the plan, our Magento 1 to Mage-OS and Hyvä migration and Magento 2 to Mage-OS and Hyvä upgrade. Want to talk about your ERP? Get in touch. ## Links - [Page](https://magento.zip/case-studies/erp-integration-odoo) - [Store guide (llms.txt)](https://magento.zip/llms.txt)