BambooForge Medusa Connector
A real, two-way connector between Odoo 18 and Medusa.js — the open-source headless commerce platform. Sync products (with variants, options & images), customers, orders and refunds over a clean JSON REST client that speaks both Medusa v2 and v1 — with a resilient queue, signed webhook push, dry-run safety and full source you can audit.
Verified live against a running Medusa
We don't just claim a vague version range. The connector was installed on Odoo 18, pointed at a live, locally-run Medusa 2.16, and run through a full product / customer / order / refund import — 0 errors.
| Medusa version | API line | Live result |
|---|---|---|
| 2.16.0 | v2 Admin API (JWT / secret key) | ✔ Live-tested — 0 errors |
| 2.x line | v2 Admin API | ✔ Supported (same v2 endpoints) |
| v1 line | v1 Admin API | Supported via capability layer — validate on your build |
The live test imported a product with 8 variants (built from Medusa options into Odoo attribute lines), a customer with address, an order through the state-machine mapping, and a credit-note refund — all green. Money units are handled per line (v2 major units, v1 cents) so prices land correctly.
Built to actually sync — not to look busy
Medusa returns clean, fully-expanded JSON, and this connector treats it that way: one request returns a product with its variants, options, images and categories inline. Every model ships with verifiable sync logic, covered by tests — no fake dashboards, no “readiness score” with nothing behind it.
What you actually get
Everything below ships in the box — including the TypeScript webhook subscriber companion and a bundled mock Medusa API so you can demo without a live store.
Products, variants & options
Medusa options become Odoo product.attribute lines and variants are generated automatically. Prices are picked in your configured currency; image URLs and thumbnail are captured.
Customers & addresses
Each Medusa customer becomes a res.partner; their addresses become child partners with billing / delivery type inferred from the default-billing flag.
Orders with state machine
Orders import with line items, shipping and tax totals, and the payment provider. Medusa status maps to Odoo confirm / cancel / draft through an editable mapping table per instance.
Refunds → credit notes
Medusa refunds (under an order's payment collection) become draft Odoo account.move credit notes linked to the order. Optional auto-post for hands-off workflows.
Signed webhook subscriber
A bundled TypeScript subscriber drops into your Medusa project and POSTs HMAC-SHA256-signed events on product / customer / order changes. Real-time — no polling cron required.
v1 + v2 JSON client
One client, three auth modes (admin secret key, bearer, email+password JWT with auto-refresh), limit/offset paging, retry with backoff and 429 handling.
Sync Control Tower
A live operations dashboard — a kanban of your instances with per-instance health, circuit-breaker state, queue backlog, dead-letter count, conflict count, 24h throughput and failure rate as clickable stat cards. At-risk instances are coloured; each card drills straight into the queue, dead-letter or conflict view.
Bulk dead-letter console
A dedicated view of exhausted-retry jobs, grouped by error type, with bulk requeue or discard actions — clear a whole class of failures in one move once you've fixed the root cause.
Conflict-resolution workbench
A triage list with a side-by-side Odoo-vs-Medusa snapshot diff, plus bulk resolve: Odoo-wins, remote-wins, or mark-reviewed. Every divergence is captured and actioned, never silently dropped.
Conditional branching
The multi-step flow engine walks true/false branches: a condition step's boolean result routes to true_step_id or false_step_id, with a loop guard against cyclic links. Flows with no branch links simply fall through to the next step — fully backward-compatible.
Field-Mapping Studio
A payload-test wizard: paste a sample Medusa JSON payload and see exactly how each field mapping transforms it, in a consolidated mapping studio view — plus one-click mapping suggestions to get you started.
Two-way stock service
Real bidirectional inventory. A delta-reconcile cron pushes Odoo on-hand for every bound product to Medusa via the Admin API (POST /admin/products/{id} carrying only inventory_quantity), guarded by a 3-layer oversell clamp (instance guard + safety buffer + final ≥0 clamp). Opt-in import writes Medusa stock into real Odoo inventory as an adjustment — never in dry-run.
A live walkthrough inside Odoo 18
Recorded in a real Odoo 18 connected to a live Medusa 2.16 — the connection cockpit, a synced product and order, the state mapping and the flow engine, all on real data.
Every screen, from a live install
Captured from a running Odoo 18 connected to a live Medusa 2.16 — real data synced through the connector, not mockups.
Run every Medusa store from one Control Tower
A short walkthrough of the operations tooling on real data: the Control Tower board, the side-by-side conflict workbench and the bulk dead-letter console.
Production safety, by default
Resilient queue
Retry with exponential backoff, rate-limit awareness, dead-letter handling and conflict capture for every job.
Circuit breaker
Auto-pauses sync after N consecutive failures so a broken endpoint can never flood your data.
Dry-run mode
Default-ON for every new instance — preview the exact write before anything touches live records.
Pre-flight validation
Blocking and warning findings surfaced before go-live, with auto-fix suggestions.
Rollback snapshots
Capture record state before risky writes and roll back cleanly when needed.
SSRF-safe by default
Internal / loopback hosts are blocked unless you explicitly opt in for a trusted self-hosted Medusa.
Honest feature matrix
No asterisks, no fake checkmarks. Here is exactly what version 1 does — and what is on the v2 roadmap.
| Capability | Status |
|---|---|
| Product import (title, description, status, handle) | ✔ Included |
| Variants & options → Odoo attribute lines | ✔ Included |
| Variant prices, currency-aware (v2 major / v1 cents) | ✔ Included |
| Image URLs + thumbnail capture | ✔ Included |
| Categories → Odoo product category | ✔ Included |
| Customers + addresses | ✔ Included |
| Orders + line items + state mapping | ✔ Included |
| Refunds → draft credit notes (auto-post optional) | ✔ Included |
| Auth: secret key · bearer · email+password JWT | ✔ Included |
| Signed webhook subscriber (TypeScript, included) | ✔ Included |
| Queue: retry · backoff · dead-letter · circuit breaker | ✔ Included |
| Pre-flight validation · rollback snapshots · dry-run | ✔ Included |
| Schema introspection & field mapping (JSON path + transforms) | ✔ Included |
| Sync Control Tower — live per-instance health & queue dashboard | ✔ Included |
| Bulk dead-letter console (requeue / discard by error type) | ✔ Included |
| Conflict-resolution workbench (Odoo-vs-remote diff, bulk resolve) | ✔ Included |
| Conditional branching in the flow engine (true/false steps) | ✔ Included |
| Field-Mapping Studio (payload-test wizard + suggestions) | ✔ Included |
| Two-way stock sync (delta push via Admin API + oversell guard) | ✔ Included |
| Product export Odoo → Medusa (create / update) | Beta — validate on your catalog |
| Image binary upload Odoo → Medusa | Roadmap v2 |
| Multi-region price lists | Roadmap v2 |
Live in four steps
A guided quick-setup wizard and onboarding checklist walk you from API key to first safe sync.
Connect
Enter your Medusa URL + admin key (or email/password). One click tests credentials and reachability.
Map
Run schema introspection and generate suggested field mappings automatically.
Dry-run
Preview exact writes with dry-run + validation on. Clear any blocking findings.
Go live
Drop in the webhook subscriber and let the resilient queue keep both systems in sync.
Buy with full clarity
In the box today
- Two-way sync: products, customers + addresses, orders, refunds
- Two-way stock sync — delta push to Medusa via the Admin API with a 3-layer oversell guard, plus opt-in import into real Odoo inventory
- Sync Control Tower — live kanban of instance health, queue backlog, dead-letters, conflicts, 24h throughput & failure rate
- Bulk dead-letter console — requeue or discard exhausted jobs by error type
- Conflict-resolution workbench — side-by-side Odoo-vs-Medusa diff with bulk resolve
- Conditional branching in the flow engine — true/false step routing with a loop guard
- Field-Mapping Studio — paste a payload, see every mapping transform, with one-click suggestions
- TypeScript webhook subscriber — included, not sold separately
- Bundled mock Medusa API — demo without a live store
- 38 automated tests (unit + HttpCase, all green)
- Full source included — audit and extend every line for your own use
Deferred / beta
- Product export Odoo → Medusa is in beta (import is the primary path)
- Image binary upload Odoo → Medusa (image import is read-only today)
- Multi-region price-list sync
- v1 line is supported via the capability layer — validate on your build
Frequently asked
Which versions are supported?
Odoo 18.0 on the Odoo side. On the store side, the connector was live-tested on Medusa 2.16 (v2 Admin API) and supports the v2.x line on the same endpoints; the v1 line is supported through a capability layer — validate it on your specific build.
Do I need to install Medusa to evaluate it?
No. A mock Medusa API ships inside, so you can install, explore and demo the full import flow before connecting a real store.
How does authentication work?
Three modes: a v2 admin secret API key (HTTP Basic), a pre-issued bearer token, or email + password exchanged for a JWT (auto-refreshed on expiry). Pick one per instance.
Is the webhook companion extra?
No. The HMAC-SHA256 signed TypeScript subscriber ships inside this package under phase2/medusa_subscriber/, with install instructions.
Is it safe to run against production data?
Dry-run mode is ON by default for new instances, validation blocks risky writes, and rollback snapshots let you undo. You decide when to go live.
What support and refund policy do I get?
Every request is answered within 24 hours, setup help included. If you report a bug within 2 months of purchase and it isn't resolved within 15 days, you're entitled to a full money-back refund.
Connect Odoo and Medusa the honest way
24-hour support · Report a bug within 2 months — unresolved in 15 days = full refund · Full source included
bambooforge.labs@gmail.comMore from BambooForge Labs — one vendor, the same standard: tested, source included, supported.
BambooForge Medusa Connector
A two-way bridge between Odoo 18 and your Medusa.js store (v1 and v2): import products with variants, customers and orders, push product changes back, and reconcile refunds — with a resilient job queue, dry-run safety, validation and rollback so you stay in control.
This page is the complete manual. If you follow it top to bottom you can install, connect, run your first sync, automate it, and fix the common issues without contacting support.
- Overview
- Requirements
- Installation
- Step 1 — Get Medusa Admin API access
- Step 2 — Create the connection in Odoo
- Step 3 — First sync (dry-run, then live)
- Order status mapping
- Field mapping & customization
- Automation (scheduled actions & webhooks)
- Safety features
- Troubleshooting
- Frequently asked questions
- Data, privacy & limits
- Support & updates
- Upgrading & version compatibility
- Uninstallation
- Changelog
Overview
The connector keeps Odoo and Medusa in sync over the Medusa Admin API, using a JSON REST client that speaks both the Medusa v2 and Medusa v1 lines. A capability layer absorbs the route and money-unit differences between them (v2 uses major currency units, v1 uses minor units / cents). It covers:
- Products — import Medusa products (with variants, options and images) into Odoo product templates, optionally with stock and tax, and export Odoo product changes back to the store.
- Customers — import Medusa customers and their addresses into Odoo contacts.
- Orders — import Medusa orders into Odoo sale orders, mapping each order's Medusa status to a sale-order action (keep draft, confirm, cancel, or ignore).
- Refunds — optionally discover Medusa order_slip credit notes attached to an order and create matching draft customer credit notes in Odoo.
Direction of sync: Odoo ↔ Medusa (import is the primary flow; product export and webhook-driven updates are supported).
Every remote call goes through a queue: nothing is written to Odoo until a job runs, jobs retry with back-off on transient failures, and a circuit breaker pauses an instance that keeps failing.
Requirements
- Odoo: 18.0, Community or Enterprise.
- Medusa: both Medusa v2 and Medusa v1 are supported; pick the matching line in the API version field. The Medusa server must be reachable from the Odoo server.
- Python: no extra libraries beyond a standard Odoo 18 install.
- Odoo access: any internal user can use the connector screens. Medusa credentials are stored in system-only fields, so only the Settings / Administration user can read or change the API key, password, publishable key and webhook secret.
- Network: outbound HTTP/HTTPS from Odoo to your Medusa server. By default the connector refuses internal/loopback/private hosts as an SSRF safeguard (see Safety features).
Installation
- Copy bambooforge_medusa_connector into your Odoo addons path.
- Restart the Odoo service.
- Open Apps, click Update Apps List, search for Medusa, and press Activate / Install. Dependencies (Sales, Contacts, Invoicing, Product) install automatically.
No Medusa store is required to evaluate the connector: a mock Medusa Admin API ships inside the module, so you can install, explore and run the full import flow against sample data before pointing it at a real store. Point the instance Base URL at <your-odoo>/medusa/mock_api with auth type Email + Password (any email/password is accepted) to try it.
Webhook subscriber companion (optional, for real-time sync)
To push changes from Medusa to Odoo in real time, install the small webhook subscriber that ships with this module at phase2/medusa_subscriber/bambooforge-webhook.ts:
- Copy bambooforge-webhook.ts into your Medusa project's src/subscribers/ directory.
- Set three environment variables in your Medusa .env:
- BAMBOOFORGE_WEBHOOK_URL — e.g. https://odoo.example.com/medusa/webhook
- BAMBOOFORGE_WEBHOOK_SECRET — must match the instance Webhook Secret in Odoo
- BAMBOOFORGE_INSTANCE_ID — the medusa.instance id in Odoo (optional but recommended; appended as ?instance_id=)
- Restart Medusa. The companion is written for the Medusa v2 subscriber API; for Medusa v1 see the README in that folder.
Without the companion, the scheduled reconciliation still keeps data current (see Automation).
Step 1 — Get Medusa Admin API access
The connector authenticates to the Medusa Admin API. Choose one of three auth types on the Odoo instance; how you obtain the credential depends on your Medusa line:
Medusa v2 — Admin Secret API Key (recommended)
- Sign in to the Medusa Admin dashboard as an admin user.
- Go to Settings ▸ Secret API Keys (Developer / API key management).
- Create a Secret API Key, give it a name like Odoo, and copy the key once it is shown.
- In Odoo, set Authentication to Admin Secret API Key (v2) and paste the key into API Key. The connector sends it as HTTP Basic (key as username, empty password).
Medusa v2 — Email + Password (JWT)
If you prefer not to manage a secret key, set Authentication to Email + Password (JWT) and enter an admin Email and Password. The connector exchanges them for a JWT at POST /auth/user/emailpass and caches the token.
Medusa v1 — Email + Password or pre-issued token
For a Medusa v1 server, set API version to Medusa v1. Either use Email + Password (JWT) (the connector logs in at POST /admin/auth/token), or, if you already hold a token, set Authentication to Bearer Token and paste it into API Key.
Optional: if your Medusa requires a publishable key for store-scoped calls, paste it into Publishable API Key; it is sent as the x-publishable-api-key header.
Step 2 — Create the connection in Odoo
Open Medusa Connector ▸ Configuration ▸ Instances and create a record.
Key fields:
| Field | What to enter |
|---|---|
| Name | A label for this store, e.g. My Live Store. |
| Base URL | Your Medusa server root, e.g. https://store.example.com or http://localhost:9000. |
| API version | Medusa v2 (default) or Medusa v1. Drives money units and the auth login route. |
| Authentication | Admin Secret API Key (v2), Bearer Token, or Email + Password (JWT) — see Step 1. |
| API Key | The secret API key (secret-key auth) or pre-issued token (bearer auth). Leave empty for the email/password flow. Visible to administrators only. |
| Email / Password | Admin email and password for the email/password JWT flow (password is admin-only). |
| Publishable API Key | Optional store-API publishable key, sent as x-publishable-api-key (admin-only). |
| Admin API path | Leave the default /admin unless your server differs. |
| Default currency code | Currency (e.g. usd, eur) used to pick a variant price on import. Default usd. |
| Verify SSL | Keep on for production. Turn off only for self-signed test certificates. |
| Allow internal host | Off by default. Turn on only to reach a Medusa server on localhost or a private network (lowers the SSRF guard — see Safety features). |
Then click Test Connection. A green Connected state means the credentials and URL are correct. On the first successful connection the default order-status mapping is seeded automatically. If it fails, the exact error is shown on the form and recorded in Logs (see Troubleshooting).
Tip: use Quick Setup (button on the instance) to pick a solution pack (catalog only, B2C full sync, B2B order-first, retail starter), seed default field mappings and flows, and apply a recommended safety profile in one step.
Step 3 — First sync (dry-run, then live)
New instances start with Dry-run ON. In dry-run, import and delete jobs simulate writes: instead of changing data they produce Validation Results you can review under Medusa Connector ▸ Operations ▸ Validation Results. This lets you confirm what would happen before anything is written.
To run a first import:
- On the instance, click Import Products (and/or Import Customers, Import Orders). This enqueues jobs; it does not block the UI.
- Jobs are processed by the Medusa Queue Processor scheduled action (every minute), or immediately if you run it manually from Operations ▸ Queue Jobs.
- Review Validation Results while still in dry-run.
- When satisfied, open the instance, turn Dry-run OFF, and run the imports again to write the records for real.
Imported records land in the standard Odoo apps: Sales ▸ Products, Contacts, and Sales ▸ Orders. Each carries its Medusa reference (a binder record) so re-imports update the same record instead of duplicating it.
Order status mapping
Medusa exposes each order's status (e.g. pending, completed, archived, canceled, requires_action) and a fulfillment_status (e.g. not_fulfilled, fulfilled, shipped, returned) used as a fallback. Under Configuration ▸ Order State Mappings each instance gets a default table (seeded on first successful connection) that decides what happens to the Odoo sale order when an order arrives in a given status:
| Medusa status | Type | Default Odoo action |
|---|---|---|
| pending | order status | Keep draft |
| requires_action | order status | Keep draft |
| completed | order status | Confirm sale order |
| archived | order status | Confirm sale order |
| canceled | order status | Cancel sale order |
| not_fulfilled | fulfillment status | Keep draft |
| fulfilled | fulfillment status | Confirm sale order |
| partially_fulfilled | fulfillment status | Confirm sale order |
| shipped | fulfillment status | Confirm sale order |
| partially_shipped | fulfillment status | Confirm sale order |
| returned | fulfillment status | Cancel sale order |
Change any row to Ignore (do nothing), Keep draft, Confirm sale order or Cancel sale order. Unknown/custom statuses default to Ignore, so a status you have not mapped never triggers a destructive transition. Add a row for any custom status your store introduces (use the exact Medusa status string).
Field mapping & customization
- Field Mappings (Configuration) map Medusa fields to Odoo fields per model. Use Generate suggested mappings on the instance to seed the business-critical ones, then adjust. The mapping board flags fields that need attention.
- Schema Fields lists the discovered Medusa fields per resource. Run Schema Introspection on the instance to refresh it from your live store (it falls back to the bundled mock sample if the store is unreachable).
- Stock / images / tax / refunds are opt-in toggles on the instance: Sync stock, Sync images (and max images), Upload images on export, Sync taxes / Auto-match taxes on import, Sync refunds / Auto-post refund. They are off by default; turn on only what you need. Tax auto-matching is name-based, company-scoped, and never auto-creates taxes.
Automation (scheduled actions & webhooks)
The module ships these scheduled actions (Settings ▸ Technical ▸ Scheduled Actions):
| Scheduled action | Default | Purpose |
|---|---|---|
| Medusa Queue Processor | every 1 min | Processes queued import/export/delete jobs. |
| Medusa Reconciliation | every 15 min | Pulls recent remote changes for enabled models. |
| Medusa Maintenance | every 1 hr | Recovers stale/locked jobs and trims old logs. |
| Medusa Flow Scheduler | every 5 min | Runs scheduled sync flows. |
| Medusa Flow Metrics | every 1 hr | Aggregates flow-run metrics. |
| Medusa Auto Recover | every 15 min | Reopens a tripped circuit breaker once the store is healthy. |
Turn on Auto import / Auto reconcile per model on the instance to let the scheduled actions keep things in sync hands-free.
Real-time webhooks (optional): install the subscriber companion (see Installation). It POSTs HMAC-SHA256-signed events to:
- Delivery URL: https://<your-odoo-domain>/medusa/webhook (optionally ?instance_id=<id> to target a specific instance).
- Secret: the instance Webhook Secret (admin-only field on the instance).
Each delivery carries an X-Medusa-Signature header. Odoo verifies the HMAC-SHA256 signature over the raw body, rejects stale or replayed deliveries, and enqueues a safe import. Without webhooks the scheduled reconciliation still keeps data current.
Safety features
- Dry-run mode — simulate writes and review Validation Results before going live (field Dry-run mode, ON by default).
- Business validation profiles — Minimal / Standard / Strict gate risky writes (field Business validation profile).
- Safety profile — Conservative / Balanced / Aggressive presets set the dry-run, validation, batch-size and webhook dials in one click.
- Resilient queue — every remote action is a job with retry, exponential back-off and a dead-letter state.
- Circuit breaker — after repeated failures an instance auto-pauses (Tripped); the Auto Recover action reopens it once the store responds again (auth/configuration failures trip it immediately and require manual resume).
- Rollback snapshots — when Rollback enabled is on, imports capture a snapshot so you can undo a batch from Operations ▸ Rollback Snapshots.
- SSRF guard — the connector refuses internal/loopback/private hosts unless Allow internal host is explicitly enabled.
- Signed webhooks — the public webhook route fails closed: a missing secret or signature is rejected, and stale/replayed deliveries are dropped.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Test Connection fails with 401 / unauthorized | Wrong or revoked API key, token, or email/password; or the wrong API version for your server. Re-check Step 1 and that Authentication matches your Medusa line. |
| "An API key / token is required" error | The selected auth type needs API Key filled (secret-key or bearer). Either fill it or switch Authentication to Email + Password (JWT). |
| "Email and password are required" | Auth type is Email + Password but one of the fields is blank. Fill both, or switch to a key/token auth type. |
| "Base URL ... is not allowed" / refused internal host | Base URL points at localhost/private IP. Enable Allow internal host on the instance (trusted self-hosted Medusa only). |
| SSL errors on Test Connection | Self-signed certificate. Use a valid cert, or turn off Verify SSL for testing only. |
| Orders import but never confirm | The order's Medusa status is mapped to Keep draft or Ignore. Adjust Order State Mappings. |
| Product prices are wrong / zero | The variant has no price in Default currency code. Set the matching currency (e.g. usd, eur) on the instance, or check the v1/v2 API version (v1 uses minor units / cents). |
| Jobs stay in Pending | The Queue Processor is off or the instance is paused. Check the Medusa Queue Processor scheduled action is active and the instance is not Paused. |
| Instance shows Tripped | Circuit breaker tripped after repeated failures. Fix the store/credentials; Auto Recover reopens it after cooldown, or click Resume. |
| Webhook returns 401 (Invalid signature) | The Medusa BAMBOOFORGE_WEBHOOK_SECRET does not match the instance Webhook Secret, or the signature header is missing. Align both. |
| Nothing happens after Import | You are in Dry-run. Review Validation Results, then turn dry-run off and re-run. |
For anything else, Operations ▸ Logs records every API call and error with a timestamp.
Frequently asked questions
Which versions are supported? Odoo 18.0 on the Odoo side. On the store side both Medusa v2 and Medusa v1 are supported — pick the line in the API version field. Validate your exact build with the bundled mock first.
Do I need a Medusa store to evaluate it? No. A mock Medusa Admin API ships inside. Point the Base URL at <your-odoo>/medusa/mock_api (auth Email + Password, any credentials) to run the full import flow before connecting a real store.
How does authentication work? Three ways: a Medusa v2 Admin Secret API Key (sent as HTTP Basic), a pre-issued Bearer Token, or Email + Password exchanged for a JWT (/auth/user/emailpass on v2, /admin/auth/token on v1). All three are built in.
How does real-time sync work? Install the bundled webhook subscriber companion in your Medusa project. It POSTs HMAC-SHA256-signed events to /medusa/webhook; Odoo verifies the signature and enqueues a safe import. Without it, scheduled reconciliation keeps things in sync.
Is it safe to run against production data? Dry-run is ON by default, validation blocks risky writes, and rollback snapshots let you undo. You decide when to go live.
What support and refund policy do I get? Every request is answered within 24 hours, setup help included. If you report a bug within 2 months of purchase and it is not resolved within 15 days, you are entitled to a full money-back refund.
Data, privacy & limits
- The connector reads products, customers, orders and refunds (order_slip) from your Medusa store and writes the corresponding Odoo records. Credentials are stored in admin-only fields.
- In scope today: product/variant/customer/order import, product export, order-status mapping, refund discovery, scheduled sync, signed webhooks.
- Out of scope / best-effort: tax auto-matching (off by default, name-based, never auto-creates taxes); multi-warehouse stock routing; subscription order types.
Support & updates
- Support: bambooforge.labs@gmail.com — answered within 24 hours, setup help included.
- Refund: report a bug within 2 months of purchase; if unresolved within 15 days, full refund.
- Full source is included. Updates track the supported Odoo 18 / Medusa v1 & v2 Admin API line.
Upgrading & version compatibility
This build targets Odoo 18.0. Each Odoo major series (17.0, 18.0, 19.0) has its own dedicated build of this module — always install the build that matches your Odoo version. Mixing a build with a different Odoo series is not supported.
Patch upgrades (same series, e.g. 18.0.1.0.0 → later)
Back up your database and filestore first.
Replace the module folder with the newer build.
Restart Odoo with the module updated:
./odoo-bin -c your.conf -u bambooforge_medusa_connector -d your_db
Odoo applies any schema/data changes automatically. Your existing records and configuration are preserved.
Cross-version migration (e.g. Odoo 17 → 18)
Upgrading Odoo itself is a database migration handled by Odoo's standard upgrade tooling. When you migrate the database to the next Odoo series, install the matching build of this module for that series. Data created by this module carries over with the database migration.
After any upgrade the module's scheduled actions resume on their normal cadence — no manual re-activation is required.
Uninstallation
You can remove this module at any time from Apps → (this module) → Uninstall, or from the command line. Uninstalling is clean and reversible by reinstalling — but note what is and is not deleted.
What is removed
- The module's own tables and every record in them (20 models, prefixed medusa.*) — this is the data this module created.
- The menus, actions, views and reports this module installed.
- Its scheduled actions (cron jobs) — they stop immediately on uninstall.
- Connection records, credentials, field mappings, queue jobs and sync logs stored in Odoo.
What is preserved
- Your remote platform is never touched. Uninstalling only removes the Odoo-side connector; products, customers and orders on the external store/service are untouched.
- Records already imported into standard Odoo models (e.g. contacts, products, sales orders) remain — they are ordinary Odoo records once created.
- Attachments and chatter messages on standard records are kept.
As always, take a database backup before uninstalling in production.
Changelog
18.0.1.0.0
Current release for Odoo 18.0. This build includes:
- Two-way Odoo 18 <-> Medusa.js (v1 & v2) connector: products, variants, customers, orders and refunds.
- JSON REST client, webhook subscriber companion, two-way stock sync, live Sync Control Tower, resilient queue and dry-run safety.
Feature additions and fixes ship as new builds on the Odoo Apps store; this page and the module's version reflect the current published release. Always keep the build matched to your Odoo series (see Upgrading & version compatibility).
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module